跪拜 Guibai
← All articles
Claude · AI Programming

GitHub's spec-kit Turns AI Coding from a Guessing Game into a Contract

By 码哥字节 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

AI coding agents amplify ambiguity: a vague prompt produces plausible-looking code that breaks at the edges. spec-kit forces the developer to state constraints upfront, turning the spec into a verifiable contract. For teams already burning hours on AI-generated rework, the 20-minute upfront cost of writing a spec replaces hours of debugging incorrect assumptions.

Summary

Vibe coding — describing requirements loosely and letting an AI agent interpret them — produces code that drifts with every iteration. spec-kit, GitHub's open-source CLI (115k stars, v0.11.8), inverts that relationship: a constitution, spec, and plan are written first, and the AI generates code that must conform. The workflow runs through six slash commands across 30+ coding agents, from Claude Code to Copilot.

A spec is not a throwaway requirements document. It persists as the source of truth. Changing a feature means editing the spec and re-running implement, not patching generated code by hand. The clarify step surfaces boundary conditions the developer didn't think to state — soft vs. hard delete, past deadlines, concurrency — and answering those questions prevents the AI from guessing wrong later.

Three persistence models (Flow-back, Flow-forward, Living Spec) let teams trade off auditability against iteration speed. Extensions and presets allow custom hooks, templates, and commands without forking the tool. The methodology itself isn't new — Martin Fowler described similar classifications — but spec-kit packages it into a single `uv tool install` that any team can adopt.

Takeaways
spec-kit's six-step workflow — constitution, specify, clarify, plan, tasks, implement — separates intent from implementation so code is always a derivative of the spec.
Running `/speckit.clarify` surfaces unstated boundary conditions (null handling, concurrency, deletion strategy) and prevents the AI from guessing wrong later.
A detailed constitution that names specific frameworks and prohibitions (e.g., "Gin, not net/http") stops the AI from picking defaults that don't match the project.
Three persistence models let teams choose their tradeoff: Flow-back for small-team speed, Flow-forward for audit trails, Living Spec for stable products.
Extensions and presets allow custom hooks — such as auto-running tests or code scanning after implement — without modifying spec-kit's core.
spec-kit supports 30+ coding agents; switching tools only requires changing the integration flag during `specify init`.
Conclusions

spec-kit's design philosophy — Power Inversion, where the spec is the boss and code must obey — is not new. It's the same principle behind API contracts and interface-driven design, pushed to the extreme where the spec directly generates the implementation.

The clarify step is the highest-leverage part of the workflow because it forces the developer to confront ambiguity before any code exists. Skipping it is the most common and most expensive mistake.

spec-kit's value proposition collapses if you don't use an AI coding agent. The tool's entire purpose is to constrain AI generation; for manual coding, the spec becomes pure overhead.

GitHub's decision to make spec-kit agent-agnostic (30+ integrations) rather than tying it to Copilot signals that SDD is being positioned as a universal development practice, not a platform lock-in play.

Concepts & terms
Spec-Driven Development (SDD)
A development methodology where a formal specification — not verbal prompts — is the source of truth. Code is generated from and verified against the spec, which acts as an executable contract rather than a disposable requirements document.
Power Inversion
The design philosophy that the specification holds authority over the code. Changing behavior means changing the spec and regenerating code, not patching generated code directly. The spec is the boss; code is a derivative.
Flow-back Spec
A persistence model where artifacts can influence each other bidirectionally — changing code can update the spec. Suited for small teams iterating quickly, but risks silent drift where code and spec diverge.
Flow-forward Spec
A persistence model where completed artifacts are immutable. New requirements create new feature directories with their own specs, preserving an audit trail. Suited for regulated industries like finance and healthcare.
Living Spec
A persistence model where the spec file is the sole durable contract. Plan and task files are disposable derivatives regenerated on each change. Best for stable products with infrequent requirement changes.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗