technical-term · Operating model · maturing · Reviewed
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.
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
Sources and further study
- GitHub — GitHub 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 in this library: Official guidance. This is official project documentation, not causal evidence that spec-driven development improves every project; its artifact flow is one configurable process model.
guidance · guidance · Published 2026 - GitHub — Spec-driven development with AI
A structured specification-to-plan-to-task workflow for making intent durable and actionable by coding agents.
Use in this library: First-party case study. This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.
engineering · engineering · Published 2025-09-02 - GitHub Spec Kit — Spec persistence models
Distinguishes spec-first, spec-anchored, and spec-as-source approaches without asserting one universal model.
Use in this library: First-party case study. This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.
engineering · engineering · Published 2026-07 - Matt Pocock — mattpocock/skills: A complete AI Coding workflow, end-to-end
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 in this library: Practitioner perspective. 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.
video · video · Published 2026-07-16