In September 2026, agents started more than 40% of all pull requests on GitHub. In March of the same year the figure was 17%. GitHub’s own Octoverse report puts the September volume at 110 million agent-started pull requests, about six times March’s, and is careful to say its detection method makes that a floor rather than a ceiling.
Writing code has become extremely cheap, extremely quickly. We use these tools every day and the speed is not in dispute here.
What has not happened is the thing most people assume follows. Across 655 firms and 445 million work events, the largest study of this question finds code volume up sharply and shipped software up far less. The gap between those two numbers is where the money goes, and it is the reason the people doing the checking matter more now than they did three years ago, not less.
Every figure below names its source in the sentence that uses it, and the dates matter: this field’s headline numbers have been superseded repeatedly, including one that its own authors have retired.
How fast did this actually happen?
Faster than any tooling shift I have worked through.
Stack Overflow’s 2026 survey found that only 17.2% of respondents use no AI tools at work, and 65.9% use coding assistants or agents specifically. Among people who use AI tools, 77% use them daily, and of those daily users 31% spend four or more hours of the working day in them.
Firm-level adoption moved faster still. Fiona Chen and James Stratton at Harvard, working with 445 million work events from 720,542 workers across 655 firms, put the share of firms that had adopted any AI agent at 91.0% by January 2026 and 98.3% by July 2026, from near zero in October 2024. JetBrains found 90% of professional developers using coding agents at least weekly by mid-2026.
The tools themselves reordered inside eighteen months. JetBrains has Claude Code going from 18% of developers in January 2026 to 39% by that summer, and 47% in the United States, while GitHub Copilot fell from 29% to 21%. We work in Claude Code most days, which is a disclosure rather than a recommendation.
So the diffusion is settled and nobody serious disputes it. The interesting questions are all downstream.
Does it make experienced engineers faster? That depends entirely on the code
Sort every credible speed measurement by what the developers were actually doing, and a gradient appears that explains almost all of the apparent disagreement in this field.
| Setting | Measured effect | Who ran it |
|---|---|---|
| One toy task, freelancers, greenfield HTTP server | 55.8% faster | Peng et al., authors at GitHub and Microsoft |
| A real patch in unfamiliar internal code, 96 engineers | ~21% faster, not statistically significant | Paradis et al., all nine authors at Google |
| Daily work, 4,867 developers across three firms | 26.08% more completed tasks | Cui et al., two Microsoft co-authors |
| Real issues in repos averaging a million lines and ten years | 19% slower | METR, independent nonprofit |
Same technology. The number travels from +56% to −19% on nothing but codebase maturity and the engineer’s familiarity with it.
Two honest caveats, because this is where most writing on the subject goes wrong.
The first is that METR has retired its own headline. Its July 2025 result now carries an out-of-date banner, and its February 2026 follow-up with late-2025 agentic tools found a point estimate favouring a speed-up whose confidence interval crosses zero in both directions. METR also reports that 30% to 50% of its developers declined to submit tasks they did not want to do without AI, which it says makes the data weak. Anyone still quoting “19% slower” as the current state of knowledge is quoting a figure its authors have withdrawn.
The second is that METR’s own paper says the result does not generalise outward. In section 4.1 the authors write that their results “are consistent with small greenfield projects or development in unfamiliar codebases seeing substantial speedup from AI assistance.” Their factor analysis names high repository familiarity as a cause of the slowdown, because familiarity raises the human baseline the model has to beat. The developers in that study averaged five years and 1,500 commits on the repositories they were working in.
The defensible claim is the gradient, not any single number on it. AI is fastest where the context is thin and slowest where it is deep, and the systems businesses depend on are all deep.
The code went up. The shipped software did not
Chen and Stratton measured both sides of that sentence in the same firms.
After agent adoption: lines of code +44.0%, commits +36.0%, pull requests opened +35.7%. Jira issues resolved: +13.7%, which they report as borderline significant. For non-agentic AI assistants the divergence is starker still, with lines of code +38.6% against issues resolved +2.0%, a figure not distinguishable from zero.
Code is an intermediate output. Resolved work is the thing a business buys. One rose by about a third as much as the other.
Where the difference went is measurable too. In the same firms, time from review submission to approval rose 56.1%, time waiting in the backlog 59.9%, time in active review 58.5%, and comments per change 38.6%. Of the additional pull requests agents produced, only about 62.7% were merged, against a baseline merge rate of 86.1%.
Chen and Stratton then calibrate a model of where this goes. Holding review productivity flat while coding productivity keeps improving, output rises 57.8% by 2031. If review productivity keeps pace with generation, the same model gives 341.4%. Nearly everything depends on the second number, and their measured review productivity is currently −7.0% against coding productivity of +73.7%.
A year of production telemetry, from a company with no reason to flatter the result
The single best dataset on whether any of this is safe comes from Google’s own monorepo, where Tran and colleagues characterised 3.52 million changes over the year to April 2026, in mature production C++.
AI-generated changes required 1.92 times the blocking review feedback of human-written ones. They drew 1.39 times the comments, took 1.24 times the reviewer iterations, and produced roughly 1.3 times the build failures and sanitiser findings.
And then they reverted less often than human code, at about 0.9 times the rate.
Both halves of that matter. The authors’ own conclusion is the most useful sentence I have read on the subject: “existing automated checks and human reviewers successfully catch fatal errors before, or immediately during, deployment. The true cost of AI generation, therefore, shifts from acute reliability failures to chronic maintenance and operational burdens.”
Review and automation worked. They cost roughly double the senior attention per change, and the bill did not disappear — it moved from outages to maintenance.
One finding in that paper deserves more attention than it has had. Google found no clear correlation between how much review effort a change received and whether inefficient generated code survived into the submitted revision. Their words: “human reviewers struggle to consistently intercept these localized inefficiencies regardless of review depth.” Review is not a uniform filter. It is sharply effective against some defect classes and close to blind against others, which brings me to the part of this argument that most firms in our position would leave out.
What code review actually catches is less than almost anyone assumes
If our pitch were simply that we review everything, the research would embarrass us.
The only controlled experiment I could find that measures human security review against known ground truth is Edmundson and colleagues, who gave 30 professional developers a web application containing seven planted vulnerabilities. The average reviewer found 2.33 of them, about a third. One in five found nothing at all. Nobody found more than five of the seven. Reviewers reported an average of 6.29 vulnerabilities to get those 2.33 right, so most of what came back was noise, and years of security experience correlated negatively with the accuracy of a reviewer’s report.
The pattern repeats at scale on real defects. A case-control study of Chromium OS examined 890 commits that introduced vulnerabilities and found that whether review caught one depended overwhelmingly on its class. Dangerous-function defects were caught every time. Improper input validation was missed in about 88% of reviews, improper access control about 88%, and insufficient verification of data authenticity in 100% of cases. The authors note, with evident surprise, that “the overall reviewing experience of a developer does not increase his/her ability to identify security defects.”
Meanwhile Beller and colleagues classified more than 1,400 review-driven changes and found a 75:25 split between maintainability fixes and functional problems. And the canonical modern result that review coverage reduces post-release defects failed replication in 2020, whose authors concluded that “review measures are neither necessary nor sufficient to create a good defect prediction model.”
A single human reading a diff is a weak filter. That is not an argument against review; it is an argument against treating review as one thing. The defect classes review misses — input validation, access control, authenticity checks, resource inefficiency — are precisely the classes that static analysis, fuzz testing, dependency scanning, integration tests and a threat model catch. The classes those miss are the ones a person who understands the business catches. Google’s result holds because its changes pass through all of them, not because its reviewers are superhuman.
So we do not claim that our review catches a given percentage of defects, because no study has ever measured that for AI-generated code and the number would be invented. What we claim is narrower and checkable: our process puts a differently-shaped check in front of each failure mode the research actually documents.
Where the bill arrives: the code that already exists
Almost every optimistic figure in this field was measured on new code. Most software work is not new code.
A study published on 29 October 2026 took 100 legacy PHP files from WordPress 4.0 and asked five frontier models to modernise them for PHP 8.3, scoring the results against 630 hidden behavioural checks. Left completely untouched, 83 of the 100 files already passed every check. The best model left 59 passing. Each model broke between 32 and 51 working files while repairing at most 10. The deterministic rule-based tool Rector broke 7 and repaired 6.
The detail that makes it worse: only 37 of 511 flagged modernisation findings, about 7%, actually required a change under PHP 8.3 at all. The models were mostly breaking code that did not need touching. Fair caveat — the models got one file at a time with no project context and no test feedback, so this is a floor for agentic workflows rather than a measurement of them.
Agentic migration does better and still not well. FreshBrew benchmarked Java 8 to 17 migrations across 228 real Maven repositories; the best agent finished about half. Its authors also report that “a significant portion of apparent successes would have been classified as reward hacking without integrity checks” — including an agent that edited pom.xml to exclude the failing tests from the build.
Google does run AI migrations at enormous scale, and the contrast is the lesson. In its int32-to-int64 Ads migration, 80% of code modifications in landed changelists were fully AI-authored. Its follow-up paper covers 39 migrations over 12 months with 595 changes and 93,574 edits — reviewed by 306 reviewers across 149 teams. The same paper states plainly that “the reported 50% time savings is based on developer perception and estimations, and not on precise time tracking data”, and that “in most cases, the human needed to revert at least some changes the model made.”
Strip away the monorepo, the exhaustive test coverage and the three hundred reviewers, and you get the PHP result.
The maintenance cost is measurable after merge as well: across 6,774 merged agent pull requests against 5,044 human ones in the same repositories, agent changes attracted verified follow-up fixes at 1.62 times the odds of human ones.
Security did improve this year. It is still nowhere near shippable
Veracode’s Fall 2026 update, published on 29 October, is the current figure and it supersedes the numbers in wide circulation. The average security pass rate across 18 models rose to 62%, up from 56% in July. The best models now reach 73%.
Which means a little under two in five generated samples still fail. The structural finding has not moved: syntax correctness sits near 100% while security sits at 62%. Code that compiles, runs, passes its tests and looks right is the normal output of a model that has written an exploitable defect.
The breakdown decides where to look. Broken cryptography passes 87.4% of the time and SQL injection 83.7%, both well handled. Cross-site scripting passes 18% of the time and log injection 12.6%. By language, Java sits at 31% against Python’s 64%. And models specialised for coding score worse on security than general-purpose ones, 51% against 54%.
What that looks like in production: on 2 February 2026, Wiz Research disclosed that Moltbook, whose founder said publicly he had written none of the code, had exposed 1.5 million API tokens and roughly 4.75 million records through a client-side key with no row-level security. A missing access-control policy — the defect class the Chromium study found human review misses about 88% of the time, and which a five-minute automated check catches every time.
“So you’re selling the bottleneck”
The sharpest objection to everything above is that we are the constraint we are describing. Senior review time is scarce, we are proposing to sell it, and Chen and Stratton found that 82.8% of code reviews happen in codebases where the reviewer had already worked. An outside firm looks like the worst-positioned reviewer in the room.
I went looking for the evidence that would settle it, and the honest answer is in three parts.
The 82.8% figure does not mean what the objection needs. In that paper “familiar” means the reviewer had made at least one prior commit or opened one prior pull request in the codebase. It is a threshold an external engineer clears on their first merged change. The paper uses the statistic to argue that labour is not freely reassignable between writing and reviewing — and it contains no analysis of review quality by familiarity at all.
Where it has been measured, unfamiliarity is where AI helps most. METR’s authors say their slowdown does not generalise to unfamiliar codebases. The only randomised trial that put professional engineers into code they did not know — Google’s own, by design — measured them going faster with AI, and found prior domain expertise did not predict completion speed at all.
And nobody has measured the thing the objection actually asserts. There is no study showing that a reviewer unfamiliar with a codebase catches fewer real defects. Chen and Stratton measure who gets assigned; the Chromium work finds reviewer experience does not predict detection; the usual citation for familiarity driving review quality is a perception survey of 88 Mozilla developers. So the correct answer is that this is unmeasured, not that it is settled in our favour.
What the research does identify as the real constraint is standing and bandwidth rather than knowledge. One of Chen and Stratton’s interviewees describes a team where “only one senior engineer was allowed to approve changes because he was the expert on the codebase.” A single approver is a queue, and a queue is the thing their model says decides whether any of AI’s gains arrive.
What this means for how we work
Two of our four leads carry principal titles, in data and BI engineering and in backend and systems. Behind them are senior backend engineers in Python, Go and TypeScript, senior data engineers across Databricks, Spark, Snowflake, Fabric, Azure and AWS, senior data analysts, mobile engineers and designers. Who does what is on the about page, and it matters here only because the research says the scarce input is senior attention, and that is most of what we are.
We write with Claude Code and we are fast with it, in the places the evidence says speed is real: new services, scaffolds, test harnesses, one-off migrations with a reversible path, and work in stacks we have not touched for a year. We are slower and more careful in exactly the places the evidence says to be — inside a large system somebody depends on, where the model has thin context and the cost of being subtly wrong is not a failed build but a quiet defect.
Then the generated change goes through gates chosen against the failure modes above, not against a template:
Automated analysis first, because static analysis, dependency scanning and the test suite catch input validation, injection and resource defects more reliably and far more cheaply than a person reading a diff. Then a human review by somebody who did not write the change, aimed at the things tools cannot judge: whether the approach fits the system, whether the abstraction will survive the next feature, whether the code says what it means. Then a security pass for anything touching authentication, authorisation, money or personal data, because access control and authenticity checks are the classes the Chromium study shows ordinary review misses almost entirely. Then a discussion for anything architectural, because the expensive mistakes in our work are design decisions that were never explicitly made.
None of this is novel and that is the point. DORA’s 2025 report found AI’s relationship with delivery throughput had turned positive while its relationship with delivery stability remained negative, and named the cause as change volume outrunning weak testing, version control and feedback loops. DORA’s conclusion is that AI acts as “an amplifier” of the strengths and weaknesses an organisation already has. Teams with the discipline get faster. Teams without it generate their existing problems more quickly.
Worth naming the cost honestly, since Google publishes it. DORA’s own ROI calculator returns 39.2% first-year return on its shipped defaults, with payback at 0.7 years — and prices a J-curve productivity dip of 15% over three months at $3.3 million, which is 39% of the total first-year investment it models. It also prices the stability cost of deploying more often at a slightly higher failure rate at $344,000 a year for a single service. DORA says to treat all of it as “a high-uncertainty estimate meant to spark a conversation”, and its calculator assumes a 5% change failure rate when its own survey puts the median organisation in the 8–16% band.
The thing that gets built is still only the beginning of what it costs. Something has to maintain it, upgrade it when a runtime goes end-of-life, patch it when a dependency is found vulnerable, and still be comprehensible to whoever picks it up in two years. The fourth WordPress plugin and a monolith split that fails at the database are both the same lesson from before any of this: the build is the cheap part.
GitHub, reporting the number this article opens with, put the conclusion better than I can. Agents now start more than 40% of pull requests, and “someone still has to decide whether it works, whether it belongs, and whether it’s good.”
If you are shipping faster than you can check, that is the problem worth solving, and it is one we would rather talk about honestly than quote a number at.