More AI code doesn’t mean faster shipping — here’s why
AI coding tools deliver exactly what they promise: faster code. The problem is that code is the output of a single stage. A feature reaching production and delivering value is the team’s actual result. Speeding up one does not guarantee the other.
Illia Smoliienko, founder of Sivense and an industrial IoT practitioner with over a decade of experience, makes the case that most engineering managers are measuring the wrong thing when they evaluate AI’s impact.
The review bottleneck hiding behind the productivity number
A 2025 DORA report from Google Cloud’s research program found that over 80% of surveyed technology professionals believed AI made them more productive. But for code specifically, that productivity has a trade-off: time saved generating code gets spent reviewing it.
One developer produces a large chunk of code in minutes. The reviewer works at the same pace as before. One person’s gain becomes another person’s backlog. As one DORA respondent put it:
“I feel somewhat more productive, but it’s at a cost.”
The output vs. outcome gap in the data
A 2026 CloudBees survey of over 200 technical leaders found that 67% reported a significant increase in code volume, but only 52% saw a corresponding increase in output. More telling: only 31% could tie their AI spending to a concrete business result.
Smoliienko traces this to two compounding mistakes. Managers roll out AI without first diagnosing which stage actually limits throughput. Then they track tasks completed and code written rather than what reaches the user. Activity grows; outcomes don’t keep pace.
Three steps to find the real constraint
The diagnosis Smoliienko recommends is straightforward:
- Map the full path. Walk every stage from “task taken into work” to “feature in production.” Measure active working time and waiting time at each stage. Turn the vague feeling of “we’re slow” into a concrete picture of where delays actually live.
- Focus on the slowest stage. That is the real constraint. By Amdahl’s law, speeding up a stage that represents a tenth of the total path can shorten the path by at most a tenth, even if you cut that stage to zero.
- Diagnose before you automate. A bottleneck at code review is a process problem, not a speed problem. Who reviews? By what rules? Are submissions too large? A bottleneck at requirements means AI will confidently implement a poorly defined task faster. Improving the workflow often matters more than accelerating it.
The test worth running before scaling
Smoliienko offers a simple thought experiment for any engineering leader: if the team started writing code twice as fast tomorrow, what would become the next constraint? If the answer is obvious, you have a clear hypothesis about where to look. If the answer is not obvious, it’s too early to scale AI tooling for the sake of speed alone.
The underlying idea traces back to Fred Brooks’ 1987 analysis of software productivity. Brooks argued that “the hard thing about building software is deciding what one wants to say, not saying it.” Speeding up expression delivers only a marginal gain when the real difficulty is clarity of intent. Forty years later, the math has not changed.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
