Insights · Engineering · 9 min read
AI is not making engineering teams bigger. It is making them smaller and more senior.
DORA's 2025 research found AI raises delivery throughput and instability at the same time. The variable in between is judgement — and it is reshaping what a technology organization looks like.
Google's DORA program — the longest-running large-scale study of software delivery — surveyed close to 5,000 technology professionals for its 2025 report on AI-assisted development. Two findings sit side by side. AI adoption now correlates clearly with higher delivery throughput, a reversal of the previous year's result. And it continues to correlate with higher instability: more change failures, more rework, longer recovery.
Both are true at once, and that pairing is the most useful thing a delivery leader can currently know about AI. The tools are not overhyped — more than 80% of respondents report productivity gains, and a majority see quality improvements in the code they review. But the same adoption that raises speed raises breakage, unless something else changes with it.
AI is an amplifier
DORA's own thesis is that AI amplifies what an organization already is. Teams with strong foundations — clear architecture, small batches, working review practices, fast feedback — get faster and stay stable. Teams carrying heavy technical debt and process chaos get faster at producing more of both. The tool is identical; the outcome is decided by what it lands on.
The report goes further and names the organizational capabilities that separate the two outcomes: a clear and communicated policy on AI use, healthy data and internal platforms the AI can actually reach, strong version control discipline, work done in small batches, and a user-centered focus that keeps the extra output pointed at something valuable. None of these are AI technologies. They are the same foundations that predicted delivery performance before AI existed — which is exactly the point. AI did not change what makes engineering organizations good. It raised the price of not being good.
The trust numbers are a feature
Around 30% of engineers in the study report little or no trust in AI-generated code, and only a small fraction report high trust. It is tempting to read that as an adoption problem to be fixed with training and enthusiasm. It is closer to the opposite: calibrated scepticism is the control mechanism that keeps the instability line from running away.
The engineers who get the most from these tools treat AI output the way a senior engineer treats a confident pull request from someone new: probably useful, possibly wrong, definitely to be read. What makes that reading effective is architectural depth — enough understanding of the system's design to notice when a plausible change violates it. AI produces volume with total confidence and no accountability. Somewhere in the loop, a human has to supply the judgement and own the outcome, and the industry data suggests the teams that formalized that — review standards for AI-assisted changes, explicit accountability for merged code — are the ones on the right side of the stability line.
AI without judgement produces volume, not solutions — and unreviewed volume in a codebase is a liability, not an asset.
What this does to the shape of the team
Follow the economics through and the conclusion is uncomfortable for the way most technology organizations are built. For two decades, the standard response to more demand was more people — often a large bench of contractors, because the constraint was hands on keyboards. AI removes much of that constraint. The volume work — boilerplate, scaffolding, migrations, tests, the first draft of almost everything — is increasingly done by the machine.
What remains scarce is the judgement to direct it and check it. That inverts the team's value curve: a small number of genuinely senior engineers, each amplified by AI and each able to checkpoint what it produces, now out-delivers a much larger mixed-experience group — while producing a codebase that stays coherent, because every decision passed through someone who understood the design. Organizations restructured this way consistently report multiples of their previous output from a fraction of the headcount, and the pattern shows up across company sizes.
The transition is the hard part. It changes hiring profiles — depth over volume. It changes what juniors are for, and forces a serious answer to where the next seniors come from, because "learn by doing the boilerplate" stops being a career path when the machine does the boilerplate. And it changes the manager's job from allocating capacity to maintaining the standards the AI is held to. None of that happens by issuing licenses.
The metrics that predict which way it goes
DORA's 2025 data offers a practical warning: individual productivity gains do not automatically become organizational performance. Time saved writing code reappears as time lost downstream — in review queues, integration pain and rework — unless the whole value stream adjusts around the new speed.
If an AI initiative in engineering is measured by licenses active or code generated, expect the instability line. The indicators worth watching instead: change failure rate and rework alongside throughput, never instead of it; review depth on AI-assisted changes; batch size, which quietly balloons when generation is cheap; and whether the strongest engineers are running the practice or avoiding it. The prize is real and the leading teams are already collecting it. It is just not "the same team, faster." It is a different-shaped team — and the reshaping, not the tooling, is the work.