.png)
AI can write a function in seconds. Your engineering process still decides why the function exists, what it touches, how it gets tested, and who signs off.
That gap explains most of the frustration around AI on software teams right now. DORA's 2025 State of AI-assisted Software Development report, built on responses from nearly 5,000 technology professionals, found 90% using AI at work and more than 80% saying it made them more productive.
The same survey found 30% place little or no trust in the code AI produces. Fast output, shaky confidence.
Better models do not close that gap. A defined AI development process includes: defined tasks, defined inputs, defined checks, and defined owners – and that’s exactly what we look closer at in this article.
What an AI-driven development workflow is
An AI-driven development workflow is the software development lifecycle (SDLC) you already run, with specific engineering tasks handed to AI, each one connected to the technical context it needs, validated by automation, and approved by a named engineer before anything ships.
The sequence looks like this:
Requirement → engineering context → AI task → automated checks → human review → deployment → production feedback
Only the third box is new. Testing, security review, release control, and ownership all stay where they were. What changes is who drafts the first version and how quickly drafts show up.
Handing every developer a coding assistant does not get you here. A tool in the environment is not a process. DORA's AI Capabilities Model, drawn from the same 2025 dataset, names seven organizational capabilities that separate teams getting value from AI from teams getting noise:
- a clear and communicated AI stance
- healthy data ecosystems
- AI-accessible internal data
- strong version control
- working in small batches
- user-centric focus
- a quality internal platform
Six of the seven describe the system around the model. One describes the data going into it. None of them describes the model.
Start with the SDLC you already have
Map the current process first. A one-page process map shows where engineers spend their hours and which activities have clean inputs and checkable outputs.
Two things fall out of the exercise. Repetitive work with verifiable output lights up as an AI candidate. Decisions with long tails stay with people. The process stays recognizable to everyone who already works in it, which matters more than it sounds when you ask a team to change habits.
Integration beats tool count
A company can run five AI products and still have a fragmented AI software development workflow. GitLab's AI Accountability Report, conducted by The Harris Poll among 1,528 DevSecOps professionals across six countries, found that 91% of organizations are running two or more AI coding tools.
Only 28% said their SDLC tools were fully integrated with shared data and workflows, and 80% said their organization adopted AI faster than it wrote the policies to govern it.
Fragmented tooling shows up twice. The AI sees fragments of your system, so its output misses context it was never given. Your team sees fragments of the AI's work, so nobody can trace a change back to the request behind it.
Map AI to engineering tasks, not job titles
“Use AI in development” tells an engineer nothing.
“Generate regression tests for approved API changes, run them in CI, send failures back before review” gives a team something to run, measure, and tune.
Task shape drives results. A repeatable activity with clear inputs and a checkable output behaves nothing like an architecture call made on incomplete information with five years of consequences attached.
Where AI earns its keep
Some engineering work has repeatable steps and output that an engineer can verify in minutes:
- Summarizing requirements and tickets
- Explaining unfamiliar code
- Generating unit and regression tests
- Updating technical documentation
- Analyzing dependencies
- Preparing pull request summaries
- Correlating logs during incident investigation
- Finding duplicated code
- Drafting migration scripts for engineer review
None of this transfers engineering ownership. It moves the first draft.
Where humans stay on the hook
Architecture decisions, security exceptions, production changes, technology selection, and business-critical logic need tighter control. AI can draft, simulate, and recommend. Engineers weigh the trade-offs, test the assumptions, and green-light the change.
DORA's analysis puts numbers behind the caution. Time saved during initial generation frequently gets reallocated to auditing and verification, and higher AI adoption is associated with increases in both software delivery throughput and software delivery instability.
You go faster out of the gate and pay for it downstream if the controls are thin.
These boundaries get more valuable as AI software engineering moves from assistants that suggest to agents that act.
Build the context layer before you ask AI for more
A model with one file open knows one file. A model connected to repository history, architecture docs, coding standards, tickets, API specs, and test results works from your actual system.
DORA treats this as a capability worth funding early. Connecting AI to proprietary sources such as internal codebases, documentation, and operational metrics acts as a statistically significant multiplier for individual effectiveness and code quality.
Feed it the right engineering sources
- Source repositories
- Architecture documentation
- API specifications
- Issue trackers
- Coding standards
- Test results
- CI/CD status
- Dependency information
- Observability data
- Incident records
Scope access to what the task can break
An agent with repository access can read secrets, call APIs, and modify project resources. Permissions should match the assigned job, same as any other system with write access to production.
DORA recommends a phased approach: assemble the relevant docs and code by hand first, then automate retrieval through methods such as retrieval-augmented generation or MCP. The research also warns against dumping large volumes of poorly selected material into context, since stale or irrelevant content degrades output. Three risks come with the territory: sensitive data exposure when access controls slip, technical debt when the model reproduces deprecated code, and delivery instability when generation outruns small-batch discipline.
Give AI what the task requires. Nothing beyond it.
Put human-in-the-loop controls where the decisions live
Human-in-the-loop does not mean an engineer reads every generated line. That version of review eats the time AI was brought in to save, and it turns senior people into rubber stamps by week three.
Put the human at the decision, not at the keystroke:
AI proposes → automated checks run → engineer reviews → system deploys
A docs update needs one reviewer. A change to authentication logic needs security checks and a senior sign-off. Same workflow, different gates.
The market has caught up to this. In GitLab's 2026 survey, 92% reported governance challenges with AI-generated code, 83% called accumulated AI code a risk to manage now, with 44% ranking it a top technology risk, and 85% agreed the next phase of AI in software will focus less on generating code and more on governing and maintaining it.
Every checkpoint should map to a decision that needs engineering judgment, security authority, or production ownership. Everything else belongs to automation.
How to wire AI into testing, review, and CI/CD
Generated code is a proposal, not a deliverable. Your pipeline decides whether the proposal survives. The split works cleanly. AI handles probabilistic work. Automation handles repeatable validation. Engineers handle decisions.
What follows is the loop the TYMIQ team runs on client delivery. Each step has one metric attached, so a failing step surfaces before the next one starts.
The verification loop
Each step gets one metric with a threshold, so a failing step is visible before the next one runs.
- Pull the approved requirement
KPI: Traceability rate.
Share of merged PRs linked to a ticket whose acceptance criteria were written and approved before generation started.
Target: 100%. Anything below means work entered the pipeline without a definition of done, and every downstream metric inherits the ambiguity.
- Retrieve the relevant technical context
KPI: Retrieval recall on touched files.
Compare the context set handed to the model against the file set in the final merged diff.
Target: 80%+ of merged-diff files present in retrieval. Low recall is the earliest predictor of rework, and it shows up two steps before anyone sees a red build.
- Ask AI to propose an implementation
KPI: First-pass acceptance rate plus human rewrite ratio (lines a human replaced ÷ lines proposed, measured 48h post-merge).
Target: acceptance above 60%, rewrite ratio under 30%. A high acceptance rate paired with a high rewrite ratio means reviewers are approving and then quietly fixing.
- Generate or update tests
KPI: Mutation score on changed lines. Coverage alone gets gamed by tests with no assertions.
Target: 70%+ mutation score on new and modified lines, tracked alongside assertion density. Add new-code coverage delta as a secondary read, never the primary one.
- Run CI and security checks
KPI: Signal quality, measured as flake rate under 2% and SAST/SCA findings per 1,000 generated lines benchmarked against your human-authored baseline.
Add time-to-red: how long from push to the first failing check. A noisy pipeline trains engineers to click through, which turns step 6 into theater.
- Route the change to human review
KPI: Defect escape rate per merged PR, segmented AI-assisted vs. human-authored.
Pair with a rubber-stamp indicator: share of AI PRs approved in under five minutes, or with fewer than two comments per 100 changed lines. The segmentation matters more than the absolute number, since parity with your human baseline is the actual bar.
- Send failures back for correction
KPI: Convergence cycles to green. Median fix iterations per failed change, with an escalation trigger at three. Track the share of failures resolved without human intervention. Rising cycle counts on a specific service usually mean the context in step 2 is thin, not that the model is weak.
- Merge after the required controls pass
KPI: Change failure rate and lead time for changes, plus a control bypass rate: percentage of merges completed via admin override or skipped check.
Target bypass at zero. The first two tell you whether the loop holds; the bypass number tells you whether it ran at all.
Generation sits in the middle of that list for a reason. Verification wraps around it on both sides, which is exactly where the reallocated time from DORA's research ends up going.
Measure the workflow before you scale it
An AI development workflow without measurement is a vibe. Teams need to know which workflows save engineering hours, which create rework, and which quietly move problems downstream.
Track at the workflow level:
Run the numbers before and after. A developer finishing a task in half the time looks great until review time doubles and post-release defects climb.
An AI engineering scorecard needs coverage across four dimensions: delivery speed, quality, engineering capacity, and business results. The volume of generated code stays an operational stat. It cannot carry the evaluation by itself, and treating it as a headline metric rewards the wrong behavior.
How to turn one working pilot into standard practice
Once a workflow holds up for one team, write down the rules before you widen it.
An internal playbook covers approved tools, permitted data sources, task types, review requirements, security controls, escalation paths, and metrics. Engineers should know where AI acts on its own, where review is mandatory, and which controls the generated output has to clear. DORA describes AI as an amplifier of what already exists in an organization, so the quality of those written rules gets multiplied along with everything else.
Stable results earn the right to expand. Then run the same four weeks on the next activity. What you end up with is a repeatable method for continuous improvement, and the method travels better than any specific prompt ever will.
What a mature AI-driven workflow looks like
AI-driven software development matures on boundaries, not autonomy. The marker is clear lines between AI work, automated validation, and human judgment.
Tool adoption is an operational number. The real assessment of AI-powered engineering is whether the workflow produces better software at a defensible balance of speed, quality, cost, and oversight.
The five-question test
Point at any AI task in your process and answer five questions:
- What engineering task does AI perform?
- What information does it receive?
- What checks surround its output?
- Who approves the result?
- Which metric judges it?
Five answers mean you have a workflow. Fewer means you have a tool and a hope. AI can generate code, analyze a failure, summarize a ticket, or prepare a change in seconds. Engineering best practices still decide whether that change gets tested, reviewed, deployed, and maintained. The workflow owns the final call.
.webp)
.svg)
