Spec-to-Code vs. Spec-to-Context
Two different gaps between a written spec and a shipped feature. AI is closing the first one, which is turning intent into working code. It cannot close the second, which is the undocumented architectural and organizational reality that determines what the intent actually costs.
The spec-to-code gap is mechanical. A PM describes a behavior, an engineer implements it, and the translation loses fidelity along the way. This is the gap that tooling has been chipping at for decades and that AI is now closing quickly.
The spec-to-context gap is different in kind, not degree. A spec cannot contain the storage layer that doesn’t exist yet, the 10MB endpoint limit set by an undocumented decision in 2019, the frontend team’s convention for error states, or the six week compliance review sitting in the critical path. None of that is missing because the spec was written badly. It is missing because it lives in systems and people rather than in documents, and a model reading your codebase reads the first without the second.
The practical consequence: a one paragraph feature request can come back as a month of engineering effort, and the spec will not have been wrong. It will have been incomplete in ways the author had no way to see.
This is why the closing gap makes the remaining one more important, not less. When producing the code stops being the constraint, the accuracy of what you asked for becomes the constraint.