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 serious harness should help discover intent
Before going further, I should qualify what I mean by a harness, because the word is already being used for rather different layers of the agentic stack. The harness contract I advocate for serious agentic engineering is the execution and discovery structure around the model: it assembles instructions, context, specifications, policy, tools and feedback for bounded work, and it helps turn an incomplete request into something which can be implemented and verified. This is not a universal industry definition of every product called a harness.
The authority boundary still matters. A harness must not invent a missing product decision, own that decision, or make it legitimate by writing its own guess down afterwards. But merely rejecting a vague request is too passive to be useful. When it detects that the intent is still vague, it should explain what is missing and begin a bounded interview or brainstorming pass, asking for just enough context to make the next decision responsibly rather than presenting the user with a requirements questionnaire for its own sake.
The discovery usually starts further away from the code than coding agents are inclined to start. Is there a business goal or objective, and what would make the work worth doing? Is there a product vision or strategic constraint which should remain free of implementation detail? If a person interacts with the result, what does the user journey or user story tell us about the user experience, including the awkward paths rather than only the happy one? Only then can the harness gather the functional, non-functional and architectural requirements which make the engineering boundary concrete.
That doesn’t require every change to produce an epic, a PRD, an FRD, an NFRD, several ADRs and a small library of Markdown. Those names can be useful within an organization, but they are not the semantic model. A reversible documentation correction may need a precise issue and the repository’s existing operating contract. A cross-system authentication change is a rather different proposition, and it may need the business objective, journey, architecture decisions, threat model and acceptance argument to remain separate because different people own them and they change at different rates.
The useful synthesis identifies the before state and the desired after state, then makes the assumptions, gaps and caveats visible—including deviations from applicable guidance, established practice, industry standards or a genuinely better state-of-the-art alternative. Retrieval over approved organization-internal documentation can ground that work in the systems, language and idiosyncrasies which actually exist. It cannot, of course, promote an obsolete internal page into authority merely because the retrieval step found it; grounded generation still depends on provenance, currency and ownership remaining part of the context.
Once those layers are coherent, the harness can synthesize the workstream requirements and produce the technical specifications which will govern the change. It can then slice the work into cohesive units, preserving trace links to the decisions and acceptance criteria which created them. Some units must run sequentially because one establishes a contract or migration boundary for the next, while genuinely independent units may be delegated to subagents in parallel when their dependencies and ownership boundaries make that safe. An orchestrator can reconcile the results, but parallelism is not a reason to hide an unresolved decision in five separate patches.
The same contract should establish generation guardrails and verification predicates before implementation begins. The former restrict what may be changed and which tools or data may be used; the latter state what must be true afterwards, including deterministic checks, acceptance criteria and the equivalent of a red-to-green TDD transition where that model applies. The agent may then conduct the implementation, gather evidence and verify the implementation against the specification at every relevant level, from the local artifact through interfaces, system behavior and the approved product outcome.
This is why one giant prompt, or one enormous AGENTS.md, remains a poor
substitute for a specification. Both can contain specification material, but 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, binding 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, and old facts remain plausible long after their assumptions have expired. The cure isn’t a small bureaucracy of Markdown files either: separate artifacts when ownership, authority, change rate or verification differs, and keep them together when those distinctions don’t earn their maintenance cost.
Proportionality, otherwise SDD becomes theater
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.