Earlier this year, we shipped an AI product for a client. A virtual assistant sitting over their vast proprietary HR and tax data, built on Bedrock, in a regulated context where mixing up "guidance" and "advice" is a legal problem rather than an embarrassing one.
Six months, on time and on budget, with adoption coming in at nearly twice what anyone had projected inside the first ten days (projections being projections, but still). A piece of work we're particularly proud of [8].
The release itself was…dare I say it…boring?
It went out like any other change. There were no emergency incident rooms and our engineers quietly moved on to building on other projects. All was quiet. That sounds like a small thing to write an article about, right? That's the whole point.
The reason it was boring is that we'd spent the front half of the engagement building the platform underneath it. We expanded the underlying infrastructure, put pipelines in place and enabled a deployment path such that releases were a non-event. When developers were ready to deploy, friction was reduced to a minimum.
I've been thinking about that release a lot, because it isn't the experience most people seem to be having at the moment.
Faros AI published delivery telemetry this year covering 22,000 developers across more than 4,000 teams, comparing each team's two quarters of lowest AI adoption against its two quarters of highest. Task throughput per developer went up 34%. Deployments per week went down 11% [1].
But wait, we need to double check these. Those are different denominators, one per head and one per organisation. Shrinking the headcount alone would pull the two figures apart. Fewer deployments can still ship more, if each release is bigger. That second objection is the interesting one, because bigger batches are exactly what you'd predict when a queue forms and bigger batches are the worse outcome rather than the neutral one. Small, incremental releases are what we're after.
Some more stats from the report: Median time in review rose 441%. The rate of pull requests merged with no review at all rose 31%. Incidents per pull request rose 243% [1]. All very big, scary numbers (especially for platform engineers).
LinearB looked at 8.1 million pull requests across 4,800 teams and found unassisted ones merge inside thirty days about 85% of the time, against 32.7% for AI-generated ones [2]. There are theories as to why. AI-generated code could be produced at a lower quality, or there could be an increase in the amount of throw-away code, given the access to quick experiments developers now have. They also don't publish how they decide a pull request is AI-generated. Either way, two thirds of that work isn't merging within a month, let alone shipping to Production [2].
Sonar asked 1,149 developers last October whether they trust the output of AI-assisted code. Four (4!) percent completely agreed that AI-generated code is functionally correct. Forty-eight percent completely agreed that they always check it before committing. “Completely agree” was the highest answer on a scale of 5 (completely disagree to completely agree), so the metrics actually undercount: plenty of the other developers agree a bit, they just didn't tick "completely". Sonar's own press release runs the same data the other way round, as "96% don't fully trust AI code", which sounds far more alarming and means exactly the same thing. Take the direction, not the number [3].
DORA's 2025 research, around 5,000 respondents, found AI adoption positively associated with software delivery throughput, reversing their 2024 finding. Having said that, the negative association with code stability held [4].
DORA is perhaps the most authoritative dataset in the field and it doesn't say what I've just said.
The same Faros report also shows pull request merge rate per developer up 16.2%, sitting in the same chart as the two numbers I opened with, pointing the other way [1].
So how do we make sense of this? Partly it's in the method. DORA asks people how delivery feels. Faros measures what the systems themselves emitted. Faros makes this argument [1]. When we see a divergence between perception and telemetry metrics, that gap tells us something more than either number alone.
It could be to do with averages. DORA's positive is a mean across the whole sample, and means hide splits. Their own work is clear that the gains land in loosely coupled architectures with fast feedback and disappear in tightly coupled systems with slow processes [4]. Averages are perfectly capable of hiding a disaster. If most teams get a bit faster and a smaller group gets dramatically slower, the average still moves up, and the report still says AI adoption is working. It is working, for most of them. That's no comfort at all if you're in the other group.
None of which means AI adoption doesn't work. We've seen it work, in the release I opened with. We can think of two separate buckets here - one containing systems which absorb the extra load placed on them thanks to AI code generation, and one that can’t. The starting point is to work out which bucket your system fits into.
What skills do your engineers actually need now?
AI genuinely creates efficiencies, but it changes what “good” looks like for an engineer. Writing code quickly is no longer the differentiator it used to be. What matters now is:
If you’re planning your team’s development this year, this is the gap worth closing. Engineers who can direct and interrogate AI will outperform engineers who simply prompt it and move on.
Goldratt's line in The Goal is that an hour saved at a non-bottleneck is a mirage, while an hour lost at a bottleneck is lost for the whole system [7]. It’s a common thing we see in consulting - we think we’re addressing the right thing, but in reality we don’t address the constraint and the system throughput stays static.
It's worth being careful here, because the next bit is the part people skip. Goldratt's actual point is that the constraint moves. You relieve it in one place and it turns up somewhere else. This is what's supposed to happen and is normal. If writing code genuinely was the bottleneck for some teams, then relieving it and surfacing, say, the review stage as the next one, is precisely what was supposed to happen.
The mistake that organisations make is that they delay focusing on the right constraint. It’s understandable - if we can all of a sudden create more code more quickly, surely we can ship features faster. I think more succinctly, and backed by lots of conversations I've had with clients and commentary across the industry, the code was never the problem.
For most organisations, code generation was never the blocker. It feels expensive because you have to pay a team to do it, but in reality it was in code review, in cumbersome test environments, in painfully long build times, in bureaucratic release processes, in the on-call rota that picks up whatever bugs get through.
As an industry, we bought a tool that makes the keyboard several times faster and pointed it at everyone at once.
So what happens next? We see work in progress expanding and reviews taking longer (exhausting reviewers who have so much more to review). Quality decreases as a result. Rubber-stamping PRs becomes a viable option because how else are we going to get these features shipped?
Our co-founder Sandro Mancuso wrote about this earlier in the year: when asked what the natural response to a massive pull request is, his answer was "Skimming, or worse, rubber-stamping." He also wrote, in the same piece, that software productivity is a property of the system rather than the speed of an individual developer [6].
So let's be specific about what that system is.
Bence Tóth at Zendesk has a name for this. Absorption capacity: an organisation's ability to define problems clearly, integrate changes into a broader system, verify they behave correctly, and turn implementation into dependable value. His argument is that it becomes the binding constraint once code itself is abundant. I wholeheartedly agree, and I think it's the right way to think about technology systems generally [5].
What I'd add is where it lives.
By platform, I don't mean a developer portal (nobody's absorption capacity was ever fixed by a portal). I mean everything between a developer finishing a change and that change running safely in production. Environment provisioning, test execution and feedback, build and deploy, secrets and access, policy and compliance, observability - all the standard things we’ve been recommending since we started.
Look at the queue again with that in mind. Environments are either self-service or a ticket shipped off to another team. Test feedback arrives in four minutes or forty. Deployment is unremarkable or it needs an incident room. Each one is something the platform either handles or hands to a person and each one is now taking several times the load it was designed for.
Now, the obvious objection: a platform engineer says the answer is platform engineering. I know. So let me argue against myself for a paragraph.
If your constraint is product management picking the wrong things to build, no paved road on earth will help you. If it's one team's test suite while everything else is fine, that's a team problem and not a platform improvement programme. If your engineers are shipping steadily, your incident rate is flat and your review queue hasn't budged, then you don't have this problem and you shouldn't let anyone sell you a cure for it. If the honest answer is that you've got too many engineers pointed at too little strategy, a better platform will just help you do the wrong thing faster.
DORA also found that 90% of organisations already have some kind of internal platform and 76% have a platform team [4]. So having one isn't the differentiator. What matters is whether it can absorb what you’re trying to push through.
On that, DORA's platform engineering page is worth quoting directly: where platform quality is high, the effect of AI adoption on organisational performance becomes strong and positive, and where platform quality is low, that effect is negligible [4].
Not any smaller, but negligible. It's cross-sectional survey data and it's correlational, with the usual conflict that the same person rated both their own platform and their own performance. It's still the most useful finding published about AI that I’ve read since this step-change started. Almost everything else tells you whether AI works. This one tells you what has to be true for it to work for you.
At huge risk of denigrating months of hard effort from our engineers, the release I opened with happened on comparatively clean ground. We executed a strong Product vision, on a technology stack set up with strong foundations. It's the straightforward version of this problem, and if your estate looks like that then you were probably going to be all right anyway.
Most organisations aren't starting there.
Nearly everything published about AI-ready platforms assumes a tidy Kubernetes estate, loosely coupled services and fast feedback. How many of you have scanned reference architectures and thought "I'm so far away from this, where do I even begin to start?". I have, many a time.
Most enterprise systems just aren't that. They're fifteen-year-old monoliths with a ninety-minute test suite and a release process involving spreadsheets or change approval boards. Each one is a heavily customised package that no one knows how to fix.
Those types of systems have the lowest absorption capacity going. They're also under exactly the same instruction to adopt AI at pace as the digital natives. The pressure is coming from the same sort of board meeting. That combination, rather than the state of the system itself, is where the churn and the incident numbers come from. We’ve been asking for investment for years, and are now seeing exactly why it was needed.
In brownfield, your first platform investment is feedback time. Not self-service and definitely not a portal. A ninety minute test suite was survivable when a developer produced three changes a day, because the loop was slow against the pipeline but fast against the developer. At AI authoring speed, it becomes the thing that sets your throughput. You can make all the changes you want downstream, but it will have no effect. Are you running the right tests at the right boundaries? Do you parallelise them where possible? Do you need the tests at all?
It's unglamorous and it doesn't demo well. It's also the highest-return platform work available in a legacy estate.
We see a lot about portals in the Platform Engineering world. In reality, they represent a nice frontend once you’ve reached the point of a fast-throughput system. If we start with a portal, we just make it easier for people to get going, without removing the constraints. The net result = a negligible effect on throughput.
Baseline before you scale adoption any further. You may already track deployment frequency and lead time. Add extra measures that expose the constraints: time in review, review-to-merge rate, proportion merged without review, rework and churn, incidents per change, time to provision an environment.
Then compare it against yourself, before adoption ramped.
Not against industry benchmarks and not against whatever unassisted work you have left either. With 90% of developers now using AI daily, that control group is disappearing, and what's left of it isn't comparable anyway. People reach for AI on greenfield and boilerplate, and leave it well alone on the gnarly legacy module they've known for six years. You'd be comparing different work, not the same work done differently.
Your own history is the most revealing comparison. Pull the same measures for the quarters before adoption ramped and the quarters since. That's what Faros did, and those metrics should be available to anyone with eighteen months of data in a consistent tool [1]. It isn't perfect, because plenty of other things probably changed over that timeframe, so it’s worth acknowledging when presenting. It’s better than nothing though, and it's the only evidence that turns "we think there's a problem" into something a board will act on.
None of this is new, by the way. It's value stream management, and we've been advocating it for as long as we've existed. The well-understood value stream holds true. We just see the constraints more pronounced in agentic development.
So focus on the constraints first before addressing code generation. It’s worth noting the Faros conclusion here: the code arriving for review was never ready, which makes it an authoring problem rather than a review problem [1].
Hmm, we’re back to square one again as that points somewhere slightly awkward for a piece like this one. Part of the fix is upstream, in how people work, in context and specification and scaffolding and no platform delivers that on its own (we've written separately about the authoring half of this, if that's the bit you're wrestling with. Read it here).
The part that is platform work is everything the change has to travel through afterwards.
There's a second move available there that hardly anyone is making. While everyone is focussed on how to generate code better and faster, we’ve been looking elsewhere in the value stream. We've built an agent internally that diagnoses and maintains Kubernetes clusters, which is AI aimed at where our constraint actually was (platform engineers doing the same old CLI commands to debug gnarly Kubernetes issues). It’s a lightweight agent which monitors for a list of common Kubernetes errors, before providing a suggested fix, and actioning that fix if approved (or in auto-mode). We save hours of engineer debugging time as a result.
If your absorption capacity is low and you're under pressure to accelerate AI adoption, the honest answer is to slow the adoption down until the platform can carry the load.
Not stop. Slow.
Every extra developer you put onto AI tooling before your platform is ready is going to be adding to the work in progress. You may see increased incidents or an increase in work that never merges. You pay for the tooling and you pay again for the consequences.
I'm not going to pretend that's a brave thing for me to say. "Slow down and fix your platform first" is close to the most commercially convenient sentence a platform engineer could put in front of you and you should weigh it accordingly.
What I would say is that it's a hard thing to do, and that's the bit worth solving. If you're PE-backed, your sponsor wants adoption metrics this quarter, and "we're pausing to fix the platform" is not a sentence that survives contact with an investment committee.
You can keep the rollout where it's working, though. Pause where needed. Put a date on the constraint, show the trend since adoption ramped, name the lagging metric and commit to a measured re-baseline.
Every firm including mine is selling AI acceleration this year, so don't take my word for it. Pull your median time in review for the last eight quarters and put it on a chart. If the line has been climbing since you scaled AI tooling, you already know which end of the flow needs the work.
If this article raises questions your organisation hasn't fully answered yet, you're probably somewhere between "we've rolled out AI tools" and "we're not sure our platform can keep up with them". That gap is where most of the churn, the growing review queues and the incident creep are coming from.
Codurance helps engineering teams build the platform capacity that makes AI adoption pay off: fast test feedback, self-service environments, sound deployment pipelines and the value stream thinking that turns code into safely shipped software. Whether you need a baseline assessment of where your absorption capacity actually sits, or hands-on support fixing the constraint once you've found it, our software craftspeople work alongside your engineers to get you there.
Want to work out which bucket your system falls into? Get in touch with Codurance to start the conversation.
Why isn't AI coding making software delivery faster?
Research from Faros AI and DORA in 2026 shows that while AI tools increase how much code developers produce, they haven't fixed the stages after code is written. Review, testing and release processes absorb the extra volume, so time in review, incident rates and unmerged pull requests tend to rise even as individual output goes up.
What is "absorption capacity" in software delivery?
Absorption capacity is an organisation's ability to take a code change, integrate it, verify it works, and get it safely into production. The term comes from Bence Tóth's work at Zendesk, building on earlier research by Cohen and Levinthal. Once code itself becomes abundant thanks to AI, absorption capacity becomes the real constraint on delivery speed.
Does a platform team fix AI adoption problems?
Not on its own. DORA found that 90% of organisations already have some form of internal platform and 76% have a platform team, but that alone doesn't predict better outcomes. What matters is whether the platform can handle the increased load AI-assisted development places on review, testing and deployment.
Should organisations slow down AI adoption?
Where platform quality is low, yes, pacing adoption is worth considering rather than stopping it outright. Pushing more developers onto AI tooling before the platform can absorb the output tends to increase work in progress, incidents and unmerged code, which costs more than it saves.
What should teams measure before scaling AI tool adoption?
Baseline metrics beyond deployment frequency and lead time: time in review, review-to-merge rate, proportion of pull requests merged without review, rework and churn, incidents per change, and environment provisioning time. Comparing these against your own data before and after adoption is more reliable than comparing against industry benchmarks.
Sam Griffiths is a Principal Consultant at Codurance. He fell into technology after a Geography degree and has spent fifteen years helping organisations navigate cloud transformation, platform engineering and AI adoption. Operating at the intersection of technology strategy and commercial decision-making, he works with clients to identify opportunities, shape solutions and deliver technology investments that create lasting business value.