Eight Times More Code, Eight Times More Bugs?

The question sounds innocent. With AI, we produce a lot more code, a lot faster. If volume explodes, isn't it normal for the bug count to follow? After all, the more you write, the more you get wrong.

It's a tempting line of reasoning. And it's exactly the wrong one.

The Trap of Proportional Reasoning

The argument "8x more code = 8x more bugs, so that's acceptable" rests on a confusion: it treats quality as a function of how much you produce, when it's actually a property of what you ship.

A customer, a user, a teacher using your software doesn't know — and doesn't want to know — how many lines you wrote to get there. They live with the result. If your product crashes twice as often as before, the fact that you "produced 8x more" isn't an excuse, it's an admission.

Defect density (bugs per thousand lines, or better: per shipped feature) is the real indicator. And that density shouldn't rise with volume. It should fall.

Why AI Should Lower the Defect Rate, Not Raise It

If AI does part of the work, it's precisely the work a human used to do with a known error rate. The opposite argument — "AI wrote it, so it's good by default" — is just as false as the first, but it points toward the right intuition.

AI changes the marginal cost of several activities that, historically, were the first to be sacrificed under pressure:

Tests. Writing a complete test suite used to cost a lot of human time. That cost collapses. There's no longer any excuse for shipping poorly covered code.
Review. A second pair of eyes on every change used to be a luxury. Now it's instant and systematic.
Documentation and readability. Refactoring for clarity no longer eats up half a day.

In other words: AI doesn't just give us more speed at producing bugs. It gives us, at the same price, the very tools that historically caught bugs. If you use only the first half of the equation, that's a choice, not an inevitability.

The Real Position: 8x More Code, Half the Bugs

Here's the bar we should set for ourselves. Not "tolerate 2x more bugs because we ship 8x more." Rather: ship 8x more and reduce the absolute number of defects.

This only sounds absurd if you believe quality is an accidental byproduct of writing. It isn't. Quality is the product of the filter you apply. And AI improves the filter as much as it accelerates production — provided you instrument it to do so.

The real danger isn't technical, it's psychological: the temptation to take the entire speed gain as features and zero as verification. That's the path to technical debt generated 8x faster than before.

What This Changes in Practice

If you lead a team or a product, the question to ask isn't "how many bugs can we afford?" It's:

Is our defect density falling, release after release? If it's rising, volume is getting away from us.
Is AI's speed gain reinvested in verification, or spent entirely on output? The right ratio isn't 100/0.
Are we measuring bugs in production, or only the ones we catch? The only number that matters is the one the customer sees.

Conclusion

No, we can't afford 8x more bugs because we ship 8x more code. And no, we can't assume that AI makes code good by default either.

The right stance is demanding and coherent: AI should raise quality, not just volume. If you ship 8x more with half the bugs, you've understood the tool. If you ship 8x more with twice the bugs, you've simply automated your debt.

Quality has never been a variable you adjust against volume. AI doesn't change that rule — it just makes it impossible to ignore.