In short: Agents build what the requirement says, so the constraint moves to intent. Spec driven development answers with better spec files, and the first study of its practice finds those files decay as the code moves on. A spec actually carries three supplies with different owners and clocks: intent, context and policies. A thin spec holds only the intent and rests on a maintained register of requirements and tests. A light spec holds only the intent and rests on nothing. Intent capacity, the volume of change an organisation can specify to a testable standard, depends on that difference.
Why are specs back?
In little more than a year, spec driven development went from a GitHub experiment to a common way of working with coding agents. Researchers from Carnegie Mellon and Google built a corpus of the files it produces, SpecMine, and found 470,795 spec files across 73,030 public repositories, 92% of them first committed in 2026. The corpus mixes serious projects with tutorials and template clones, since only 923 of those repositories have a hundred stars or more, but the direction is hard to miss.
The same team then ran the first systematic study of how the practice actually works, combining Reddit discussions, interviews with 21 practitioners including eight tool makers, and an analysis of 266 active repositories. Practitioners agreed that a spec should capture intent. Many still filled their specs with implementation detail, used the approach selectively and mostly for new features, and reported more reliable agent behaviour alongside higher planning and review costs, though they could not separate that gain from better models. Specs also went stale. In one interviewee's words, the code gets changed and the spec is left alone.
The authors conclude that the approach shifted cost into planning without removing it. That is Constraint Migration reaching the Intent stage: the work has moved to the people who now have to say precisely what they want before anything is built.
What does spec driven development get right?
The movement deserves credit for naming a real problem. Intent stated only in a chat session is lost when the session ends, while a spec makes it something people can review before any code exists. Structured requirement forms such as EARS, published in 2009, remove much of the ambiguity agents would otherwise resolve by guessing, and they produce acceptance criteria a test can check. That is the shift left argued for in the Verification System, applied at the moment of writing.
The more careful voices saw the maintenance problem early. In late 2025, Birgitta Böckeler of Thoughtworks distinguished three levels of rigour: spec first, where a spec guides one piece of work; spec anchored, where it is kept and evolved with the feature; and spec as source, where people edit only the spec. Every approach she found was spec first, fewer aimed higher, and the maintenance strategy was often left vague.
Selective use also looks more like judgment than failed adoption. Most practitioners in the study chose by task size, and some by risk, skipping specs for small fixes and one off scripts. That matches the risk tiers of the Verification System, where ceremony follows what a change can break.
So the movement is right about where the problem sits. The open question is whether a better file is the whole answer.
Why does the constraint move to intent?
An agent acts on whatever the requirement says, faithfully and at volume. A person who meets an unclear requirement asks a colleague, checks an old design or applies a rule nobody wrote down. An agent fills the gap with a default, and the default becomes behaviour in production.
This site has already described what that looks like. In recent agentic delivery work, the hardest stop to clear was getting intent right in the product requirements and the solution design. Agents built what the documents said, and the documents lacked the context and the policies that experienced engineers used to carry in their heads. Missing context became missing requirements, and missing policies became rework.
What failed was rarely the statement of intent itself. It was everything a correct implementation depended on that the document did not contain.
The capacity at this stop is intent capacity: the volume of change an organisation can specify to a testable standard. It is usually lowered by functional coupling, where business rules and domains are entangled so that one change touches many, and by requirements written as prose that nothing can test. On the AI Engineering Capacity Map it sits upstream of verification capacity, and it decides how much of what agents build had a chance of being right.
What is a spec actually made of?
Look at what teams put into a spec for an agent and three different things appear, bundled into one file.
The study shows the bundling happening. In the repository sample, 77.6% of specs contained implementation detail, and tool users described adding what the agent could not infer for itself: internal APIs, domain rules and team conventions. That is context and policy, copied in by hand.
Copied into a spec, they are frozen at the date of writing while the systems and rules they describe keep moving. The authors found that detail of this kind may help the agent in the moment while making the spec prone to decay, and that decay strikes hardest when a change alters behaviour other specs describe. One participant said a small change might relate to ten other features. Finding those other specs is a traceability problem, and producing more specs faster makes it worse.
The authors recommend that tool builders separate the parts of a spec by how long they are expected to last. My own reading goes a step beyond what the study claims: the parts also differ by owner, and most of what decays is the context and policy that were copied in. The intent of a finished change rarely needs updating. The description of the system around it does, constantly.
What belongs in a spec, and what never should?
If that reading holds, a spec should carry only what is specific to the change. Five elements cover most of it:
the outcome the change should move, declared before build, in the terms validated business value will later be read against;
acceptance criteria written as concrete, testable statements;
scope exclusions, saying what the change must not do or touch;
the risk tier, which sets the checks and who signs;
references to the context and policies the change depends on, by identifier.
Everything else stays outside, by reference: the description of the systems involved, the architecture decisions and standards that apply, and the policies the change must satisfy. A separate study published this month, which derives 40 specification practices from exemplary specs, makes a related point about tools: a template shows where information belongs, but not what is sufficient. Choosing a template will not settle the anatomy question.
That leads to the question of format. The case for an open spec format is real. Teams run several agents and tools, each with its own layout, and the practice study found that tool specific structures shape what people and agents see. A shared format would make specs portable and reduce lock in to one vendor's conventions.
The standards that have gained neutral stewardship so far sit elsewhere. When the Linux Foundation launched the Agentic AI Foundation in December 2025, its founding projects were the Model Context Protocol, Block's goose agent framework and OpenAI's AGENTS.md. They standardise how agents receive project guidance and how they reach tools and context. None of them, nor the Agent2Agent protocol added this year, standardises the feature spec.
That may be the right order. A spec lives for weeks, while the interfaces through which any agent fetches current context and has its actions checked against policy will live for years. Standardising those interfaces seems to buy more than standardising the file, which can stay a short, portable local convention.
Thin spec or light spec?
Both look the same on the page: short, and limited to intent. The difference lies in what stands behind them.
Figure 1. Light, bundled and thin. The same intent, with nothing behind it, with everything copied into it, or resting on maintained supplies.
A light spec carries intent and rests on nothing. The agent fills every gap from the code it can read and its own defaults. For one team building a new feature, that often works, which is why light specs spread so easily. At organisational scale it breaks down. Every agent fills the gaps differently, and the reviewer quietly becomes the only place where the organisation's requirements are held. Margaret-Anne Storey has a name for what accumulates when intent goes unrecorded: intent debt.
A thin spec carries the same intent and rests on a maintained requirements register: a record of what each system and product is supposed to do, built up across releases, with each requirement linked to the tests that prove it. The register works at three levels, for each system, for each product spanning several systems, and for the rules that hold across the whole estate. It is also where requirements connect to the architecture decisions and policies they depend on, and where a new intent can be checked against the other changes in flight, using the roadmap already described as part of the context supply.
The register is part of context, owned and kept fresh like the rest of it. It is also what lets a thin spec stay thin.
There is a strong argument for skipping the register altogether. Agents can now read a codebase and draft its requirements, cheaply and always in step with the code. Inference is genuinely useful for bootstrapping a register and for detecting drift between what a system does and what it was meant to do. Its limit is that code records what a system does, including its defects and accidents, without recording what it should do or why. A requirement inferred from code can turn a bug into a specification, and it carries no rationale an owner could challenge. Inference can feed the register; it cannot be its source of truth.
The register also answers the decay problem. Once a change is released, its accepted criteria and tests merge into the register and the spec can be archived. The spec no longer has to stay alive, because the register does. Some tools already work this way inside a repository: OpenSpec merges each change spec into a living spec for the capability it touches. The register applies the same idea across products and the whole estate, and ties it to tests, decisions and policies.
None of this is new as a discipline. At La Redoute, requirements were validated through test plans carried from definition to execution in Cerberus Testing, and the ecommerce test base grew to more than 7,500 automated tests supporting daily releases across international markets. In effect, that was a requirements register maintained at human volume. Agents make the same discipline necessary across every system they touch, because a missing requirement now becomes wrong code within hours.
In any single change, the difference between a light spec and a thin spec is invisible. Across a thousand changes a quarter, it separates absorbing agent volume from accumulating rework.
What does the design look like?
The design follows the life of one change through the three supplies.
Figure 2. A thin spec through its life. Checked against the register before build, merged into it after release.
An agent can draft the spec from a declared outcome, but a person decides it. Before build, the change is checked against the register and the roadmap, which shows which requirements it alters and which other initiatives touch the same systems. It is then checked against the policies it references, evaluated as code by the same control plane that governs agent action. Build and verification follow the risk tiers of the Verification System. After release, the merge back into the register is a pipeline step, which is how the context supply keeps all its context fresh.
Risk tiers set the ceremony. A contained change may need three acceptance criteria and two references. A regulated or irreversible one carries full evidence and a second approver. Applying the full ceremony everywhere would turn specification into the next queue, and that queue counts as human intervention like any other.
Who decides what?
Agents draft, people decide, and the decision rights follow the supplies. Product owns the outcome and declares the value a change should create. Engineering owns the acceptance criteria and their testability; the study's authors advise that people write or at least approve these even when agents produce the rest. Architecture owns the structure of the register, the decisions and standards it links to, and the domain boundaries that keep functional coupling low. Governance, with security and risk, owns the policies.
The register itself needs one named owner, accountable for its coverage and freshness. Because every requirement in it is tied to tests, the owner of the Verification System is a natural candidate, though some organisations may prefer the platform or architecture function. What tends to fail is shared ownership, where everyone contributes to the register and nobody answers for it.
How do you measure intent capacity?
Three probes give a first reading, offered as a starting set:
flow, the time from an accepted outcome to a spec ready to build with testable criteria;
quality, the share of changes that start without testable criteria, and the rework traced back to ambiguity;
effort, the human hours spent specifying and clarifying, per change.
Register coverage, the share of systems whose behaviour is described by maintained requirements linked to tests, works as a leading sign. Intent capacity is binding when flow lengthens as build accelerates, or when effort per change rises faster than output. Specifying is human intervention, so the effort probe belongs in the denominator of validated business value per unit of human intervention, alongside the other probes in the absorption dashboard.
Where should a CTO start?
A spec tool is the wrong first purchase. A more reliable start is the handful of systems where agents already produce the most change. Build a register for those, bootstrapped from existing tests and from requirements inferred from code, then confirmed by their owners. Agree the spec anatomy as a short standard of one page at most. Then make the merge back into the register a pipeline step, so the register grows with every release instead of through clean up campaigns.
Design one stop ahead. Once intent flows, the constraint is likely to move up to Direction, where the question becomes how many bets an organisation can fund and steer with a declared value. That is focus capacity, and the subject of a later piece in this series.
The question for your specs
Agents will build whatever your organisation writes down, and they will build it fast. The organisations that keep pace are likely to be those whose specs stay short because everything behind them is maintained.
If an agent implemented your next spec tonight, what would it check its work against: the spec alone, or a record of what your systems are meant to do?
Read further
Where intent sits in the model: The AI Engineering Production System
Every capacity in one place: The AI Engineering Capacity Map
Why the constraint reaches intent: AI Won't Replace Your Engineering Bottleneck. It Will Move It.
The context behind the spec: Building a Governed Context Supply
The policies behind the spec: Governance as Architecture
Where acceptance criteria become evidence: Designing the Verification System
What the system is optimised for: What Is Your AI Engineering System Optimising For?
FAQ
What is intent capacity?
Intent capacity is the volume of change an organisation can specify to a testable standard. It sits at the Intent stage of the AI Engineering Production System, upstream of verification. It is usually lowered by functional coupling, where business rules and domains are entangled, and by requirements written as prose that nothing can test. When it binds, work starts without testable criteria and rework traces back to ambiguity.
Is spec driven development enough?
It is a useful mechanism and probably not the whole answer. Specs make intent reviewable before code exists and structured criteria reduce ambiguity, but the first study of the practice found that specs decay as code changes and that planning costs rise. Much of what decays is context and policy copied into the spec, so spec driven development works best when specs reference maintained context and policies instead of carrying them.
What should a spec for an AI coding agent contain?
Only what is specific to the change: the outcome it should move, testable acceptance criteria, what is out of scope, the risk tier, and references to the context and policies it depends on. Descriptions of systems, architecture decisions and policies belong outside the spec, in maintained sources the agent can fetch, so they stay current after the spec is written.
What is the difference between a thin spec and a light spec?
Both hold intent only. A light spec rests on nothing, so the agent fills gaps from code and defaults, and the reviewer becomes the place where requirements live. A thin spec rests on a maintained requirements register linked to tests, plus governed context and policies. Light specs work for one team; thin specs let specification scale across an organisation.
Can requirements be inferred from code?
Partly. Agents can draft requirements from a codebase cheaply, which helps to bootstrap a requirements register and to detect drift. Code records what a system does, including its defects, without recording what it should do or why, so inferred requirements need confirmation by an owner. Inference can feed the register, but it should not be its source of truth.