Skip to main content
Back to Blog
AI Dev Tools/6 min read

The AI Developer Velocity Crisis: Why Writing More Code Faster Is Creating More Problems

93% of developers use AI coding tools. Actual productivity gains? About 10%. The bottleneck moved from writing code to reviewing it, and nobody redesigned their workflows to match.

ai-codingdeveloper-productivitycode-reviewsecuritysoftware-engineering
The AI Developer Velocity Crisis: Why Writing More Code Faster Is Creating More Problems

A lot of teams are experimenting with AI right now. They install the tools and marvel at how fast the codebase grows. But the honeymoon ends quickly. Very quickly it turns out bugs are growing at the same rate, sometimes faster. And code audits, even with AI making them more accessible, bloat the backlog for weeks.

This is the typical story of 2026. The AI revolution arrived faster than we had time to realize what happened and what to do about it. More importantly, how to rebuild development workflows so this code doesn't blow up in production.

The Numbers That Don't Add Up

Here's the data that should make every engineering leader uncomfortable.

Ninety-three percent of developers now use AI coding tools monthly. That's not a survey quirk. It's a real market. JetBrains measured the same number independently at 92.6%. The adoption curve was so steep it bent the tools themselves: Cursor, GitHub Copilot, and Claude Code became essential infrastructure almost overnight.

The productivity story should be triumphant. Instead, six independent research efforts converged on the same uncomfortable finding: organizational productivity gains are stuck at roughly 10%. Not 2x. Not 50%. Ten percent.

Here's the part that should keep you up at night. A randomized controlled trial by METR in July 2025 found that experienced developers using AI coding tools took 19% longer to complete the same tasks. The same developers thought they were 20% faster.

That's a 39-point gap between perception and reality.

Why? AI accelerates the part of coding that feels like coding: typing. The thinking, the review, the debugging, the architecture. None of that got faster. It might have gotten slower, because there's more code to review and more code to debug.

The Bottleneck Moved

Apply Goldratt's Theory of Constraints to a software team. Writing code is only 25-35% of the development lifecycle. The rest is requirements gathering, code review, security review, testing, deployment, and the endless meetings that hold it all together.

AI accelerated the 25-35%. The other 65-75% didn't speed up. In most organizations, it slowed down. More code to review, more code to test, more code to maintain.

Cursor CEO Michael Truell put it bluntly: "Cursor has made it much faster to write production code. However, for most engineering teams, reviewing code looks the same as it did three years ago."

Cursor then acquired Graphite, a code review startup. That acquisition was a more honest statement about where the constraint lives than any marketing copy could be.

The Faros AI data confirms it. Teams with high AI adoption merged 98% more pull requests. Their review time increased 91%. Bugs increased 9%. DORA metrics showed slight declines per 25 percentage points of AI adoption. Not improvements. Declines.

The velocity crisis is this: we write more code faster, and it creates a downstream pile-up. "Works on my machine" became "ships to production, but review is backed up for three weeks."

The Security Crisis Nobody Counted On

This is where the story turns grim.

Forty-five percent of AI-generated code fails security tests. Forty to 62% contain security or design flaws. AI-generated code has 2.7x higher vulnerability density than human-written code. These aren't edge cases. They're the baseline outcome when AI writes code without human guidance.

The Veracode data, covering 1.6 million applications, found that 82% of companies now have security debt, up from 74% the year before. High-risk vulnerabilities increased from 8.3% to 11.3% of the total. The remediation gap reached "crisis proportions," in Veracode's words.

Ten thousand or more new security findings per month are now being attributed to AI-generated code. That's a 10x jump from December 2024. In one year.

The attackers figured this out faster than the defenders. When AI generates code 10x faster and human review can't keep up, the math favors whoever is looking for vulnerabilities. 57% of organizations acknowledge that AI coding tools introduce new security risks. 70% report confirmed or suspected vulnerabilities from AI-generated code.

The vulnerability types tell a specific story. SQL injection and XSS failures in AI-generated code run at 86%. Log injection appears in 88% of AI-generated scenarios. Hardcoded credentials show up in tools designed for enterprise use. The most dangerous finding: design-level security flaws, including authentication bypass and improper session management, increased 153%.

Code review used to be a human-intensive but manageable problem. Now it requires human judgment at a volume that doesn't scale.

Why This Happened

The crisis wasn't inevitable. It was architectural. Organizations kept the same review workflows and just added AI-generated code to the pile. The velocity went up 10x and nothing downstream was redesigned to handle it.

This is what makes the crisis fixable. We didn't fail at using AI coding tools. We failed at redesigning our processes for a world where code is cheap and fast.

What Actually Works

The teams seeing real gains aren't the ones writing the most AI code. They're the ones that treated the entire workflow as the problem to solve, not just the coding step.

This means treating security review as a first-class output of the coding process, not an afterthought. It means accepting that the bottleneck moved to review and redesigning review to handle volume. It means letting AI handle the volume tasks while humans handle the judgment calls that actually require judgment.

The teams seeing real DORA improvements accepted that code review is now the critical path. They added reviewers. They automated what could be automated. They stopped treating "it compiled and the tests passed" as sufficient for production.

AI is a component in a system, not a replacement for a process. The AI writes the code. The humans make sure the code is worth writing.

What I've Seen in Practice

I use Claude Code every day. The perception gap between feeling and reality is visible to the naked eye. Code I would have written in an hour, AI writes in ten minutes. Then I spend another twenty minutes on review. Sometimes AI forgets to do several steps from the plan. Or the tests are written sloppily and don't catch the real problem.

But the real gain is there. Not the 6x that marketers promise. I get an honest 10x. But that's on my tasks: my own codebase, familiar context, clear specifications. METR measured something different: experienced devs on unfamiliar repos. Different numbers, same direction. The gain scales with how well you understand what you're doing.

Zoom out and AI in development isn't just about making programmers more efficient. It's about opening the door for everyone who wanted to build but couldn't wrangle the code. AI is the democratization of software. The main thing is that AI has enough context and your docs are in order.

AI is fastest when you know exactly what you want and can describe it precisely. AI is slowest when you don't know what you want yet and you're using the code to figure it out. Then you're iterating on both the spec and the implementation, and the back-and-forth multiplies the time.

Every project I ship gets a full test suite and security review before it goes live. Not because AI wrote bad code. Because AI writes plausible code, and plausible is the most dangerous kind of wrong. The review catches what AI misses. The tests aren't exciting. They're the system that makes the velocity sustainable.

The Question for 2026

Are we building more, or are we just building faster at the wrong things?

The AI coding revolution is real. It shipped faster than the workflows that were supposed to keep that code from creating security debt and review backlogs. The teams that close that gap will be the ones who shipped working software in 2026. Everyone else will be reviewing code until the heat death of the universe.

Stop measuring sprints by lines of code. Measure how much functionality actually reached your users.

Back to Blog