Code Became Ephemeral, and Quality Became Blast Radius

Code has always been ephemeral. Before AI, the Apache Airflow codebase recycled itself completely every three years, 100 percent of it rewritten. That was normal. The only thing that changed is the speed. AI did not make code disposable; it collapsed the timeline from years to hours, and that changes how you should think about quality.

Six months ago I posted that code quality does not matter as much as it used to. It drew two and a half million views, and most of the replies were angry. I understand the reaction. Craftsmanship is real, and nobody enjoys hearing that the market price of a skill they spent years sharpening is falling. But the objection is aging quickly. The perfect three-line function still has value; it is just no longer scarce, because an agent will rewrite it, correctly, whenever the requirements change.

And "quality does not matter" is too blunt. The whole app matters; the design and UI that earn a user's trust are critical too. The real distinction is what happens when something breaks. Ring-fence the roughly 10 percent of your app where a bug is catastrophic (the core processing engine, the ledgering, the transactions that other companies' entire businesses run on) and hold it to strict standards with a tight group of reviewers. Then declare everything else non-sacred. One hundred-person company made it explicit policy: their five core repos are guarded by three senior reviewers, and every other repo accepts pull requests from anyone in the company. That openness is deliberate.

Why does this work? Because mean-time-to-recovery collapsed. If a vibe-coded feature ships a bug, and it is not in the core, a thirty-second blip does not matter. If it were in the engine running ninety million supply chain transactions a month, it would. The distinction is not old-code-versus-new-code quality. It is blast radius.

The tech debt objection is real but the interest rate dropped. A schema that caused real pain, controls and requirements half handwritten, sat as a dreaded migration teams debated for weeks. It turned out to be solved in two or three hours with an agent going back and forth, then nobody looked at it again. This is the same reason I argue that good enough code wins: the cost of being wrong fell faster than the cost of being slow.

Stop grading your whole codebase on the same curve. Draw the fence. Guard the 10 percent like it is sacred, and let the other 90 percent be as ephemeral as it always secretly was.