Agentic Harness: What Spec Driven Development Actually Is

At the AI Engineer World's Fair in 2025, Sean Grove from OpenAI described how most of us work with coding agents: "We keep the generated code, and we delete the prompt." He compared it to shredding the source code and version controlling the binary.

A harness can check a great deal about an agent's output: whether it stayed in its box, whether it finished, what it did. None of that tells you whether the agent understood what was asked. When the work is small, understanding is cheap to confirm by reading the result. When the work gets broad, the jobs drift, and every check passes on the wrong thing.

Spec driven development is the industry's answer to that problem.

What it is

Spec driven development means you write down what you want before the agent writes any code, and that document becomes the source of truth for both of you. The agent plans from it, breaks it into tasks from it, and is checked against it.

The definition is still moving. Thoughtworks put it on their Technology Radar in November 2025 in the Assess ring and said plainly that "the term's definition is still evolving". Birgitta Böckeler, a distinguished engineer at Thoughtworks, wrote the most useful map of it so far on Martin Fowler's site, and she splits it into three levels:

1. Spec first. You write a careful spec, the agent builds from it, and the spec is done with when the task is.
2. Spec anchored. The spec is kept after the task and evolved alongside the feature, so the next change starts from it.
3. Spec as source. The spec is the thing you maintain. Humans edit only the spec, and the code is generated from it.

Almost every tool today does the first. Few commit to the second. Only one has seriously tried the third.

Three levels of commitment

Each level asks you to trust the spec more and the code less.

Why it is needed

Agents are good at writing code and bad at guessing intent. GitHub's announcement of Spec Kit says this directly: the problem is not the agent's coding ability, it is the approach. We treat agents like search engines when they behave like "literal minded pair programmers". Give one an ambiguous sentence and it will pick an interpretation, build it well, and explain convincingly why it is right.

Vibe coding works for a prototype. It fails on anything that has to live in an existing codebase, match an existing architecture, or still make sense in six months. The prompt that carried the intent is gone, the code is all that is left, and code is a lossy copy of intent. It tells you what the system does. It rarely tells you why, or what it was never supposed to do.

A spec is the attempt to keep the intent. Written down, reviewed by a person before any code exists, and kept somewhere the next agent can read it.

Where it comes from

None of this is new. What is new is who reads the spec.

1. Design by contract, from Bertrand Meyer and the Eiffel language in the 1980s. Preconditions, postconditions and invariants written next to the code, checked at run time.
2. Model driven architecture, from the Object Management Group in 2001. Draw a precise model, generate the code from it. It promised exactly what spec as source promises today, and it mostly did not stick, because the models were rigid and the generated code was painful to live with.
3. Behaviour driven development, from Dan North in 2006. Scenarios written as "given, when, then" in plain language that a test runner can execute. Most spec tools today write their acceptance criteria in this shape.
4. The Easy Approach to Requirements Syntax, usually called EARS, from Alistair Mavin and colleagues at Rolls-Royce in 2009. They built it while analysing airworthiness rules for a jet engine control system: a handful of sentence templates that remove most of the ambiguity from a requirement. Kiro uses it today.

Two EARS requirements, written for this post:

WHEN a user submits the signup form with an email that is already registered,
THE SYSTEM SHALL reject the request and show "this email already has an account".
 
IF the email service does not respond within 5 seconds,
THEN THE SYSTEM SHALL queue the welcome email and complete the signup.

Each line is one trigger and one behaviour, and each one is a test waiting to be written.

The difference this time is that the reader of the spec is a model. Model driven architecture needed a strict, parseable model because the generator was a compiler. An agent reads plain language, which removes the rigidity. It also brings back the uncertainty, because the same spec can produce different code on two runs.

Who is proposing it

1. GitHub, through Spec Kit, announced by Den Delimarsky in September 2025.
2. Amazon Web Services, through Kiro, an editor built around specs that launched in July 2025.
3. OpenAI, less as a product and more as a position. Grove's talk argued that "the new scarce skill is writing specifications that fully capture the intent and values", and pointed at OpenAI's own Model Spec, a versioned set of markdown files where every clause has an id and a set of prompts that act as its tests.
4. Tessl, founded by Guy Podjarny, which made the boldest bet of all: specs, not code, as the primary artifact.
5. The open source community, through OpenSpec and the BMAD Method, which between them have over a hundred thousand stars on GitHub.

And on the sceptical side, the same people who mapped it. Thoughtworks and Böckeler are the clearest critics, covered further down.

How people use it

Under the different names, almost every tool runs the same loop.

The loop most spec tools share

The approval happens on the spec, before any code exists.

1. Set the rules once. A file of things that are always true for the project: the language, the testing rules, what is never allowed. Spec Kit calls it a constitution.
2. Write the spec. What you are building and why, as user stories with acceptance criteria. Usually the agent drafts it from a short description and you correct it.
3. Plan. You give the technical direction. The agent writes the design: data model, interfaces, how it fits what exists.
4. Break it into tasks. Small, ordered, each one checkable on its own.
5. Build one task at a time, and review a small change rather than a large one.

The review moves. Instead of reading a thousand lines of generated code and asking whether it is right, you read a page of requirements and ask whether it is what you meant. That is a cheaper question to answer, and a much cheaper one to get wrong.

The five approaches worth knowing

Ranked by how much they are used and how often they appear in independent comparisons. Star counts were read on 22 October 2026.

1. Spec Kit, from GitHub

github.com/github/spec-kit, about 142,000 stars, MIT licensed.

The reference implementation. A command line tool installs templates and slash commands into whatever agent you use: Copilot, Claude Code, Gemini and others. The flow is constitution, specify, plan, tasks, implement, with clarify and analyse steps between them to catch gaps and contradictions. It is the most thorough of the five and the heaviest. The project now describes its steps as "independent entry points, not mandatory phases", a softer position than its first release.

Best for: new features of real size where you want a documented trail.

2. Kiro, from Amazon Web Services

kiro.dev, an editor rather than a toolkit.

Every spec is three files in .kiro/specs/: requirements.md, design.md and tasks.md. Requirements are written in EARS. When you run the tasks, Kiro builds a dependency graph and runs independent tasks in parallel waves. It has separate flows for features and for bug fixes, and a quick spec mode that skips the approval gates for work you already understand.

Best for: teams happy to move into a new editor in exchange for the most integrated experience.

3. OpenSpec

github.com/Fission-AI/OpenSpec, about 72,700 stars, MIT licensed.

Built around changes rather than whole systems. Each change gets a folder with a proposal, a design, a task list and spec deltas that describe what the change adds to the system. When the change ships, it is archived and its deltas are merged into the living specs in openspec/specs/. That makes it the tool that comes closest to spec anchored without asking you to describe your entire system first. It claims support for more than thirty assistants.

Best for: existing codebases, which is most codebases.

4. BMAD Method

github.com/bmad-code-org/BMAD-METHOD, about 54,400 stars.

The Breakthrough Method for Agile AI Driven Development. Where the others are workflows, BMAD is a team: separate agents carrying product, architecture, user experience, development and testing roles, each handing structured documents to the next. Small changes go straight to build. Larger ones go through the full planning cycle first.

Best for: people who want the agile ceremony modelled explicitly, and are willing to pay for it in process.

5. Tessl

tessl.io.

The only serious attempt at spec as source. In its framework, each spec mapped to one code file, and the generated file carried a header saying "GENERATED FROM SPEC - DO NOT EDIT". Thoughtworks described it as the approach where "the specification itself becomes the maintained artifact, rather than the code". It was in private beta through 2025. Today the home page describes Tessl as "the agent enablement platform", built around reusable skills and context rather than specs as source. Tessl has not published a reason for the change, but the change itself is a data point about how hard the third level is.

Best for: watching. It is where the idea goes if it works.

What the critics say

Böckeler tried the tools on real work.

Kiro turned a small bug into four user stories with sixteen acceptance criteria. She called it "like using a sledgehammer to crack a nut". Spec Kit produced so many repetitive markdown files that she concluded "I'd rather review code than all these markdown files". Agents still ignored the spec in places, and in one run regenerated classes that the research step had already documented as existing. A detailed spec gave a feeling of control the agent did not honour.

Thoughtworks went further and asked whether the field is relearning the bitter lesson: that handcrafting detailed rules for AI "ultimately doesn't scale". And Böckeler's sharpest point is the history one. Model driven development failed on rigidity. Language models remove the rigidity and add uncertainty. Spec as source risks getting both problems at once.

A spec only helps if somebody reads it, and only protects you if something checks the code against it.

Most of the criticism is really about those two failures. Specs too long to review, and specs that nothing enforces.

What to do with it right now

1. Use it for features, not for fixes. A bug with a clear reproduction does not need a requirements document. A feature that touches three parts of the system does. If you cannot say what a spec would catch, skip it.
2. Keep the spec short enough to review in one sitting. If you would not read it, neither will anyone else, and an unread spec is just a longer prompt. Böckeler's warning about "spec" becoming a synonym for "detailed prompt" is the real risk here.
3. Write every acceptance criterion so it can fail. EARS or "given, when, then", it does not matter which. "The signup works" cannot fail. "When the email is already registered, the system rejects the request" can, and it is a test before it is code.
4. Make the spec executable. The spec is a claim. The test is the evidence. Turn each criterion into a test before the implementation exists, and let the test runner decide, not the agent.
5. Aim for spec anchored, not spec as source. Keep the spec and update it with each change, the way OpenSpec does with its deltas. Do not try to stop editing code. Tessl's change of direction shows how hard that is.
6. Start with the lightest tool that fits. For an existing codebase, OpenSpec. For a new product with real scope, Spec Kit. If you already live in an editor you like, a folder of markdown files and a clear habit get you most of the way.

The open problem is drift. A spec written today and code changed tomorrow will disagree soon enough. Some of these tools have verify or analyse steps, but a June 2026 paper still names specs that silently fall out of sync with the code as a failure the existing approaches do not fully solve. Until something does, a spec can report success on work that no longer matches what anybody meant.

This is the third post in a short series on building an agentic harness. If you are using any of these tools on real work, I would genuinely like to hear where they held up and where they did not. Happy coding.

References

1. Birgitta Böckeler, Understanding Spec Driven Development: Kiro, spec-kit, and Tessl, martinfowler.com, 15 October 2025.
2. Thoughtworks Technology Radar, Spec driven development, November 2025.
3. Den Delimarsky, Spec driven development with AI: get started with a new open source toolkit, GitHub Blog, 2 September 2025.
4. Sean Grove, The New Code, AI Engineer World's Fair 2025.
5. GitHub Spec Kit.
6. Kiro specs documentation.
7. OpenSpec.
8. BMAD Method.
9. Tessl.
10. Easy Approach to Requirements Syntax, Alistair Mavin and colleagues, IEEE Requirements Engineering Conference, 2009.

Join the community

I run a free community for people moving from vibe coding to production: spec driven development with Claude Code, Cursor and agents, and the habits that make the output something you can ship. If this post was useful, the conversation carries on there.

Join Vibe Coding to Production on Skool