# Spec-to-code A controlled transformation from durable intent and acceptance criteria through a technical plan and bounded tasks into implemented, tested, and reviewable software. technical-term · Operating model · maturing · Reviewed 2026-08-09 ## Definition Spec-to-code is a family of engineering workflows that treats a specification as persistent input to planning, decomposition, implementation, and review. The useful pattern is not one-shot code generation: each artifact makes decisions visible, carries constraints forward, and can be checked against both upstream intent and downstream behavior. Teams may begin from a new specification or reconcile a specification with an existing codebase. Specification-driven tools are rapidly maturing, while artifact schemas, change control, and evidence of outcome improvement remain uneven across implementations. ## Why it matters A durable chain—concept, specification, plan, tasks, implementation, tests, and review—reduces the need to reconstruct intent from chat history. Specifications are hypotheses about the desired system. They require accountable decisions, versioning, feasibility feedback, and revision when implementation or user evidence changes. ## System anatomy - **Specification:** Desired behavior, boundaries, constraints, and acceptance criteria. - **Plan:** Architecture and sequencing choices that make implementation feasible. - **Tasks:** Bounded units with dependencies, evidence, and completion conditions. - **Conformance review:** A check that implementation and tests satisfy current intent. ## Important distinctions - **One-shot generation:** Spec-to-code maintains traceable intermediate decisions instead of asking a model to leap from request to final code. - **Documentation after coding:** The specification actively shapes and is reconciled with delivery rather than merely describing the result afterward. ## Implementation signals - Version specifications with the code they govern - Carry acceptance criteria into executable tests where appropriate - Review both implementation drift and specification error ## Failure modes - A large specification becomes unreviewable context - Tasks preserve syntax but lose the user outcome - Generated code passes tests that do not represent the specification ## Related knowledge - [Shared design concept](https://aisdlc.ai/agentic-engineering/shared-design-concept) — A durable, explicit understanding of the problem, domain language, boundaries, constraints, and acceptance conditions shared by humans and coding agents before implementation expands. - [Intent engineering](https://aisdlc.ai/agentic-engineering/intent-engineering) — The practice of turning goals into versioned specifications, constraints, interfaces, invariants, decision rights, acceptance criteria, and testable outcomes before agents implement them. - [Tracer-bullet development](https://aisdlc.ai/agentic-engineering/tracer-bullet-development) — A deliberately thin, end-to-end implementation slice used to expose architecture, integration, feedback, and deployment assumptions before scaling the full build. - [Eval-driven development](https://aisdlc.ai/agentic-engineering/eval-driven-development) — An engineering loop that converts expected behavior and observed failures into repeatable evaluations combining deterministic checks, environment inspection, security testing, model graders, repeated trials, and human judgment. ## Sources and further study - [GitHub — GitHub Spec Kit](https://github.github.com/spec-kit/) — Documents an intent-driven workflow that turns a specification into a plan, tasks, and implementation artifacts while supporting multiple coding agents and replaceable process extensions. **Use:** Official guidance. **Limitation:** This is official project documentation, not causal evidence that spec-driven development improves every project; its artifact flow is one configurable process model. - [GitHub — Spec-driven development with AI](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) — A structured specification-to-plan-to-task workflow for making intent durable and actionable by coding agents. **Use:** First-party case study. **Limitation:** This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence. - [GitHub Spec Kit — Spec persistence models](https://github.github.com/spec-kit/concepts/spec-persistence.html) — Distinguishes spec-first, spec-anchored, and spec-as-source approaches without asserting one universal model. **Use:** First-party case study. **Limitation:** This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence. - [Matt Pocock — mattpocock/skills: A complete AI Coding workflow, end-to-end](https://www.youtube.com/watch?v=M6mYodf0dJM) — Demonstrates a skills-based coding workflow that develops shared domain context, writes a specification, decomposes work into tickets, implements it, and reviews against the specification and standards. **Use:** Practitioner perspective. **Limitation:** This is a first-party workflow demonstration rather than comparative evidence. A fresh-context model review is useful challenge but is not automatically an independently owned verifier. --- This library synthesizes cited research, standards, official documentation, and clearly attributed practitioner perspectives. Maturity describes the state of a concept—not vendor endorsement, production readiness, or permission to deploy. Benchmarks and demonstrations do not replace use-case evaluation, governed controls, independent verification, or named human release authority.