LLM agents write code at astonishing speed. They also forget at astonishing speed. A conversation may contain important decisions, yet those decisions disappear when the session, model, maintainer, or available context changes.

That is where Spec-Driven Development (SDD) comes in. The idea is simple: before asking for code, write down what we want to build, why, which boundaries it must respect, and how we will know it works. The specification stops being an ephemeral document and becomes a working contract that both the team and its agents can read.

Specifications are memory

A prompt says, “add authentication.” A specification says which users exist, what they can do, what happens when things fail, which data must not leak, and which scenarios must pass. The difference is not merely length: it is the difference between a momentary intention and context that can survive for months.

For an agent to work over the long term, it helps to preserve at least:

• the goal and the problem being solved;
• user stories and acceptance scenarios;
• functional, security, performance, and accessibility constraints;
• technical decisions and their reasons;
• a list of small, verifiable, ordered tasks;
• the state of what has been implemented and what still needs checking.

The agent may propose the first version, but humans remain responsible for checking whether it describes the right product. A specification does not remove conversation; it makes conversation cumulative.

A practical SDD workflow

A sensible cycle separates four questions:

1. Specify: what problem are we solving, and for whom?
2. Plan: which design and technical decisions solve it within the constraints?
3. Break it down: which independent, verifiable tasks can the agent execute?
4. Implement and verify: does the code satisfy the scenarios and continue to respect the specification?

When new information appears, update the specification and plan again. This is not about imposing a rigid waterfall; it is about recording change so the work does not depend on somebody remembering an old conversation.

Spec Kit

Spec Kit is GitHub’s open-source toolkit for this approach. Its workflow moves from /specify to /plan, /tasks, and /implement, with Markdown artifacts that provide structured context to the agent. It also includes commands for establishing project principles, clarifying ambiguity, and checking artifact consistency.

A typical start looks like this:

/specify Describe the problem, users, and scenarios
/clarify Resolve any open questions
/plan    Choose the architecture and technical decisions
/tasks   Turn the plan into verifiable tasks
/implement

Its strength is making the transition from intention to design to execution explicit. It is especially useful when a repository has many rules, when several agents are involved, or when future work should be resumed by reading the project files.

OpenSpec

OpenSpec describes itself as a lightweight, configurable framework for creating and managing specifications. Its current workflow revolves around /opsx:explore, /opsx:propose, /opsx:apply, /opsx:verify, and /opsx:archive: first understand the problem and existing code, then draft a proposal, requirements, design, and tasks, and finally implement, verify, and archive the change.

/opsx:explore
/opsx:propose add a theme preference
/opsx:apply
/opsx:verify
/opsx:archive

The emphasis is slightly different: Spec Kit offers a clear sequence of artifacts from idea to implementation; OpenSpec puts strong emphasis on maintaining changes, verifying that implementation matches the specification, and working in existing projects. Both pursue the same goal: preventing the agent from improvising a product from a single isolated instruction.

Benefits of working this way

• Continuity: a new agent can resume by reading the specification instead of reconstructing the whole history.
• Less ambiguity: acceptance scenarios force us to define what “done” means.
• Better delegation: small, ordered tasks are easier to assign, review, and repeat.
• More useful reviews: code can be compared with a written intention, not just a conversation.
• Less drift: scope changes, constraints, and decisions stay visible to the whole team.
• Portability: project knowledge does not remain locked inside one provider, IDE, or chat session.
• Cumulative learning: specifications, decisions, and checks become the system’s operational memory.

There is a cost: writing and maintaining specifications takes discipline. An outdated document can mislead as much as no documentation at all. The specification should therefore be short when the problem is small, reviewed alongside the code, and stripped of ceremony that does not add clarity.

Other projects worth exploring

The ecosystem is growing, and there is no single correct way to practice SDD. It is worth comparing Kiro, which organizes work around requirements, design, and tasks; The BMAD Method, an open framework with specialized agents and roles for different lifecycle phases; SpecD, which treats specifications, changes, and hooks as first-class concepts; and Tessl, which explores an approach where the specification plays an even more central role than the code.

The Spec Kit repository and GitHub’s article on spec-driven development with AI are also useful starting points. Always check the current documentation: commands, integrations, and maturity levels in this area change quickly.

The rule of thumb

An LLM agent does not need us to repeat the same context forever; it needs us to turn that context into a versioned, reviewable artifact. Specifying is not bureaucracy before programming. It is deciding what memory we want to leave for the next agent — or for ourselves six months from now — so work can continue without guesswork.

Humans still have the final word: review the specification, inspect the code, and validate real behaviour. But when a project lasts longer than a chat session, working without a specification is asking the agent to build with amnesia.