A payments company running 57 million lines of code just published real numbers on AI across its development lifecycle: adoption, merge requests, token spend, and the point at which the bottleneck moved. Here is what is worth copying, and what the numbers actually say.
Most public statements about AI in engineering are a press release with a multiplier in it. Earlier this month Tom Adams, CTO of Adyen, published AI in our development lifecycle, and it is a different kind of document: a public company putting denominators next to its claims, naming the things that broke, and describing the systems it had to build afterwards.
That makes it the most useful engineering artifact I have read this year. Not because the numbers are spectacular, but because they are plausible, and because they land almost exactly where the measurement data points.
The scale first. Around 57 million lines of code across monorepos for backend, frontend, data and infrastructure. In the last 90 days, CI ran 13 million jobs across more than a million pipelines, which they put at 126 years of compute time. In the same window, AI edited roughly a million files and co-authored 20,000 commits. Half of AI code review comments are accepted by developers. Roughly 1,400 developers consume about a trillion tokens a year, a figure that quadrupled in three months.
Then the outcome numbers, which are the ones to sit with.
Figure 1. Adyen’s reported chain from adoption to value. The 15% figure comes from DX developer surveys, and they note explicitly that they ignore larger step-change gains when computing the return.
Read that honestly and it is a strong result delivered without hype. A 48% lift in merge requests per developer is large. It is also an input measure, and they say so: a 2x return calculated off the conservative self-reported number, not off the 10x anecdotes. They mention those too, including a refactor of about 2,000 production jobs across 40 card schemes that would normally take 6 to 12 months across several teams, done by a couple of engineers in two months with no incidents.
That restraint is the tell of a real measurement culture. If your organization only ever reports the 10x story, you do not have a measurement culture, you have a highlight reel.
The sentence in this piece that should stop every VP of Engineering is the one where they state plainly that within their teams the bottleneck has already shifted from code generation to code review, with review turnaround times rising and pushback per review increasing.
This is the prediction that falls out of basic queueing theory the moment one stage of a pipeline gets an order of magnitude faster, and here it is observed in production at a company processing more than a trillion euros a year.
Figure 2. The shape of an AI-native delivery pipeline. Generation capacity expands, review capacity is still gated on human attention, and the constraint moves downstream.
Every stage you accelerate hands its scarcity to the next stage down the line.
Their answer to the review problem is the part I would steal first. They are piloting a system that uses AI to classify the risk of every merge request as low, mid, high or unknown, against explicit criteria: fault likelihood, critical-flow impact, security, behaviour change, reversibility, rollout safety, plus repository-specific rules.
The insight behind it is one that predates AI. Review effort has never been proportional to change risk. A one-line change can be a typo or a security hole, and reviewers have historically allocated attention by arrival order rather than by blast radius. When volume was human-limited that was merely wasteful. At agent volume it is dangerous.
Figure 3. The risk tagging pattern Adyen is piloting. Lane treatments on the right are my illustration of how the classification translates into review policy.
The second thing worth copying is architectural. They report that their twenty-year bet on monorepos turned into a strategic advantage once agents arrived, because frameworks sit beside the services that use them and documentation sits beside code, which makes context gathering immediate. They also name the limit honestly: it breaks when an agent has to cross from backend to data to infrastructure, and they have not solved that yet.
On top of that they built Architect, which stitches three graphs together.
Figure 4. Architect, as described by Adyen. The point is not the graphs individually, it is that static structure and runtime reality are joined and exposed to agents through the same interface humans use.
Their framing for why this matters is the sharpest line in the piece: coding is not engineering. Quality is an emergent property of code, architecture and runtime behaviour together, and AI amplifies both the good and the bad decisions feeding into it. An agent with a great model and no system context will confidently produce a locally correct change with a globally terrible consequence.
Three shorter observations, each of which I expect to become a standard problem.
Resource sprawl. Monorepos made it easy to share skills, subagents, hooks and commands, and then that turned into a pollution problem: too many resources, too little governance, slower workflows and wasted tokens. They built an Agent Marketplace as a single source, defined in git, materialized per harness, and aware of the user’s team and role. Anyone who has watched a company accumulate 400 unreviewed prompt files will recognise the failure mode.
Token policy. Their position is that “Tokenmaxxing is fundamentally the wrong incentive”, because usage is gamifiable in exactly the way lines of code were, and reflects consumption rather than value. Hard caps miss the point in the other direction. What they run instead is a default limit with unlimited top-ups approved by team leads, alongside semantic routing and bring-your-own-model on in-house inference infrastructure. They recently doubled the defaults and are planning for ten times the current volume.
Figure 5. Token trajectory for roughly 1,400 developers, with the model tier split they report. Quadrupling in a quarter is the number to hold next to your own finance forecast.
The human cost. They are candid that heavy AI users produce twice the merge requests of same-seniority peers, and equally candid that this is a noisy proxy. They flag rising cognitive load and context debt among engineers orchestrating several agents at once. They note that junior engineers now find it harder to build intuition, and are moving mentorship toward system design, code evaluation and architectural decisions much earlier. They run an AI Champions group of 40 expert users to translate general capability into workflows for specific product areas. And they observe frontend and backend roles converging back into full-stack.
| Question | What most orgs can answer | What Adyen can answer |
|---|---|---|
| Adoption | Number of licences purchased | Effective adoption across engineering, files edited, commits co-authored |
| Quality of AI output | Nothing systematic | Acceptance rate of AI review comments |
| Throughput | Anecdotes and a demo | Merge requests per developer, against a baseline |
| Return | A vendor’s multiplier | A conservative return computed off surveyed time savings |
| Where the constraint sits | Unknown | Named explicitly: review turnaround and pushback per review |
| Risk | Review in arrival order | Risk classification per merge request, with defined criteria |
Six things I would act on this quarter:
Adyen can write this post because they instrumented the transformation while it was happening. The 48% and the 15% and the acceptance rate were not reconstructed afterwards from a vendor dashboard, they came from their own data and their own developer surveys. Any organization can copy the risk tagging idea or the graph architecture. Very few can currently produce the baseline that would let them prove either one worked.
My read is that the industry is about to split into two groups. One knows what its agents are doing to its codebase, its cycle time and its people, and can defend the number in a board meeting. The other has a licence count and a good story. Both will have access to the same models.
Source: Tom Adams, AI in our development lifecycle, Adyen Knowledge Hub, 3 September 2026. All figures attributed to Adyen are drawn from that article. Figures 1 to 5 are my own visualisations; lane treatments in Figure 3 and the model tier framing in Figure 5 are my interpretation rather than Adyen’s stated policy.
Ready to unlock your SDLC productivity?
