Generated code, reviewed code

There is a new imbalance in software projects: we generate in an hour what takes three days to review. The bottleneck has moved, and many teams have not noticed yet.

Production is no longer the constraint

Writing a thousand lines costs almost nothing now. Deciding whether those thousand lines do the right thing, break nothing elsewhere and will still be understandable in a year costs exactly what it always has: human attention.

The code nobody read

The real risk is not the bug — bugs get fixed. The risk is ending up with a codebase nobody truly understands, because nobody wrote it and the review step quietly disappeared.

The day a business rule has to change, nobody knows where it lives. So an exception gets added next to it rather than touching the existing code. Then another one. That is how a project becomes heavy in eighteen months instead of ten years.

What actually helps

• Small batches — fifty lines properly reviewed beat five hundred skimmed
• Tests on what matters — not coverage for coverage's sake: calculations, amounts, access rights, state changes
• One simple rule — if nobody can explain what a piece of code does, it does not ship
• Less code — the most reliable line is still the one you did not write

Real speed and perceived speed

Generating fast feels like being ahead. That feeling is real for a few weeks, then it gets paid back: every change becomes slower, every fix riskier. On a tool used daily, the speed that counts is the one you have in month six, not month one.

In short

Code generation tools are genuinely useful — I use them every day. They simply move the effort: less typing, more reading. A team that speeds up production without strengthening review is not accelerating, it is borrowing.