AI-Assisted Engineering: What the Data Says About Speed and Stability
90% of developers use AI tools. 30% report little or no trust in the output. Both findings are from the same study, and both are true.
AI-assisted engineering means models generating, reviewing or refactoring code inside your normal development workflow. The productivity question is settled — teams do ship faster. The open question is whether your review, testing and deployment practices are strong enough that shipping faster is a good thing.
What the data says about AI-assisted engineering
DORA's framing is that AI acts as an amplifier rather than a fix: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones. The controls around the code matter more once the code arrives faster.
Where AI genuinely speeds engineering up
Measure before and after
Track DORA's four delivery measures — deploy frequency, change lead time, change failure rate, time to restore — before introducing AI tooling. Without a baseline, throughput gains and stability losses are both invisible.
These four measures are the DORA programme's core metrics and predict both delivery performance and organisational outcomes.
Review discipline scaled to volume
If code arrives faster, review capacity has to grow with it or it becomes the bottleneck — and a rubber-stamped review is worse than no review, because it looks like a control.
Tests around the highest-churn code
Not full coverage. Coverage where you actually change things, so that accepting a generated change is a decision rather than a gamble.
Provenance for generated code
Know which code was model-generated. When a defect pattern emerges, being able to ask whether it clusters in generated code is worth having.
Explicit policy on what is not delegated
Security-sensitive code, authentication, permissions and payment paths deserve a written rule. Decide it once rather than per developer per sprint.
Watch change failure rate, not just velocity
DORA found AI adoption correlating with higher instability. If failure rate climbs while velocity does, the net has not necessarily improved.
Where AI slows engineering down
- Your change lead time is already measured in days because of manual deploys. Fix the pipeline first — AI makes code arrive faster into a queue that is already the constraint.
- You have little or no test coverage on the code being modified. Faster changes to untested code is a straightforward way to increase incidents.
- Review capacity is already saturated. Generating more code to review does not help a team that cannot keep up with what it has.
- The goal is headcount reduction rather than throughput. DORA's evidence supports faster delivery, not smaller teams, and planning around the latter tends to produce neither.
Green light, red light
| Dimension | Go ahead when | Do not when |
|---|---|---|
| Delivery baseline | DORA's four measures captured before introducing tooling | No baseline, so throughput gains and stability losses are both invisible |
| Pipeline health | Deploys are automated and change lead time is short | Lead time is already days because of manual deploys — AI only makes code arrive faster into a queue that is already the constraint |
| Test coverage | Tests exist around the code being changed most | Little or no coverage on the code being modified; faster changes to untested code is a direct route to more incidents |
| Review capacity | Review capacity grows with the volume of generated code | Review is already saturated — a rubber-stamped review is worse than none, because it looks like a control |
| What is delegated | A written rule covers security, authentication, permissions and payment paths | Each developer decides per sprint what is safe to delegate |
| Success measure | Change failure rate watched alongside velocity | Only velocity is tracked; DORA found AI adoption correlating with higher instability |
How to trial AI in your engineering team
-
01
Measure the four DORA metrics for a fortnight before changing anything. Deploy frequency, change lead time, change failure rate, time to restore.
-
02
Pick one team and one codebase rather than rolling out organisation-wide.
-
03
Add tests to the highest-churn area of that codebase first.
-
04
Write down what is not delegated to a model — security, auth, permissions, payments.
-
05
Re-measure at 30 and 90 days. If change failure rate rose more than throughput, tighten review before expanding.
Questions buyers ask about AI-assisted engineering
The evidence does not support that framing. DORA found throughput gains alongside stability costs, which points to a shift in where engineering effort goes — more review and integration, less initial authoring — rather than to fewer people.
DORA found that more than 60% had discovered AI-related errors after deployment. Distrust in that context is a rational calibration, not resistance to change, and it is why review discipline matters more once adoption is high.
Banning tends not to work — DORA's adoption figure suggests developers are using these tools regardless. The more effective response is to fix coverage on the code that changes most, and to write down what must not be delegated.
Change lead time: commit to production for a one-line change. If that is measured in days, your constraint is pipeline rather than authoring speed, and AI tooling will not move it.
Continue the kit
Want an honest read on your readiness?
Six evidence tests, four minutes, no email required. It will tell you plainly if the foundations are not there yet.
Run the assessment →Read the rest of the kit.
Five capability guides, every figure cited to a named source and year.
Open the AI Resource Kit →