Spec-Driven Development Has a Rubber-Stamp Problem

You open the spec your SDD tool just generated. Diagrams. Acceptance criteria. A named architecture decision, with a short paragraph on why it beats the alternatives. You read it top to bottom. Nothing looks wrong. You click Approve.

You just did the thing automation-bias researchers have been warning about for a decade.

Spec-Driven Development was supposed to fix what vibe coding got wrong: nobody understood what the AI built, so nobody could own it. The fix looks solid on paper. There's a document now. Someone reviewed it. Box checked.

But the review step is exactly where automation bias thrives. And a more complete, better-argued spec doesn't protect you from that. It makes the problem worse.

Where Spec-Driven Development Earned Its Reputation

Vibe coding got its name from Andrej Karpathy in February 2025, and it earned its bad reputation fast. You prompt, the AI generates, you ship. It works for three weeks. Then the model contradicts something it built last week, nobody remembers why a decision was made, and every new feature means re-explaining the whole system from scratch.

Spec-Driven Development showed up as the grown-up response. Write the spec first. Let the AI implement against it. Tools like GitHub's Spec Kit, Amazon's Kiro, and OpenSpec formalized this into a repeatable loop: generate the spec, generate the plan, generate the tasks, then generate the code, with a human reviewing at each handoff.

That review step is the entire safety case. It's the reason SDD gets to claim it's more disciplined than vibe coding. Almost nobody asks whether the review step actually holds up under the conditions it's used in.

Why "I Read It" Is The Wrong Question

Here's what "the conditions it's used in" means in practice. A Harvard Business School field experiment had 228 evaluators screen 48 real innovation proposals under three conditions: no AI, AI recommendations with no explanation, and AI recommendations paired with a written rationale. The rationale didn't make people more accurate. It made them 19 percentage points more likely to agree with the AI. That effect was strongest exactly when the AI recommended rejecting something. The better the AI explained itself, the less independent the evaluation became.

This isn't a one-off finding from a soft field. Radiologists show the same pattern reading mammograms. In a 2023 study, experienced radiologists (15+ years, on average) correctly categorized 82.3% of cases when an AI system's suggestion was accurate. When the AI's suggestion was wrong, their own accuracy dropped to 45.5%. Fifteen years of training didn't inoculate them. It just meant they trusted the system enough to follow it off the ledge.

Neither group was careless. Neither group skipped the review. They read the recommendation, considered it, and decided it was sound, because it was well-presented, not because it was checked against anything independent. That's what "I read the spec" actually measures: whether you finished reading, not whether you verified anything.

The pattern shows up in a boardroom and in an X-ray reading room. Explanation buys compliance, not scrutiny.

The Checkpoint Objection: Why It Backfires

The obvious pushback: SDD isn't a single approve button. It has multiple named checkpoints: spec review, plan review, execution approval. That's more structure than a radiologist glancing at one AI suggestion. Surely that adds up to real oversight.

One SDD write-up raises this worry directly, then waves it away with a line to the effect that the disciplined version of the workflow avoids it, without engaging the research at all. That's not an answer. It's a hope.

The HBS study didn't just measure whether people complied more with an explained recommendation. It measured whether that compliance produced better decisions. It didn't. Narrative explanations increased agreement without improving accuracy, because evaluators substituted the AI's persuasive text for their own verification. Add more checkpoints, and each one is a fresh opportunity to do that substitution again. The plan reads well, so you defer. The task breakdown reads well, so you defer again. Multiple well-justified checkpoints don't dilute automation bias. They multiply the moments where it can happen.

Where The Control Point Actually Works

None of this means human review is worthless. It means the timing is wrong. Reviewing a finished artifact asks you to catch a problem in something already built to look complete. That's a much harder cognitive task than making the decision yourself before anything gets written down.

The fix isn't a better-formatted spec or a fifth checkpoint. It's moving the decision earlier than the generation.

Same eventual document. Different question at the moment that matters: did you decide, or did you approve?

Tools that gate generation behind a question that's actually been asked and answered, instead of a read-through after the fact, shift the control point to where it works. GitHub's Spec Kit has a /clarify step for exactly this: it forces specific questions before the spec gets written, not after. Speclr does the same thing structurally: refinement interviews that unlock a section only after a decision has been made, gating the next phase behind an answer instead of a document. The point isn't the tool. It's that the decision happens before the AI has anything to show you, so there's nothing polished sitting there for you to quietly defer to.

This isn't the same worry Thoughtworks flagged when they placed SDD in their Technology Radar's "Assess" ring for a bias toward heavy up-front specification. That's a different failure mode: write too much before you know enough, and you've reinvented waterfall with extra ceremony. Deciding earlier doesn't mean specifying more. It means specifying the same amount you always would, just answering the question that mattered before a finished-looking document exists to hide it.

The Deletion Decision You'll Never Catch By Reading

Take something that sounds boring: a user asks to delete their account inside a multi-tenant product. Their data isn't just theirs, though. A shared workspace references it, and other users depend on parts of it staying intact.

An AI-generated spec can plausibly propose cascade delete. It can just as plausibly propose soft delete with anonymization. Both read as complete. Both come with tidy acceptance criteria. Neither reveals, on the page, that the real question underneath never gets asked: who actually owns this data, the user or the workspace they were part of.

You will not catch that gap by reading either version carefully. It's not a gap in the writing. It's a decision that was never surfaced as a decision. It got resolved somewhere in the model's generation process and handed to you as a finished answer. The only way to catch it is to have been asked the ownership question before the spec existed, so the spec you're reading is the record of your answer, not a guess you're now grading for plausibility.

Vibe coding and Spec-Driven Development get compared as if they're opposites: chaos versus discipline, feel versus structure. They're not. They're the same trust relationship with the AI, wearing different amounts of formatting.

What actually separates them was never whether you trust the model. It's when. Approve a finished spec and you've already extended the trust. Reading it afterward is theater, however sincere. Answer the question that produces the spec, and there was never a moment where trust substituted for a decision you made yourself.