Spec-driven development is in some danger of becoming a market in which engineering organizations buy back their own memory.
Requirements, system boundaries, acceptance criteria, test evidence, change control, user needs: none of these arrived with the LLM. We have disciplines for them already, although we have practiced those disciplines with varying degrees of enthusiasm and, occasionally, buried the useful parts under impressive amounts of ceremony.
The genuinely different condition is the reader. A specification may now be consumed by a model, assembled into an execution context by a harness, and used by an agent that can edit a repository, invoke tools and prepare a change for delivery. The reader may also be an actor. That changes the required shape of the information, the speed at which ambiguity turns into code, and the importance of explicit authority boundaries.
For an engineering manager, this distinction is more than terminology. Treat SDD as an entirely new AI methodology and a team can spend a considerable amount of time inventing document names, prompt formats and folder structures, only to rediscover requirements engineering rather badly. Reuse the established disciplines and the work becomes more tractable: reshape what an agent must consume, make the important predicates enforceable, then add the controls that are justified by model execution.
What I mean by SDD
I use SDD here to mean Spec-Driven Development. It is a working definition for this series, not an ISO definition and not a claim that the industry has settled on the term:
Spec-driven development is an operating pattern in which versioned, reviewable artifacts make intent, constraints, acceptance and evidence legible to both humans and agents.
The word artifact is deliberate. A specification need not be one prose document, and making something model-readable does not mean pouring it into YAML. Types, schemas, state machines, interface descriptions, examples, decision tables, contract tests and a carefully qualified paragraph can all carry specification. Structure helps when information must be selected, joined, traced or validated. Prose still carries intent and judgment rather well. We should use each for what it is good at.
There is a related vocabulary problem. Teams often place several kinds of information in the same Markdown file and then speak about the file as if it had one semantic role. For this series I separate them as follows:
| Artifact | The question it answers | Characteristic lifecycle |
|---|---|---|
| Prompt | What is being asked in this invocation? | Usually local and short-lived |
| Instruction | How should the agent behave while doing the work? | Reused across tasks; owned like an operating rule |
| Context | Which facts and current state are relevant to this run? | Selected for the task and prone to staleness |
| Specification | What outcome, boundary and acceptance condition define the change? | Versioned with the decision and traceable through delivery |
| Policy | Which action is allowed, under which conditions, and by whose authority? | Governed independently and enforced at an authority boundary |
| Evidence | What was observed, checked or approved, and what does it actually support? | Produced by execution and retained for review or audit |
These are working distinctions. A repository may store several of them together; the labels used by vendors will vary. Their ownership and change rates still differ, and that is where indiscriminate bundling becomes costly. A stale context item is one problem. A stale permission rule is another.
The filling is familiar
This argument is not a loose analogy between old practice and new tools. The established standards already describe the underlying work. ISO/IEC/IEEE 29148:2018 covers requirements engineering processes and their information items. ISO/IEC/IEEE 15288:2023 and ISO/IEC/IEEE 12207:2026 provide system and software lifecycle frameworks without imposing one mandatory sequential method. ISO 9241-210:2019 covers human-centered design activities, while ISO/IEC/IEEE 29119-2:2021 covers test processes.
None of those standards defines agentic SDD. They establish something more useful for this argument: stakeholder needs, lifecycle boundaries, verification and reviewable information were engineering concerns before models acquired tool access.
The extension pattern is familiar too. ISO/IEC 5338:2023 builds AI-system lifecycle processes on the established system and software lifecycle standards. NIST’s Secure Software Development Framework is intended for integration into an organization’s SDLC, and SP 800-218A adds practices for generative AI and dual-use foundation models. Preserve the useful base, then extend it for the new failure modes. That is the sensible pattern here as well.
From discipline to executable control
The following crosswalk is my synthesis, rather than a normative mapping from the standards. Its purpose is to make one relationship visible: an agent can consume established engineering information, but accountability does not move into the model merely because execution became faster.
| Established discipline | Model-readable artifact | Agent use | Deterministic gate | Accountable human owner |
|---|---|---|---|---|
| Requirements engineering | Needs, requirements, non-goals, acceptance criteria and trace links | Bound the task and expose missing decisions | Required fields, trace checks, acceptance-test result | Product and requirements owner |
| Systems engineering | System boundary, dependencies, interfaces, states, hazards and lifecycle assumptions | Estimate impact beyond the local repository | Contract checks, dependency constraints, architecture policy | System owner or architect |
| Human-centered design | User goals, journeys, accessibility constraints, prototypes and research findings | Preserve the intended interaction and propose testable behavior | Accessibility checks and approved acceptance scenarios | Product and design owner |
| Software architecture | Invariants, decision records, module boundaries and compatibility rules | Select an allowed change path and explain its trade-offs | Dependency rules, API compatibility and schema validation | Architecture owner and code owners |
| Testing and verification | Examples, properties, test plans, evaluation cases and coverage rationale | Generate candidates, run checks and assemble evidence | Tests, type checks, static analysis, builds and explicit evaluation thresholds | Engineering and QA owner |
| Security engineering | Threat model, data classification, prohibited actions and least-privilege rules | Refuse unsafe scope and request escalation | Policy-as-code, secret, dependency and IAM checks | Security and service owner |
| Configuration and change management | Baselines, version pins, provenance, rollout and rollback plan | Work from known state and keep the delta attributable | Clean-diff, signature, promotion and rollback checks | Repository or release owner |
| Iterative delivery | Bounded work packet, risk class, feedback record and next decision | Execute one increment and reconcile feedback | Scope, review, CI and merge-policy checks | Engineering manager and delivery owner |
“Deterministic gate” deserves care. I mean that the rule and result are explicit enough for the delivery system to enforce. The model has not thereby become deterministic, nor does a green pipeline prove the whole system correct. A gate proves the predicate it checks. Nothing more. This is a modest statement, but a crucial one when fluent explanations are easily mistaken for evidence.
A harness cannot repair vague intent
In the narrow sense needed here, an agentic harness is the execution structure around the model: it selects and assembles instructions, context, specifications, policy, tools and feedback for a bounded loop. It consumes the specification. It may enforce parts of the operating contract. It cannot infer the missing product decision and make that decision legitimate by writing it down afterwards.
This is why one giant prompt, or one enormous AGENTS.md, is a poor substitute
for a specification. Both can contain specification material. An instruction
file is usually closer to a repository operating contract: what the repository
owns, how it is built, which invariants apply broadly, which paths are generated
and where an agent must stop. A change specification has a narrower life. It
binds one intended outcome, its non-goals, affected boundaries, acceptance
evidence and approval path.
Once task intent, durable instruction, policy and evidence are compressed into one convenient container, precedence becomes obscure. Small decisions require reviewing an ever-growing context. Old facts remain plausible. An agent can satisfy local wording and miss the reason the change exists.
Still, the cure is not a small bureaucracy of Markdown files. Separate artifacts when ownership, authority, change rate or verification differs. A precise issue plus an existing repository contract may be entirely sufficient for a reversible documentation change. A cross-system authentication change is a rather different proposition.
Proportionality, otherwise SDD becomes theatre
I would choose rigor along two dimensions.
Discovery and specification depth rises with uncertainty: unclear user outcomes, disputed requirements, unfamiliar domains, interfaces crossing team boundaries, or several plausible solutions. Verification and assurance depth rises with consequence: blast radius, irreversibility, poor failure detectability, security exposure and the cost of finding an error late.
The dimensions are correlated, but they are not the same. A small IAM change may be simple to specify and still deserve extensive security and regression evidence. An interaction prototype may require serious discovery and HCD work, yet almost no production assurance while it remains a prototype. A cross-system change can be deep on both axes. Page count tells us very little.
This also exposes the awkward part of specification work: specifications decay. They contradict implementations, retain decisions whose assumptions have expired, or become a ritual performed at the start of a project and ignored thereafter. Versioning helps only when someone owns reconciliation. An agent may identify drift, broken trace links and conflicting assertions. It should not quietly choose which source of truth has authority.
The useful test is whether an artifact closes an important ambiguity and whether the required evidence is proportionate to the risk. Anything beyond that needs to justify its maintenance cost.
What this changes for engineering leadership
Cheaper candidate generation moves attention toward the harder decisions: what should be built, where the system boundary lies, which uncertainty remains open and what evidence deserves authority. The AI-maturity model calls the broader organizational property safe delegation capacity. SDD supplies part of its intent and acceptance structure. A platform cannot safely delegate work that the organization cannot state, bound and evaluate.
People who understand requirements, systems engineering, HCD, testing, security and delivery as connected disciplines become more valuable under these conditions. So does the ability to recognize when a familiar practice has turned into empty ceremony. For hiring and team development, I would ask someone to carry one intended outcome through the system boundary, the verification argument and the approval decision. Which assumptions remain? What can the pipeline genuinely prove? Who is allowed to accept the residual risk? How will the team notice that the specification has gone stale?
Those questions are a better signal than fluency with a fashionable prompt framework. They are also the beginning of an AI platform, because the artifacts need versioning, identity, policy, CI, evidence retention and an authority model around them. The less glamorous work is to reshape accumulated discipline for a reader that can also act, while refusing to recreate paperwork that no longer earns its maintenance cost.