A model can produce flawless, well-tested code that still fails, because the defect never lived in the implementation. It lived in the instructions that shaped it, and those instructions rarely capture everything a human quietly assumes.
The Details:
- A model only sees the words in the prompt, not the meeting, the complaint, or the tribal knowledge behind a request. Ask for retry logic on a failing step and it will hand back textbook exponential backoff with jitter in the right place. What it will not do is flag that repeating the operation twice could corrupt data, because that constraint lived in your head and never made it into text.
- Ordinary technical debt announces itself through messy files and slow, painful edits. Specification debt hides because AI output carries no tells. A guess and a fully-informed answer come out with the same tidy structure and the same confident tone, so the instinct that once warned a reviewer to slow down has nothing to grab onto.
- The fix is not a better sentence, it is a different sequence of steps. Require a readback before any code gets written: the goal, the inputs, the edge cases assumed, and explicitly what is being left out, since that last item is where hidden assumptions surface. Pair it with a short pre-mortem naming who the user is and what would make them reject the result, plus a deliberate list of edge conditions like empty or malformed input before the happy path is coded.
- A cheap social check catches what process alone misses: say the requirement out loud to a colleague who was not in the original conversation. If it does not hold up verbally, it will not hold up in a prompt either.
Bottom Line: Code review caught bad implementations for decades; nothing yet catches a bad specification, and until teams build that habit, clean-looking output will keep quietly shipping the wrong thing.
