The spec bill does not disappear, it moves to whoever re-reviews every loop

A post on the Stack Overflow blog, filed under its Dispatches from O'Reilly series, argues against the now-common line that detailed specs are old-world overhead: give the model a rough goal, let it explore, fix what comes back, move on ^[0][1]. That matters for anyone running agents in a real codebase, because the cheap-looking option does not remove specification cost, it moves it onto a person. Someone still has to decide whether the result matches the real goal, and according to the author, that person becomes the oracle ^[3]. The mechanics are unremarkable and that is the point. A simple prompt looks cheap because implementation starts immediately, and then the correction loops start: review output, clarify intent, ask for changes, rerun tests, find the next gap, repeat ^[2]. Each pass bills the same human. At the other extreme, full formal specification is expensive up front, since acceptance criteria, contract tests and BDD scenarios all take real effort ^[4]. The author's claim is that the downstream cost differs because more of the oracle is executable: a test checks the same condition every time, and it does not get tired, rushed, or optimistic five minutes before lunch ^[5]. So the decision is not spec versus no spec. It is where the minimum total cost sits, and for most agentic work the post puts that in the middle: enough structure to constrain the work, enough examples to make intent concrete, and enough executable checks that review does not become guessing ^[6]. Zero spec, in the author's framing, is not lean; it is costly vibe-coding ^[7]. There is a structural reason this suddenly bites. Software engineering was never mainly about typing code; it was about deciding what should exist, what should never happen, which trade-offs matter, and what "done" means in the real world ^[8]. Teams used to discover missing specification through human friction: a reviewer catching an edge case, QA finding the path nobody described, a senior engineer carrying half the requirements in his head ^[9]. Agents make implementation much cheaper and faster, so an underspecified idea can become a plausible system before anyone has agreed what the system means ^[10]. Vague requirements used to run into human slowness; now they run into machine speed ^[11]. Implementation cost was the forcing function, and we called the result process ^[12]. The step most people skip, per the post, is that the spec needs review too ^[13]. A careful spec can still contradict itself, cover the happy path while saying nothing about retries, rate limits or partial failure, describe behavior that cannot be verified, or be precise in exactly the wrong way and say what you wrote instead of what you meant ^[14]. When an agent executes a flawed spec faithfully, the implementation can look coherent and pass the checks you supplied, so fixing it means unwinding code and reasoning together ^[15]. Hence the recommendation to treat spec validation as its own line item, with plain questions: is this internally consistent, is it complete enough, which parts are testable, where are we still leaning on human judgment, and which failure modes were silently assumed ^[16]. The concrete workflow offered is two-agent: ask for the smallest spec that would let another agent implement the work safely, including assumptions, nongoals, acceptance criteria, edge cases, observable outcomes and open questions, with each claim marked as automatable test or human review ^[17]. Then hand that draft to a different agent and tell it to find contradictions, ambiguous terms, hidden dependencies, untestable claims, missing failure modes, and places where an implementation could pass the written criteria while violating the intent ^[18]. The author's modest claim is that this lowers the cost of reaching a spec worth human judgment, not that it removes judgment ^[19].