BizTechLab — Ideas, Innovation, ImpactBizTechLab — Ideas, Innovation, Impact
Back to Opinion Articles
Opinion #008•4 min read•4 September 2026

AI Is Making Software Development Faster. So Why Does Software Feel Harder to Ship?

We spent years trying to make developers write code faster. Now AI can generate code in minutes — but the bottleneck has quietly moved somewhere else.

Rajnish Kumar

Rajnish Kumar

Editor-in-Chief & Founder

AI Is Making Software Development Faster. So Why Does Software Feel Harder to Ship? — Opinion article hero image

We Solved the Wrong Bottleneck

For decades, "developer productivity" was treated as a coding-speed problem. Faster IDEs, faster compilers, faster frameworks, faster autocomplete — every tool generation attacked the same target: how quickly can a person turn an idea into a diff. AI coding agents are the endpoint of that project. JetBrains' Developer Ecosystem Survey 2026, one of the largest studies of its kind at more than 15,000 professional developers worldwide, found that 90% of them now use an AI coding agent at work at least weekly, and 68% daily. The cost of producing code has collapsed. The rest of software delivery hasn't.

When Code Becomes Abundant

Before AI, a developer's answer to "how long will this take" was measured in the time it took to write the implementation: "three days for this feature." Today the code itself can exist in minutes. What doesn't shrink at the same rate is everything that has to happen after "I wrote it" and before "it's safe to ship":

  • Is it correct, not just plausible?
  • Are the edge cases actually covered, or just the ones the prompt implied?
  • Does it introduce a security issue nobody asked the model about?
  • Does it fit the existing architecture, or quietly work around it?
  • Will the next developer — human or AI — be able to understand it a year from now?
  • Is its behavior in production predictable, or just untested?

Code Generation Became Cheap. Verification Didn't.

The data backs this up in a way that's hard to wave off as anecdote. Faros AI's "Acceleration Whiplash" report — telemetry from 22,000 developers across more than 4,000 teams, tracked over two years — found real throughput gains from AI: task completion per developer up 33.7%, epics completed per developer up 66.2%. But the same telemetry shows the downstream cost of that speed. Bugs per developer are up 54%. The incidents-to-PR ratio has more than tripled. The median time a pull request spends in review is up 441.5%. Average PR size is up 51.3%, touching 59.7% more files each. And 31.3% more PRs are now merging with no review at all — a gate only works if the gatekeeper isn't buried under an avalanche. The bottleneck didn't disappear; it moved from the "write" column to the "trust" column. The next software engineering bottleneck isn't writing code. It's trusting what was written.

The New Engineering Tax

Every gain on the output side is now paired with a corresponding tax somewhere downstream: a review tax, a testing tax, a maintenance tax, an observability tax, a security tax, and — if any of those get skipped under time pressure — a technical-debt tax that comes due later, with interest. Black Duck's 2026 "State of AI-Powered Software Development" survey, run with UserEvidence across 831 enterprise engineers and DevOps professionals at companies with 500 or more employees, captures both sides of that ledger in one dataset: 92% of teams report improved productivity and release velocity from AI coding assistants, with 58% calling the improvement major. But nearly 90% of those same teams report workflow issues stemming from AI-generated code, with the specific bottlenecks landing exactly where you'd expect — manual review (52%), security testing (51%), and code rework (48%). Adoption of the tools has reached 97%. Governance of what they produce is still sitting at around 30%. The gap between those two numbers is, functionally, the tax bill nobody has agreed to pay yet.

Who Absorbs That Tax?

Somebody has to pay it, and the Faros telemetry is specific about who: senior engineers. AI-generated code tends to be superficially convincing — idiomatic, well-named, stylistically consistent with the surrounding codebase. It reads like it was written by someone who knew what they were doing. The failures, when they're there, sit beneath the surface, and catching them means reading carefully enough to reconstruct the problem the code was actually meant to solve rather than scanning for obvious mistakes. That's slow, expensive cognitive work, and it's the work only a senior engineer's judgment can reliably do. Which is exactly why review queues are backing up, not because there aren't enough reviewers, but because the volume of code now requiring that specific kind of scrutiny has outgrown the number of people capable of providing it.

The Senior Developer Becomes More Important, Not Less

This is a different claim from "juniors are struggling to learn with AI in the loop" — that's a real and separate problem. This one is about judgment, not training. AI can produce a working implementation on request. It cannot decide, on its own authority, whether that implementation should exist in this codebase, in this form, with these tradeoffs. That's an architectural call, and it still needs someone who has seen enough systems fail to recognize which shortcuts are cheap now and expensive in eighteen months. When code was expensive to produce, that judgment got exercised mostly at design time, before anyone typed. When code is nearly free to produce, that same judgment has to move to review time, applied to a volume of output no team was previously reviewing.

Maybe We Need to Stop Measuring Developers by Lines of Code

This might be the sharpest course correction available to any engineering org right now. The instinctive question after adopting AI coding tools is "how much code did AI help us produce?" — velocity, PR count, tickets closed, lines shipped. Those numbers suggest we're measuring the wrong thing. The question that actually predicts whether a team is in good shape a year from now is "how much useful, reliable software did we ship, and how much of it do we still understand?" Those two metrics can move in opposite directions at the same time, and right now, across the industry, there's reasonable evidence they are — throughput climbing while bugs, incidents, and unreviewed merges climb right alongside it.

The Software Factory Has Changed

None of this means AI is making developers obsolete — the productivity numbers are real, and nobody serious is arguing teams should go back to typing every line by hand. What it means is that the economics of software have shifted. When code was scarce, the ability to produce it was the competitive edge. Now that code is abundant, the constraint has moved to the ability to verify it, trust it, and stand behind it in production — and that capability is comparatively scarce, unevenly distributed, and much harder to buy off the shelf than an AI coding subscription. That's where the advantage is relocating, whether or not an organization's metrics have caught up to notice: the future of software engineering won't belong to the team that generates the most code, it will belong to the team that can generate the most code without losing the ability to understand, verify, and trust what it ships.

Sources

Every figure above is traceable to a specific survey or telemetry report below, not to general commentary about AI and coding.

Found this useful? Share it

Published under the BizTechLab Editorial Code of Integrity.

Explore More Opinion Articles