AI coding tools can move quickly from a request to a working change. That speed makes an unresolved product decision easier to miss: whose workflow is this, which rules apply, and what should happen when the request cannot be completed?
Spec-driven development (SDD) gives the team a shared description of intended behavior. The specification becomes a reference for planning, implementation, and review, with enough detail to expose important decisions before they are buried in code.
Write behavior that someone can verify
Describe users, permissions, inputs, outputs, and exceptions. State the result the user needs before selecting the implementation. Include constraints that materially affect the design, such as existing interfaces or retention requirements.
A useful specification does not need to predict every line of code. It needs to resolve the decisions that would otherwise force the developer or coding agent to guess.
Carry the specification into the delivery plan
GitHub’s Spec Kit provides a structured approach spanning project principles, a specification, a technical plan, implementation tasks, and checks against the intended result. The artifact sequence makes the relationships between these decisions explicit.[1]
For the invoice example, the plan should identify the review interface, authorization boundary, duplicate-check behavior, and decision record. Tasks should connect those pieces to acceptance checks instead of treating them as unrelated tickets.
Give the coding agent bounded context
Supply the relevant specification, the part of the plan being implemented, repository conventions, and the command used to verify the change. Identify which existing interfaces must remain compatible. Ask the agent to surface a material contradiction before changing the design.
Work in increments a reviewer can understand. A focused change makes it easier to distinguish implementation mistakes from a requirement that still needs discussion. Treat the generated diff as reviewable work, with the same ownership as any other contribution.
Review evidence against the behavior
Acceptance should answer the original business question. For the invoice flow, showing a disabled button is insufficient if an unauthorized API call still approves the record. Verification needs to cover the boundary where the rule is enforced.
- Trace each important requirement to an implemented behavior.
- Check the normal path and the exceptions that change the outcome.
- Record any deviation and who resolved the underlying decision.
- Retain enough evidence for a reviewer to understand what was checked.
Update the contract when the product changes
A specification loses value when it describes a system the team no longer intends to build. Review requirement changes alongside the implementation and revise the acceptance examples that depend on them.
Start with one feature and a lightweight set of artifacts. Judge the process by how well it exposes ambiguity and supports review. The goal is a shared understanding that stays useful throughout delivery.
PUT IT INTO PRACTICE
Use a specification to make consequential decisions explicit. Connect those decisions to implementation tasks and evidence that the delivered behavior matches the intended result.