Everyone’s celebrating how AI makes us write code faster. The entire industry narrative around vibe coding has been about speed and output — robot monkeys typing faster than humans. But does anyone actually want more code?

The output obsession

One of the dysfunctions that AI amplifies is our industry’s obsession with output. We measure lines generated, time to first output, pull requests merged. Companies like Meta and Uber track AI usage in performance reviews, because using more AI means being seen as more productive. The perceived output goes up, engineering leadership shares glowing reports about productivity gains, and everyone feels great about the numbers.

But a fast output that requires extensive rework isn’t productivity. It’s waste with better optics. A METR study with 16 developers tackling 246 issues in mature, million-line repositories found that developers using AI tools were actually 19% slower than those working without them, despite believing they were 24% faster. MIT measurements echo this: developers believed they gained 20% speed while delivery actually slowed by 20%. The bottleneck had shifted from generation to verification. Review, integration, and rework were eclipsing the fast coding gains.

We’re not just failing to get faster. We’re getting slower while feeling faster. Output metrics reward what is easy to count, not what is expensive to own.

More code is a liability

We tend to think of code as something we produce, like a factory output. But code isn’t a product. It’s a liability. Every line you add increases complexity, creates more places for bugs to hide, and adds to the maintenance burden your team will carry for years.

James Shore formalized this with a maintenance cost model that’s worth understanding. For every month of code written, crowdsourced estimates suggest roughly 10 days of maintenance in the first year and 5 days annually after that. If you double your output with AI, and the code quality stays the same, you also double your maintenance burden. Shore’s key insight isn’t that AI is bad. It’s that you need to invert your productivity. If you’re producing twice as much code, you need code that costs half as much to maintain. Three times as much? One third the maintenance. The teams that focus on this will see durable gains. The teams that just crank up output without touching maintenance costs will watch their productivity erode within a couple of years.

Even with AI context windows swallowing 500K lines, feeding it more code to fix one bug risks introducing more. And a working feature that nobody asked for is worse than no feature at all. It confuses users, incurs liability, and eats maintenance budget forever. Once something ships, it rarely dies cleanly. It sticks around in docs, tests, edge cases, dashboards, and customer expectations. Anthropic’s own Claude.ai had a persistent UX bug affecting all paying customers, unnoticed despite 80% of the code being AI-generated. Amazon’s Kiro AI agent caused outages severe enough to require senior sign-offs on all subsequent deployments. This is what happens when you optimize for throughput without caring about what comes out the other end.

The bottleneck moved

Vibe coding raised the floor, and that part is genuinely great. Anyone can ship a prototype now, non-engineers can build internal tools (maybe even behind SSO gates 😉), and the barrier to getting a computer to do stuff for you has never been lower. But it also moved the bottleneck in a way most teams haven’t internalized yet.

When code generation becomes essentially free, the constraint shifts from production to verification. A good engineering decision loop has four steps: observe the system, make sense of what’s happening, then decide and act. AI compresses the last two steps dramatically, but if you skip the first two, you’re not going faster through the loop. You’re just acting without understanding, and assuming code works because it was generated. Without tests, traces, and health checks to verify what was produced, you’re just generating unverified piles of code at an unprecedented rate.

The engineers who invest in building the automated feedback infrastructure that lets you actually observe whether what you built matters are the ones who will thrive. The ones who just keep generating will drown in their own output.

The smallest thing that solves the problem

The real skill was never typing speed, and it certainly isn’t prompting speed. It’s knowing what not to build. Effective software demands the smallest, simplest solution that solves exactly the problem at hand. AI doesn’t change that equation. It makes the consequences of ignoring it more expensive, because now you can produce the wrong thing at a scale that was previously impossible.

Before, teams could brag: “We shipped 40 features this quarter, AI made us so productive!” What I want to hear instead: “We shipped 4 features that customers actually use, and we have the verification to prove they work.”

That’s the shift worth making: fewer features, with evidence that they matter.

Next time someone celebrates how much code AI helped your team produce, ask the follow-up: did any of it need to exist?

References

• Value Is Not Proportional to Quantity — Allen Holub
• You Need AI That Reduces Maintenance Costs — James Shore
• Are AI agents actually slowing us down? — The Pragmatic Engineer
• You’re tired because your AI has no feedback loop — Siddhant Khare