Why the gains from AI assisted development stall before they reach the P&L

Ask an engineering leader whether AI has made their teams faster and the answer is usually yes. Ask the CFO whether it shows in the numbers and the answer is usually a pause.

Both are telling the truth.

The gains are real

In a randomised controlled trial at Google, developers given AI assistance completed a realistic enterprise task around 21% faster than the control group. Telemetry across more than ten thousand developers points the same way: teams with high AI adoption complete about 21% more tasks and merge close to twice as many pull requests.

This is no longer a vendor claim. It is measured, repeatedly, in controlled settings.

They stop at the edge of the team

The same telemetry study found no significant correlation between AI adoption and improvement at company level. Not in throughput, not in delivery metrics, not in quality.

The distribution tells the story better than the average. Across 28 million workflows, average throughput rose 59% year on year. The median team gained 4%. The bottom quarter gained nothing.

Executives feel this gap without being able to name it. In one 2026 survey, 89% of leaders said AI had increased the speed of work. 6% could point to clear organisation-wide return.

Coding was never the long pole

The explanation is unglamorous. Writing and testing code accounts for roughly 25% to 35% of the time between an initial idea and a product launch.

Double the speed of a third of the process and the end-to-end gain is modest by arithmetic alone. Worse, the accelerated step now finishes early and waits. Capacity that used to be consumed by building is now consumed by waiting for something worth building.

Product management did not accelerate with it

This is where the constraint has landed, and it is the part most operating models have not touched.

Individual product work has absorbed AI quickly. Interviews with product owners across manufacturing, healthcare, insurance and the public sector describe tender assessments dropping from four hours to thirty minutes per document, and backlog bootstrapping from eight hours to two.

And yet the same study found that the number of refinement loops with the team had not changed at all. The product owner got faster. The organisation around them did not.

That is the uncomfortable shape of the problem. Discovery, stakeholder alignment and the decision about what deserves to be built are slow because people are involved in them, and adding a model to one person’s workflow does not change the cadence of a group.

We see the same shape in our own delivery work. On a recent enterprise engagement, a product owner on our team used these tools for the layer around the build: turning workshop notes and raw discussion into a structured set of requirements, and assembling a governance review pack that would otherwise have taken days. It came together in an afternoon and cleared the client’s design gate. What did not move was anything that depended on other people. Where the client had never defined the process, no amount of drafting speed helped.

The number nobody manages

There is a harder version of this argument, and it comes from an unlikely place.

When Google’s DORA team published a model for the return on AI assisted development in April 2026, they were unusually transparent about their assumptions. The headline case shows a 39% return in the first year. That figure rests on four inputs, and one of them is an assumed idea success rate of 33%.

Read that again. In the most rigorous public model of what AI assisted engineering is worth, the return is anchored to the share of product ideas that turn out to be right.

That number belongs to product management. In most organisations nobody measures it, nobody owns it, and nobody is accountable for moving it. Which means the business case for the entire investment rests on a variable the business is not managing.

Doubling delivery speed against a 10% hit rate does not double value. It doubles the speed at which the wrong things get built.

What it takes

Three shifts, none of them a tooling decision.

Treat idea success rate as a managed metric. Not a retrospective observation, a number with an owner, a baseline and a target. It is the denominator under every AI productivity claim an engineering organisation will make this year.

Bring the same leverage to the front of the funnel. Discovery, requirements definition, prototyping and customer feedback analysis are all workable with these systems today. Almost nobody has invested there with the seriousness applied to the IDE.

Build the translator capability into product management. In 2018, McKinsey argued that the scarce role in analytics was not the data scientist but the translator, the person who converts business intent into something technical teams can act on, and converts the result back. They estimated demand in the United States alone could reach two to four million by 2026.

It is 2026. The role is still scarce, and the gap it was meant to close has moved from analytics into the product function.

Where that capability sits matters. Hiring translators alongside product management adds another handover to a process that already has too many. The version that holds is a product manager who carries it directly: close enough to the business to see which problems are worth solving, close enough to the technology to know which of them are now solvable. Most organisations are still staffing the previous generation of the role.

What that role spends its time on also changes. Less of it goes into producing the artifact, more into judging it: whether the framing holds, whether it addresses the real problem, what the draft quietly got wrong. These systems produce a credible first version of almost anything. Deciding whether it is the right one still takes someone who knows the domain, the client and what a good decision looks like.

MULTIPLAI: How we help

At MULTIPLAI, we work at exactly this seam. Our teams sit between business intent and technical delivery, which is where the current bottleneck sits, and we bring both halves rather than one.

We do not start from the tooling. We start from where the constraint actually is, which in most organisations today is upstream of engineering rather than inside it. That means treating idea success rate as something to be governed, giving product management the same AI leverage engineering already has, and building the translator capability that makes the handover work in both directions.

The organisations that get the return will not be the ones with the fastest developers. They will be the ones that fixed what those developers are waiting for.

Sources

Bain & Company (2025) From Pilots to Payoff: Generative AI in Software Development, Technology Report 2025. Available at: https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/

CircleCI (2026) 2026 State of Software Delivery. Available at: https://www.prnewswire.com/news-releases/circleci-publishes-2026-state-of-software-delivery-302691131.html

DORA / Google Cloud (2026) The ROI of AI-assisted Software Development, v2026.1, 22 April. Available at: https://dora.dev/ai/roi/report/

Faros AI (2025) The AI Productivity Paradox, 23 July. Available at: https://www.faros.ai/blog/ai-software-engineering

McKinsey & Company (2018) Analytics translator: The new must-have role, McKinsey Quarterly, February. Available at: https://www.mckinsey.com/capabilities/quantumblack/our-insights/analytics-translator

Paradis, E. et al. (2024) How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944. Available at: https://arxiv.org/abs/2410.12944

Steghöfer, J.-P. (2026) Faster than the Team, Faster than the Customer: Tool Integration, Collaboration, and Organisational Lag in AI-assisted RE, arXiv:2606.01772. Available at: https://arxiv.org/html/2606.01772v2

Atlassian (2026) State of Teams 2026. Available at: https://www.atlassian.com/blog/ai-at-work/why-ai-speed-isnt-delivering-roi-for-cios