The specs-to-code movement’s workflow is: write a spec, generate code from it, and if something’s wrong, edit the spec and regenerate — never look at the code itself. Matt Pocock tried this directly: “I would try not to look at the code, but I would look at the code, and I realized… I would get worse code. And I did it again, I got even worse code.” Repeating the cycle compounded the degradation rather than converging on quality. His conclusion: “the idea that we can just ignore the code and just have the code manage itself is just sort of vibe coding by another name” — the practice inherits vibe coding’s core failure (no one is actually checking the artifact) even though it wears the more disciplined-looking clothing of “specs.”
The Pragmatic Programmer’s concept of software entropy explains why this happens instead of just staying flat: “every time you make a change to a codebase, if you’re only thinking about that change and not thinking about the design of the whole system, your codebase is going to get worse and worse and worse.” A spec-only feedback loop has no channel for whole-system design thinking — it can only react to symptoms visible from the spec’s altitude. This is the concrete failure case behind AI amplifies the architecture it works in — a hard-to-change codebase caps what any model can do for you, and it argues for treating Deep modules make a codebase both AI-legible and safe to gray-box as the fix: a codebase with legible module boundaries is one where a human CAN cheaply glance at “the code” without it costing the time savings specs-to-code was chasing in the first place.