Three months ago your CTO shared a chart in the team Slack. PRs merged per week, up 3x. Deploys per sprint, doubled. “This is what AI-first looks like,” he wrote, and added a rocket emoji for good measure.
Today your lead engineer has 200 open PRs in her review queue, your last sprint extended into a fifth week to unpick something the second sprint introduced, and your on-call rotation has quietly grown from one person to three. Nobody posted a chart about that.
The Metric You Celebrated Was the Wrong One
Output per engineer is up. That part is real. Developers using AI coding assistants are generating roughly 60% more code per week than they were a year ago. Epic throughput is up 66%. Task completion rates are climbing. By the numbers most engineering managers track, things look genuinely good.
But the number almost nobody was watching: median time in code review is up 441% over the same period.
A developer with AI tools can produce five or six pull requests a day. A reviewer can still only handle the same number they always could, because reviewing AI-generated code is not faster than reviewing human-written code. In many cases it is slower, because the code is plausible and readable and almost, but not quite, right. 96% of developers in a 2026 survey said they do not fully trust the functional accuracy of AI-generated code. Which means every PR requires close reading, not a quick scan.
The bottleneck did not disappear. It shifted, invisibly, into the review queue.
What Is Actually in That Code
Speed was always a symptom. The underlying question is whether the code your team is shipping at 3x the previous rate is the code you want running in production.
The data being collected across thousands of AI-assisted codebases in 2026 is not reassuring. Between 40% and 62% of AI-generated code contains at least one vulnerability. Code duplication has increased 48% across teams that adopted AI coding tools without a structured review process. Refactoring activity dropped 60%, which means nobody is cleaning it up. And 85% of professional developers now use AI coding tools at least weekly, which means this is not a fringe problem.
The failure patterns are specific and consistent. Missing error handling. Duplicated logic that diverges slowly and silently. Functions that work but that nobody on the team can explain. Hallucinated package names that get committed and only surface when a dependency audit runs, or when someone actually looks.
In March 2026, Georgia Tech’s Vibe Security Radar tracked 35 new CVEs directly attributable to AI-generated code, up from six in January. Amazon’s most significant production incident of the quarter was traced to an AI-assisted deployment. Moltbook exposed 1.5 million API keys. Lovable-built applications inverted access control logic across 170 production deployments.
None of these teams were careless. Most of them were moving fast.
The Question Worth Asking Now
The question is not whether to use AI in development. That argument is over. The question is what kind of AI-first means in practice, and whether what your team is doing right now actually qualifies.
There is a version of AI-assisted development where engineers are faster because they are doing less typing and more thinking. Where code review rates stay manageable because the generation is supervised at the architecture level, not just the line level. Where the AI handles the scaffolding and the boilerplate while the domain logic stays in human hands.
There is another version where the AI handles everything, the engineer glances at the output, and the commit goes out. That version is faster in week one. By week twelve it has created a maintenance surface that would take three sprints to stabilise, if anyone had three sprints to spare.
Most teams are somewhere in between, and most of them have not looked closely at which side they are drifting toward. If your review queue has grown and your sprint velocity has dropped even as your output metrics have climbed, you already have the answer.
What Responsible AI-First Development Actually Looks Like
The AI-powered development teams that are producing durable work in 2026 have a few things in common. They use AI to compress the early phases of a build, getting to a working proof of concept faster and with less speculative investment. They separate velocity metrics from quality metrics and track both. They build review processes that scale with generation volume, or they cap generation volume to match what can be reviewed properly. And they treat the code review step as a non-negotiable, not as friction to be reduced.
Workflow automation and application modernisation projects are especially vulnerable to this pattern. Legacy systems are already fragile. Adding AI-generated code to a modernisation effort without rigorous review is not acceleration. It is accelerated accumulation of the exact problem you hired the team to fix.
None of this is an argument against using AI. The productivity gains are real and the business case is strong. A senior engineer working with well-designed AI tooling genuinely does produce more, faster, at lower cost. That is the outcome worth building toward.
The argument is for using AI honestly. Which means measuring what it is actually doing to your system, not just what it is doing to your PR count.
The Chart Worth Posting in Slack
The rocket emoji chart is easy to make. It shows the number everyone wants to see go up, going up.
The harder chart is the one that shows PR review age over time. Or mean time to recovery for production incidents. Or the percentage of your codebase that at least two engineers can explain. Those numbers tell you whether what you built last quarter is an asset or a liability.
Your team’s AI velocity is not the story. What happens to that velocity when the first major refactor lands is.
Agively builds software the AI-first way, with senior engineers and a proof-of-concept process that puts working, reviewable code in your hands before you commit the full budget. Book a free 30-minute call to talk through what responsible AI-first development looks like for your product.