Why AI coding adoption may not improve delivery performance
Faster code generation did not shorten your delivery queue. It moved it. The constraint in most enterprise engineering organisations was never how fast code got written, so making that step faster improves one stage and adds load to three others, which from outside looks exactly like nothing happening.
That is not an argument against the tools. It is an argument against expecting a tool to fix a process problem, and against the measurement that lets you believe it did.
- Adoption is effectively solved. Industry surveys in 2025 put AI assistant use among software professionals in the mid-eighties to around ninety percent.
- Organisation-level throughput has not moved in proportion. Individual output rose; delivery performance did not follow.
- Typing was never the constraint. Review capacity, integration, environments, approvals and rework were, and AI adds load to three of those.
- Faster code generation increases the volume arriving at every downstream gate. Without changing the gates, you have moved the queue, not shortened it.
- The measurable version of this is an operating-model change, not a tooling change.
The gap between adoption and outcome
Two things are now true at once, and they sit awkwardly together. Nearly every engineering organisation has adopted AI coding assistants. Very few can show an organisation-level improvement in delivery performance that they are willing to attribute to them.
Both halves are well evidenced. Adoption figures from the 2025 DORA research and the 2025 Stack Overflow developer survey land in the mid-eighties to roughly ninety percent. Meanwhile the productivity claims attached to AI-native development approaches, including AWS-linked experiments reporting order-of-magnitude gains, have not translated into comparable movement in organisational throughput.
The usual explanations are that it is early, or that the measurement is wrong. Both are partly true. Neither explains why the gap is so consistent.
What the constraint actually was
The assumption inside every productivity claim is that writing code was the bottleneck. For most enterprise teams it was not, and had not been for years. The queue formed after the code existed.
| Stage | Was it the constraint? | Effect of faster generation |
| Writing the code | Rarely | Improves, substantially |
| Code review | Often | Load increases |
| Integration and environments | Often | Load increases |
| Test and quality gates | Sometimes | Load increases |
| Change approval | Often, in regulated settings | Unchanged |
| Rework from unclear requirements | Very often | Unchanged, sometimes worse |
Read the right-hand column. Faster generation improves exactly one stage and increases pressure on three. That is not a productivity gain arriving slowly. It is a bottleneck moving downstream, which looks like no gain at all from outside.
The rework problem nobody instruments
The stage that matters most is the one least measured. Code written against an ambiguous requirement is rework whether a human or a model wrote it, and models are considerably faster at producing confident work from thin input.
This is why teams that instrument only volume metrics, commits, pull requests, lines changed, report improvement while the business sees none. The volume is real. So is the share of it that gets discarded, and almost nobody counts that.
Three measures separate signal from noise here, and none of them is a volume count: review latency, defect escape rate, and rework as a share of merged change. If those three are flat, the tooling has not changed your delivery performance regardless of how much faster the keyboard got.
What actually changes the number
The organisations that do show movement changed the process around the tool rather than only the tool. In practice that means four things.
Specification before generation. If the model is the fastest writer in the room, ambiguity becomes the most expensive input in the room. Getting requirements to a state a model can act on correctly is now a delivery activity, not a preamble to one. Our delivery method puts that step first for exactly this reason.
Review capacity treated as infrastructure. If generation doubles, review has to scale or become the constraint. That means automated checks carrying more of the load so human review is spent on judgement rather than mechanics, which is the argument for treating quality engineering as a platform concern.
Gates sized to risk. Uniform approval processes were tolerable when change volume was lower. At higher volume they either bottleneck everything or get bypassed. Risk-tiered gates are what make higher throughput safe rather than merely faster.
Measurement that survives contact with a stakeholder. Review latency, defect escape and rework, tracked before and after, per team. Vanity metrics will show a win. They will not survive the question of what changed for the business.
The honest version of the claim
AI assistants make individual engineers meaningfully faster at a task that was not your constraint. That is genuinely valuable, and it is not the same thing as making your organisation deliver faster. The second outcome requires changing how work is specified, reviewed, gated and measured, which is an operating-model problem rather than a licence-purchase problem.
So here is a threshold worth committing to before the next renewal. If review latency, defect escape rate and rework share have not moved after two quarters of near-universal adoption, do not expand the licence. The tooling is not the thing that is failing, and buying more of it will not reach the stage that is. Fix the gate that the volume is piling up behind, then measure again. That is a test the tools can pass, which is the point of stating it: an unfalsifiable claim about productivity is not a claim at all.
For Australian enterprises with distributed teams, the effect is amplified, and it hides better. A generation speed-up in one location lands as review load in another, so the queue forms across a timezone boundary where neither team can see the whole of it. Both sides report that their part is working. How teams work decides whether that resolves or compounds, and it is usually the first thing cut when a delivery programme comes under pressure.
If you want the mechanism rather than the argument, this is the problem Greenlight was built around, and it opens on the same observation this article does: output volume is up, and review has quietly become the bottleneck nobody planned for. The response is to put three steps in the work rather than in a policy document. An agent proposes the work. An independent check tests it against the standard it has to meet, before anyone acts on it. A person with the context to judge it and the standing to refuse it clears it, and that decision is part of the record rather than a checkbox beside it.
Two properties of that matter for the argument above. It governs the AI coding tools your teams already use rather than replacing them, which is the right shape, because the licences were never the problem and removing them would fix nothing. And because verification runs as the work happens instead of after it, review capacity scales with generation instead of queueing behind it, which is the one thing that has to be true for faster writing to become faster delivery. Greenlight Engineer is that model applied to the software lifecycle.
Sources
Adoption figures are drawn from the named industry surveys below. Productivity-gain claims for AI-native development approaches come from the AIDLC literature, which should be read with its experimental conditions in view.
- DORA. State of DevOps / DORA research, 2025. AI adoption among software professionals. Verify the current edition before citing a figure.
- Stack Overflow. Developer Survey, 2025. AI tool use among respondents.
- AIDLC, the AI Development Life Cycle. justenougharchitecture.com
- AI-Driven Development Lifecycle (AI-DLC). ijaidsml.org
