There is no shortage of instruction on how to introduce AI coding tools. We publish some of it ourselves. What is harder to find is a straight account of what happens when teams actually do it, now that enough of them have done it for long enough to measure.
This is that account. It is deliberately not a how-to - the rollout guide covers the method, and the measurement guide covers the templates. This piece is about what the evidence says, including the parts that are inconvenient for people selling the tools and for people dismissing them.
The adoption question is settled. The value question is not.
Adoption is effectively universal among professional developers. Stack Overflow’s 2025 survey found 84% using or planning to use AI tools, and Google’s DORA research put adoption around 90% of practitioners with a median of roughly two hours a day of AI-assisted work.
Trust is a different story entirely. In the same Stack Overflow data, more developers actively distrusted the accuracy of AI output than trusted it - 46% against 33%, with only about 3% expressing high trust.
Those two findings sit awkwardly together and they are the most important thing on this page. Near-universal use combined with majority distrust means the tools are being used under supervision, by people who expect to correct the output. Any business case built on the assumption that generated code ships unexamined is built on something practitioners do not believe.
The measured productivity gain is real and smaller than advertised
Vendor claims of 30% or 50% productivity improvements have not survived contact with measurement.
DX, which instruments engineering organisations for a living, reports a median improvement of about 7.8% in pull request throughput, with most organisations landing between 5% and 15%. Google’s DORA programme published a framework for measuring the return on AI-assisted development, and its central argument is that AI amplifies the organisation it lands in rather than transforming it: strong engineering cultures get stronger, weak ones get faster at producing problems.
A 7.8% median is not a disappointing result. On a team of twenty engineers it is meaningful money. It is simply not the number in the pitch deck, and budgets built on the pitch-deck number will not survive review.
The constraint moved from writing to checking
This is the finding that changed how I advise clients, and it is under-discussed because it is inconvenient.
Sonar’s 2026 developer survey, covering more than a thousand developers, found the top reported bottlenecks were manual code review at 52%, security testing at 51%, code rework at 48% and prompt iteration at 41%. Analysis of AI-generated pull requests has found roughly 1.7 times more issues than in comparable human-authored ones. Research inside a Fortune 50 engineering organisation found AI-assisted developers committing three to four times faster while introducing security findings at around ten times the rate.
Read those together and the mechanism is clear. Generation got cheap. Verification did not. The work did not disappear; it moved downstream onto the people who review, and those are your senior engineers.
This is why we now treat reviewing AI-generated code as a distinct discipline rather than an extension of normal code review. AI output is uniformly tidy whether it is correct or not, which defeats the visual cues reviewers have relied on for twenty years.
What it actually costs
Spend has settled higher than most teams budgeted for. Organisations mixing inline completion with agentic tooling are typically paying $150 to $600 per developer per month, with heavy users considerably above that - Uber capped per-employee spending at $1,500 per tool per month after usage ran away. Gartner has gone as far as suggesting AI coding costs will approach developer pay.
Set that against a 7.8% median throughput gain and the arithmetic gets interesting rather than obvious. It is still usually positive. It is not free money, and it is not the same answer for every team, which is exactly why measuring your own baseline matters more than reading anyone’s benchmark.
Where the evidence supports using them
Consistent across sources and my own client work:
Tests and scaffolding. Bounded, verifiable, and the output is checked by running it. The clearest win available.
Documentation and code explanation. Turning an undocumented module into something a new joiner can read is genuinely faster, and errors are cheap.
Translation and migration. Moving code between languages or framework versions, where the target behaviour is defined by the source and there is a test suite to prove equivalence.
Debugging assistance. As a second opinion on a stack trace, not as an authority.
Where the evidence says be careful
Anything security-critical. The ten-times security finding rate is the whole argument. Authentication, authorisation, cryptography, payment paths - human-authored, human-reviewed.
Core business logic. The subtle errors are the expensive ones, and they are exactly the class of error that looks fine on inspection.
Architecture. These systems produce a plausible answer, and architecture is a domain where plausible-but-wrong costs years. They are useful for enumerating options and poor at choosing between them.
Dependencies. Generated code cites packages confidently, and roughly one in five samples in published research referenced packages that do not exist. A name that does not exist is a supply-chain opening rather than a typo.
What I take from all of it
Three conclusions I would defend.
The tools are worth having and the gains are ordinary. Somewhere between 5% and 15% on throughput, concentrated in specific task types. Plan for that and you will be pleased. Plan for 40% and you will spend a year explaining a shortfall.
The value depends almost entirely on the review discipline around them. The same tool produces a good outcome in a team with strong review culture and a bad one in a team without it. That is what DORA means by amplification, and it is why buying the tool is the easy 10% of the project.
Senior engineers become more valuable, not less. If generation is cheap and verification is expensive, the people who verify are the constraint. Teams that cut senior headcount on the strength of AI adoption are removing the thing that makes AI adoption work.
If you want to establish what these tools are actually doing in your own organisation rather than in a survey, the measurement guide has the baseline template and pilot charter we use, free and without a form. If you would rather have it run with you, book a free consultation.