Summary: SDD sounds like corporate process for large teams, yet it delivers its biggest payoff to the solo builder. A solo developer is architect, implementer, reviewer, and product owner at once — and nobody catches the flaw in the business logic, guards the scope, or remembers why a decision was made three months ago. A spec is the org chart of a one-person company: it staffs the three roles an absent team would fill — reviewer, memory, product owner. The benefit is asymmetric — a team bolts a spec onto rituals that already exist; a solo developer uses the spec to create those rituals in the first place.

Four hats, one head

Working alone you're simultaneously the architect (structural decisions), implementer (execution), reviewer (catching mistakes), and product owner (what to build and why), with a brutal context-switching cost between them. The biggest risk of solo work isn't a shortage of hands — an AI agent supplies those — it's the missing external feedback loop that corrects course on a team. Two concrete traps: the missing reviewer (the agent doesn't question your assumptions, it accepts them and amplifies the mistake) and falling in love with your own code (classic sunk cost, with no teammate to say "you don't need this in V1"). This maps onto the observed trajectory of pure vibe coding: euphoria, then a plateau, then an accelerating decline as refactoring drops and duplication climbs, until an undocumented system hits the wall.

The spec staffs three missing roles

  • The ego-free reviewer. A spec plus the agent's fresh context gives a review solo work lacks by definition: present the finished code to a new session and ask it to argue against the stated intent. Karpathy's caution about agents applies — models accept flawed assumptions and run with them; they don't push back. The spec is the one artifact that gives the agent something to disagree with.
  • Memory outside the context window. Practitioners call its absence comprehension debt — mounting forgetfulness of your own product logic once the agent has written most of the code. Decision logs (Markdown files next to the code) explain why something is the way it is: a three-project free-tier limit looks like a deletable "magic constant" to the code, but the log records it as a deliberate pricing strategy. The spec and context files are the project's BIOS — intent held outside the model's window so the agent reads it instead of guessing.
  • The product owner who says no. The "out of scope" section is the defense against scope creep, forcing you to frame the problem from the user's perspective rather than the implementation's — structurally discouraging "coding for coding's sake."

A lightweight four-phase cycle

Solo SDD isn't enterprise weight. It's four phases, and the entire payoff sits in clearing context before each implementation step:

  1. Intent — describe the goal in prose; the tool scans the codebase and asks questions; you confirm architectural choices while changing your mind still costs a text edit, not a refactor.
  2. Compile the spec — a design.md appears (API, data model, error boundaries). Think of the spec as source code an "LLM virtual machine" compiles down to the implementation.
  3. Isolated implementation — clear the agent's context (/clear) and feed it only the fresh section of design.md, broken into micro-steps, so it sees only the current instruction and goal. This prevents the drift and context overload that make long agent sessions progressively worse.
  4. Verification — a second AI instance with clean context checks the code against the spec. The iron rule: when they collide, you change the spec first, then regenerate — you never patch by hand.

Sizing to risk: from CLAUDE.md to Spec Kit

The objection that "SDD is too much for one person" confuses SDD with its heaviest variant. There's a spectrum, and the real solo skill is right-sizing:

  • CLAUDE.md — a rules file the agent reads instead of guessing conventions; its strength is "compounding memory," a direct descendant of Tom Preston-Werner's 2010 Readme-Driven Development.
  • OpenSpec — lightweight, model-agnostic, propose → approve → archive, setup in minutes.
  • PRD + task list + rules, then Spec Kit with a versioned project "constitution."
  • Kiro — heavy end, EARS notation (WHEN/IF/THE SYSTEM SHALL, from safety-critical software), tight single-IDE lock-in.

The one selection criterion: the cost of a mistake × the lifespan of the code. A weekend prototype takes the minimal variant; a product with paying users takes the full cycle. Two traps: a spec written by the agent rather than by you just reproduces vibe coding one level up, and a 600-word spec for a 20-line fix is theater.

When to spec, when to vibe code — and the honest tension

The honest answer isn't "always spec." It's: spec when the cost of a mistake is high and the code will outlive the conversation that created it. Wasowski deliberately airs the conflicting evidence rather than defending a thesis:

  • A widely cited 2025 METR experiment found an AI agent slowed experienced developers by 19% even as they felt ~20% faster — but it measured implementation in a repo they knew inside out, exactly where a structural spec adds least, not the requirements/architecture phase where SDD works hardest. (METR announced a methodology redesign in Feb 2026 after a larger follow-up produced ambiguous results from selection effects.)
  • An analysis of 119 open-source repos recorded a statistically significant increase in rework (~5 pts) where specs were used, plus a small defect uptick — best explained as confounding by indication: specs get written for the hardest tasks, which inherently generate more defects and rework. In mature, maintained repos rather than greenfield solo work, the spec's benefit doesn't show up.

The best explanation for the diverging results is context — greenfield-solo versus maintaining a mature repository — and the piece leaves that tension open. The necessary condition tying it together is self-discipline: without a team, nobody forces you to keep the spec alive, so the spec only works if you actually maintain it.

  • Spec-Driven Development Will Collapse — the productive tension to hold alongside this piece: Wąsowski's spec staffs three roles (reviewer, memory, product owner), while Ahuja warns a spec must never fuse three layers (intent, spec, implementation) into one document. Both hold only if the solo spec keeps intent/spec/implementation separable even as it substitutes for absent teammates — otherwise it commits the very three-layer collapse Ahuja predicts. (Noah's own comment on this source makes exactly that point: "When product goal and implementation contract live in the same document, the agent optimizes for the how and quietly redefines the what.")
  • Return of the spec — the "spec as the durable artifact, code as its projection" thesis this piece operationalizes for one person.
  • Context Engineering — decision logs, BIOS files, and context-clearing are context-engineering primitives; the spec is intent held outside the model's window.
  • 14 Claude Code Commands That Changed How I Work — the practitioner tooling (CLAUDE.md, /clear) this cycle runs on.
  • Design-First Collaboration — the "settle intent before implementation" discipline the four-phase cycle enforces solo.
  • Modular Monolith Instead of Microservices — Wasowski's companion argument; SDD is the discipline process he pairs with the modular-monolith architecture.
  • Encoding Team Standards — CLAUDE.md as compounding, machine-readable standards; here the same mechanism substitutes for an absent team.