What Specifications Cannot Catch: A Proposed Taxonomy of the Residual
This is Part 3 of a four-part series, "The Specification as Quality Gate." Part 1 developed the correlated error hypothesis. Part 2 grounded the argument in complexity science. This post maps what ...

Source: DEV Community
This is Part 3 of a four-part series, "The Specification as Quality Gate." Part 1 developed the correlated error hypothesis. Part 2 grounded the argument in complexity science. This post maps what executable specifications cannot catch. Part 4 will follow. The argument for specification-driven development is strong. BDD scenarios that pass or fail are not probability estimates. Mutation testing that finds no survivors is a verified claim about the coverage of the verification layer itself. Contract probes that confirm boundary behaviour are deterministic gates, not heuristics. The case for putting specifications before code, and treating the pipeline as the reviewer, is well-founded. "Well-founded" is not the same as "complete." Any argument that executable specifications make AI code review redundant needs to account honestly for what specifications cannot catch. That accounting is not a concession. It is what makes the rest of the argument credible. What follows is a proposed taxonom