On this page
You bought the AI coding tools.
Every engineer has access. The usage dashboards are green. The model is the latest one. The vendor’s case study suggested a 25% throughput increase. The CFO is asking when the ROI will land.
A year later, the answer is uncomfortable. Some teams are visibly faster. Others are not. Across the organisation, the delivery metrics look roughly the same as they did before, and the engineering leaders cannot explain why.
This is not a tooling failure. It is a platform failure that the AI investment has just made expensive enough to notice.
What the DORA Data Actually Says
The 2025 DORA report on AI-assisted software development is the most credible study of where AI tooling actually produces value in engineering organisations.
The headline finding is simple and uncomfortable: AI is an amplifier.
Organisations with strong delivery systems convert AI investment into measurable throughput. Organisations with weak delivery systems convert AI investment into a larger inventory of code that they cannot safely release. The tooling is the same. The systems around it are not.
This is not a finding about individual engineer productivity. Engineers using AI tools individually generate code faster, almost universally. The question is what happens to that code afterward.
If your platform supports fast feedback, self-service deployment, automated testing, and clear ownership, more code at the top of the pipeline produces more shipped software at the bottom. If your platform does not, the additional code accumulates in pull requests, fails on inconsistent environments, gets queued behind manual approvals, and waits for a human to debug failures that the tooling created.
AI tools do not create the bottleneck. They expose it.
Where AI Productivity Actually Stalls
When engineering leaders look honestly at where AI-generated code slows down, the same set of points appear:
Code review
A team generating twice as much code creates twice as many pull requests. Code review capacity, which was already a constraint in most engineering organisations, becomes the binding constraint immediately. Reviewers are still humans, reviewing at human speed, and the rate of incoming review requests now exceeds the rate at which review can be performed credibly.
This is the first place AI investment hits a wall. Most organisations notice it within the first three months.
Deployment
If deploying a service requires a platform engineer to be involved, AI-generated code arrives at a queue rather than at production. The deployment pipeline becomes the limit on throughput, and AI has not made the deployment pipeline faster.
This is what platform engineers mean when they say AI productivity is gated on self-service. Without it, the deployment line is the same length as it was before, but the line is longer because there is more code waiting to use it.
Environment provisioning
AI-generated code often needs new resources: a database, a queue, a configuration change, an environment variable. If those require a ticket, every AI-accelerated piece of work converges on the same manual process and waits there.
Testing and feedback loops
A team generating more code needs faster confirmation that the code works. If the test suite takes 45 minutes to run and the deployment to a non-production environment takes an hour, the AI productivity gain is dwarfed by the wait time on validation. Slow feedback turns AI into a slower iteration loop, not a faster one.
Ownership and accountability
AI-generated code that produces a production incident creates a question that the platform does not currently answer: who owns this? If the model wrote it, the engineer prompted it, the team approved it, and the platform deployed it, the accountability chain is unclear. Organisations without strong ownership models discover this the first time an AI-related incident happens.
The pattern across all five: AI accelerates an early stage of the pipeline. The later stages of the pipeline become the constraint. The total throughput is determined by the slowest stage, not the fastest.
The Executive Pattern
Engineering leaders rolling out AI coding tools tend to follow a similar trajectory.
In the first quarter, individual engineers report that the tools are useful. Adoption rises. The vendor’s metrics look good. Leadership briefs the board on the productivity narrative.
In the second quarter, throughput at the team level is flat or marginally up. Most leaders attribute this to ramp time and assume the gains are coming.
In the third quarter, the throughput metrics still have not moved meaningfully, and the conversation becomes defensive. The investment is justified on the basis of individual engineer experience rather than on shipping outcomes.
By the fourth quarter, the question becomes uncomfortable: is the tool not working, or is the system around the tool not working? Engineering leaders who can answer that question precisely are in a much stronger position than those who cannot.
The DORA finding is the answer. The tool is doing what it was supposed to do. The system around the tool is what determines whether that work converts into shipped software.
What the Platform Has to Provide
For AI coding investment to actually produce delivery gains, the platform underneath it has to do several specific things well. None of these are new platform engineering capabilities. The AI tooling has just made them load-bearing in a way they were not before.
- Self-service deployment. If shipping a service requires platform team involvement, AI throughput will be capped at the rate the platform team can absorb deployment requests.
- Fast and reliable test feedback. Slow tests delay every iteration. Flaky tests waste every iteration. Both compound with higher code volume.
- Automated environment provisioning. Each PR needs a place to run. Manual environment setup is a per-PR tax that scales with volume.
- Code review tooling that scales. Reviewing more code in the same time requires automation: static analysis, AI-assisted review, policy enforcement, and clear escalation rules for when humans need to be involved.
- Clear ownership models. Every service, every workload, and every deployment has a named owner who is accountable for what happens when it breaks.
- Production observability that catches problems quickly. When AI-generated code produces incidents, the time to detect and roll back is the limiting factor on how aggressively the organisation can ship.
These are not new ideas. They are the standard list of mature platform engineering capabilities. What AI tooling has done is to take an organisation that could previously get away with one or two of these being weak, and make them all load-bearing simultaneously.
How to Talk About This With Leadership
The framing that lands with non-technical executives is straightforward: AI coding investment is a multiplier. Multiplied by a strong delivery system, it produces faster shipping. Multiplied by a weak one, it produces faster generation of work that cannot ship.
The board does not need to understand pipelines or pull requests. They need to understand that the tool is not the investment. The system the tool sits on is the investment.
The practical consequence: every dollar spent on AI coding tools should be matched, at some level, with investment in the platform that lets the resulting code ship. Organisations that do this see the throughput gains. Organisations that do not, do not.
This is also a useful frame for justifying platform engineering investment that was previously hard to justify. Platform work that was historically described as “developer experience” can now be described in language the board recognises: it is what makes the AI investment pay back.
The Caveat
This is not an argument against AI coding tools. The tools work. Engineers are more productive using them. That is real.
The argument is that the productivity gain is asymmetric, and the asymmetry is determined by the platform. Organisations with strong platforms get more out of the tools, faster. Organisations without strong platforms either do not see the gains, or see them late and partially.
The question is not whether to invest in AI tooling. The question is whether the underlying delivery system is ready to convert that investment into shipped software.
The Takeaway
The premise of AI coding tools is that the bottleneck in engineering organisations is the time spent writing code. For most organisations, this is not the bottleneck. The bottleneck is everything around the code: review, deployment, testing, ownership, environments, approvals.
AI tools accelerate the part of the pipeline that was already fastest. The slow parts, untouched, become the new constraint. The total throughput is set by the slowest stage, not the fastest, and the math has not changed because the tools changed.
The organisations that will look back on AI coding investment as a success are the ones that paired it with the platform work to absorb the additional volume. The organisations that will look back on it as a disappointment are the ones that bought the tools and assumed the platform would adapt on its own.
If you are early enough in your AI tooling investment to make this choice deliberately, we can help you decide where the platform investment actually needs to land.