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 Bad code is the most expensive it's ever been, 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.