Main idea

Files that grow too large, missing tests, business logic scattered across the endpoints, architectures too complicated for the need, rewrites pushed off for too long: none of that appeared with coding assistants. Teams were already building a cathedral to hold up a shelf, and companies were already confusing delivery speed with actual value.

So what changes isn't the nature of the flaws, it is their throughput. An assistant accelerates what was already going too fast, makes what was already poorly understood less visible, and lets people stack up in a few hours decisions nobody really made.

The consequence is that a system can now display apparent maturity without having gone through the stages that usually produce it. The flaw isn't new; it is its rate of accumulation that now outruns the team's understanding.

Why it matters

This shifts the diagnosis. Blaming the tool for these flaws leads you to look for a better tool or to ban its use; recognizing them as old pathologies amplified leads you to rearm the mechanisms that already contained them badly — review, architectural arbitration, tests, explicit decisions.

It also gives a reading of projects that degrade fast: it isn't code generation that made them fragile, it is that generation removed the delay during which the fragility was still fixable.

Layer added by "Four Days of Vibe Coding as a Rusty PM" (2026-07-28). Watched closely over four days of building, the mechanism takes a precise and repeatable form. A file starts out reasonable, then swells until it does a bit of everything, and the cost shows up three days later when it has to be modified. The layers bleed into each other because nothing forces a decision about where the business logic goes. An API that returns thirty thousand items is treated like an API that returns two hundred. None of these moves is new; what is new is that they pile up in a few hours and the demo passes all the same. The mechanism extends beyond the code as well: tools built in a corner, unmaintained and ungoverned, have been a known corporate problem since spreadsheets and macros — the assistant doesn't invent that either, it lowers the entry price, and therefore raises the number of objects that take that route.

Nuances and limits

The change of scale isn't neutral: beyond a certain throughput, a difference of quantity becomes a difference of nature, because the human control mechanisms — reading, discussing, arbitrating — don't follow the same curve.

And some disciplined teams get the opposite effect: the same assistant writes the tests, separates the domain from the plumbing and proposes a simpler solution as soon as it is explicitly asked to. What it does spontaneously and what it knows how to do are two different things.

Open questions

• Above what production throughput do human control mechanisms stop being adequately sized, and how do you measure that before the incident?