When Spec-Driven Development Is Overkill (and How to Right-Size It)

When Spec-Driven Development Is Overkill (and How to Right-Size It)

When Spec-Driven Development Is Overkill (and How to Right-Size It)

The most common criticism of SDD is real: ask a rigorous tool to fix a one-line bug and it will happily produce user stories, acceptance criteria by the dozen, a multi-file plan and a phased task list — a sledgehammer for a nut. The fix is not to abandon the method; it is to right-size it, matching the rigor to the risk with a classification step before the loop.

Why the Ceremony Creeps In

The tools are built for the case where SDD shines — substantial features, real ambiguity, multiple hands — and their templates default to that scale. Run the same machinery on a trivial change and every phase still fires, generating artifacts whose review cost exceeds the change's risk. Worse, plausible-looking generated requirements invite rubber-stamping, and a rubber-stamped gate is not a gate.

Match the Rigor to the Risk

Ask one honest question before you start: what is the blast radius if this goes wrong, and how ambiguous is the intent? Three broad answers:

  • Trivial and unambiguous — a typo, a copy change, an obvious one-line bug. Skip the loop; a direct instruction or plan mode is the right tool.
  • Scoped but real — a small feature, a contained refactor. Run a light loop: a half-page spec and a task list, skipping the full plan.
  • Substantial or ambiguous — new features, cross-cutting changes, unclear requirements. Full loop, every gate held.
The free SDD Cheat Sheet includes the right-sizing guide and the review-cost test.Download Free — SDD Cheat Sheet

The Review-Cost Test

Here is the test that settles most cases: if reviewing the generated artifacts costs more attention than reviewing the diff itself would, the process is oversized for the change. Structure must earn its review cost — that is the whole deal. Make the fast lane official by writing it into your standards, so taking it is a sanctioned decision, not a guilty one.

Right-Sizing Is the Methodology

This is not the fine print; it is close to the heart of the matter. The founding insight of SDD is that structure should be proportional to how much intent matters — and that cuts both ways. A team that specs everything is making the same category error as a team that specs nothing: both have stopped asking the question. Ask it per change, answer honestly, and you spend your ceremony where it compounds and your speed where it is safe.

Spec-Driven Development: The Complete Guide has a full chapter on right-sizing, plus the three levels of rigor.Get the Complete Guide