CLAUDE SPEC-DRIVEN WORKFLOW

Code generation with Claude is fast enough that the bottleneck is no longer typing. The bottleneck is knowing exactly what you want before Claude writes it. Spec-driven workflow front-loads the thinking so the implementation phase becomes execution rather than exploration.

The teams that ship well with Claude are the ones that built spec discipline before the AI tools existed. The teams that struggle are the ones who try to skip spec by asking Claude to figure it out.

I describe the problem to Claude in three or four sentences. Then I ask Claude to surface five questions whose answers would change the design. I answer them. Then I ask Claude to summarise the resulting product spec in 200 words.

This stage takes 30 to 60 minutes and produces a written spec that the rest of the work flows from. The five questions are usually the ones I would have skipped if I went straight to code; surfacing them via the brainstorm stage is the entire value.

With the spec in hand, I ask Claude to identify the architecture choices that have the highest leverage downstream. Database shape, API surface, rendering strategy, deployment model. For each, Claude proposes two or three options with trade-offs.

I pick. The decisions go in the same document so the build phase has a single source of truth. Decisions made at this stage are 10x cheaper to revise than decisions discovered during implementation.

Code generation is the last stage and it is fastest because the spec is already complete. Claude writes the schema, the queries, the components, the routes, the tests, in roughly that order. I review every commit.

Most reviews surface a small refactor or a missing edge case; full rewrites are rare when the spec was clear. The pace is two to five times faster than unaided engineering on greenfield work.

Three review gates between brainstorm and shipped code:

Spec gate: before any code is written, the 200-word spec gets read top to bottom. Anything ambiguous gets clarified. Anything aspirational gets cut.

Architecture gate: before any database migration runs, the architecture decisions get reviewed against the spec. Anything that does not serve the spec gets reconsidered.

Commit gate: every Claude-authored commit gets a human review before merging. The review is faster than writing the code yourself but it is non-skippable. Claude does not approve its own pull requests.

Exploratory or research-shaped work where the goal is to learn what is possible rather than build a known thing. For these, the spec stage produces vague specs that constrain Claude unhelpfully. Iterative chat with concrete artefacts is the right pattern instead.

Bug fixes where the cause is unknown. The spec stage assumes you know the destination; debugging is figuring out where you are. For debugging, jump straight to the systematic-debugging pattern (reproduce, isolate, diagnose, fix) and skip the spec.

UI polish where every iteration is small and visual feedback is the signal. For these, Claude in Cursor with hot reload and side-by-side diff is the right tool, not a written spec.