We have all been in this board meeting recently.
You put up the slide showing that 80% of your engineering team has adopted AI coding assistants. You share anecdotes about how much faster developers are writing boilerplate. Then the CFO looks at the delivery metrics and asks the question that ruins the afternoon:
"If everyone is coding faster, why hasn't our roadmap accelerated?"
It is a fair question. And the data backs up the CFO's skepticism.
In an NBER working paper surveying nearly 6,000 senior business executives across the US, UK, Germany, and Australia, the findings were sobering:
89% of executives reported no impact of AI on their firm's labor productivity over the past three years.
That doesn't mean AI is failing. It means we are confusing AI adoption with AI operating leverage.
Local Speed vs. Company Throughput
When we first rolled out AI coding tools to our teams, we made the same mistake everyone makes: we thought faster typing meant faster shipping.
Developers love these tools. They help them understand unfamiliar code, generate tests, and stay in a flow state. But the software development lifecycle (SDLC) is a factory floor. If you make one workstation 10x faster, but the assembly line still bottlenecks at QA, product review, and deployment, the machine is a waste of money.
Local speed only becomes company throughput when it translates to:
- Priority work shipping sooner
- Fewer requirement gaps
- Less product-engineering translation loss
- Less rework after PR review
- More predictable releases
If those outcomes don't improve, you just have more AI usage. You don't have better business performance. Motion is not throughput.
Why Productivity Stays Flat
The NBER result makes perfect sense when you look at how software is actually built in the enterprise.
AI coding tools optimize the act of generating code. But most of our delivery drag doesn't come from typing speed. It comes from:
- Vague Jira tickets
- Incomplete acceptance criteria
- Unclear ownership between product and engineering
- Missing technical plans
- Architecture drift
- Late discovery of requirement gaps
When those problems exist, AI doesn't fix them. It accelerates them.
A vague ticket becomes incorrect code faster. A missing test plan becomes a faster path to rework. An agent with partial context confidently implements the wrong thing. And we still discover critical gaps on a Friday afternoon PR review, after most of the expensive work has already been done.
The Missing Link Is an Operating Model
Buying licenses creates access. It doesn't create a system.
To get real operating leverage, we need an AI-native delivery operating model. We need a system that can:
- Turn vague work items into structured, approved intent
- Translate that intent into technical plans and test plans
- Give coding agents the right context at the right time
- Check implementation against the approved artifacts before the PR
- Measure whether intended outcomes were actually delivered
Without that layer, AI remains trapped inside individual sessions and individual power users.
What We Should Be Asking
The right executive response isn't to cancel the AI licenses. The right response is to ask harder operational questions:
- Are we measuring AI activity or delivery outcomes?
- Do teams have approved intent before coding begins?
- Are coding agents working from governed context or local, ad-hoc prompts?
- Can we see where rework and requirement gaps are occurring?
These questions matter more than license counts.
At Amulent, we built CodeMerlin because we lived this pain. CodeMerlin is the operating layer around AI software delivery. It turns a Jira ticket into a structured Spec, gets product and engineering to agree on intent, and feeds that approved context directly to the coding agents.
The goal isn't just to write more code. The goal is to define the right work, distribute the right context, verify the output, and measure the result.
That is how AI stops being a promising tool in isolated workflows and starts becoming a productivity system for the business.