Oren Grinker

Spec-driven development is a practice in which a written spec, not the code, is the source of truth. The spec states goals, acceptance criteria and non-goals. A person reviews it before implementation, agents build against it, and it stays versioned next to the code as the record of why the system behaves the way it does.

In a traditional SDLC, people write the code, so most of the effort goes into implementation. In an AI SDLC, agents write most of the code, so the effort moves to the edges: defining intent precisely before the build, and verifying and governing the result after it. The spec, the review and the record become the main work products.

Vibe coding goes straight from a prompt to code. An AI SDLC puts a reviewed spec before the build and a verifiable record after it, so you can check the result against its acceptance criteria and trace every change to the person who approved it.

No. Waterfall front-loads one big specification for a whole project and rarely changes it. In spec-driven development every change gets its own small spec, agents build it quickly, and what you learn in production flows back into the next spec, so the loop stays short and iterative.

Three parts: goals (what the change is for and who it serves), acceptance criteria (testable conditions for done) and non-goals (what not to build). Add the context an agent can't infer, such as constraints and existing conventions. Short and specific beats long and vague: “Admins can export monthly usage as CSV. 100k rows export in under 10 seconds. No PDF export.”

Acceptance criteria are the testable conditions that define done, written before any code exists. Each one should be checkable by a test or an eval, like “100k rows export in under 10 seconds” or “totals match the dashboard”. Without them, nobody can say whether an agent's work is correct, only that it runs.

Agents treat anything a spec leaves out as allowed. Writing down what you won't build, such as “no PDF export” or “no new permission roles”, stops agents from adding work nobody asked for. When agents do the work, what you don't forbid becomes permitted.

Product and R&D write it together: product owns the goals and the user outcome, and engineering adds acceptance criteria, constraints and non-goals. A different person reviews and approves it before agents start. Agents can help draft a spec, but a person owns it.

In the repository, versioned next to the code they describe, for example as a SPEC.md for each feature. Then every diff can link to the spec it implements, and the spec's history shows how the intent changed over time.

People write the spec, approve it before any code exists, review the diff against the acceptance criteria and decide when to ship. Agents do the implementation in between.

Check it against the spec, not against your impression of it. Tests and evals cover each acceptance criterion, a person reviews the diff for anything the spec didn't ask for or forbids, and the results are recorded with the change. If a criterion has no check, the code isn't verified yet.

It doesn't ship. If the build is wrong, it goes back to the agent with the failing criterion. If the spec turns out to be wrong or incomplete, you change the spec first, get it approved again and rebuild, so the record always matches what shipped.

They give agents consistent, controlled access to tools and context, such as the codebase, tickets, documentation and internal systems. Packaging a capability once as a plugin and reusing it across agents keeps behavior the same everywhere and makes it easier to govern what agents can touch.

Every change leaves a record: the spec, the human approval, the diff linked to the spec and the acceptance checks. In a regulated company, that record answers who approved a change and why, even months later. Good SDD isn't process ceremony; it's governance.

It's the set of records that explains a change: the spec, the approval with a name and a date, the diff linked to the spec and the acceptance check results. With it, anyone can answer why the system behaves a certain way and who approved it. The git log alone can't answer “why”.

Regulated companies have to show how changes are approved and controlled, and AI-written code gets no exception. The real question about AI-written code isn't whether it works; it's whether you can prove who approved it. Spec-driven development makes that proof a byproduct of normal work.

Start with one feature. Use a short spec template with goals, acceptance criteria and non-goals, require a human approval before agents build, link the diff to the spec and check each criterion before merging. Once that loop feels normal, make it the default for every change, with lighter specs for small fixes.

Writing the spec takes time up front, but agents make the build itself fast, so the bottleneck moves to deciding what to build and checking it. A clear spec cuts rework and back-and-forth with the agent. Small changes and bug fixes get short specs: the expected behavior as an acceptance criterion and a non-goal or two.

The spec becomes the product manager's main output, because agents build exactly what it says, gaps included. PMs write precise acceptance criteria and explicit non-goals, and spend more time checking results against intent than writing tickets.

I'm Oren Grinker, a co-founder and VP R&D in enterprise AI. I run R&D on an AI SDLC built on spec-driven development and write about governing AI-written code. Earlier I headed software development at ONE robotix, founded Coo.Land Games and co-founded MultiPlay.co.il.