GitHub pushes spec‑driven development, urging engineers to write the spec, not the code.

GitHub’s Spec Kit, announced alongside AWS Kiro and the Tessl Framework, marks the first coordinated push toward “spec‑driven development” (SDD) on major cloud‑native platforms, according to Bobby Blaine’s March 5 substack post. Unlike the “Vibe” coding model that treats an AI as a rapid‑prototype generator, SDD forces developers to codify requirements in a structured, behavior‑oriented document before any code is emitted. Blaine argues that language models excel at pattern completion but falter at “mind‑reading” – a REST API request, for example, leaves thousands of implicit decisions (authentication, pagination, error handling) that the model fills with its own training‑data biases. By making those decisions explicit in a spec, teams can turn the AI’s output into a deterministic, testable artifact rather than a guess‑work sprint that often requires a week of debugging, as the substack analysis notes.

The Spec Kit CLI integrates with GitHub Copilot, Anthropic’s Claude Code, and Google’s Gemini via slash commands that break the workflow into four discrete phases. First, the /specify command expands a natural‑language description into a detailed specification; next, /plan generates an implementation roadmap that respects the project’s stack and constraints; then /tasks slices the plan into reviewable units; finally, the AI agent executes each task in sequence. Crucially, Spec Kit enforces a “constitutional foundation” – a set of project‑level architectural rules that the model must obey throughout generation. This approach, Blaine writes, is the most customizable of the three tools, allowing enterprises to embed internal policies (e.g., mandatory OAuth2, rate‑limit thresholds) directly into the spec and have the AI honor them automatically.

AWS’s Kiro takes a lighter‑weight stance, delivering three markdown artifacts – requirements, design, and tasks – via a VS Code extension. Blaine notes that Kiro’s linear workflow can become cumbersome for simple fixes; the tool generated sixteen acceptance criteria for a modest bug, illustrating the overhead risk when the spec’s granularity exceeds the problem’s scope. Nonetheless, its simplicity lowers the barrier to entry for teams still experimenting with SDD, offering a quick way to see the benefits of explicit requirements without the full constitutional scaffolding of Spec Kit.

Tessl Framework, still in closed beta, pushes the spec‑as‑source paradigm to its logical extreme. It reverse‑engineers specifications from existing codebases and maintains a one‑to‑one mapping between spec files and generated source files, annotating the latter with “// GENERATED FROM SPEC – DO NOT EDIT” comments. Blaine cautions that while the vision is to eliminate manual code edits entirely, the current reality is that AI agents still “inconsistently follow instructions.” The spec acts as a guardrail rather than a guarantee, and the framework’s success hinges on its ability to keep the generated code faithful to the spec as the code evolves.

Early adopters are gravitating toward the “spec‑first” tier of adoption – writing specs for immediate tasks – which Blaine identifies as the sweet spot for measurable productivity gains. Teams that move to “spec‑anchored” (maintaining living specs alongside code) or “spec‑as‑source” face higher operational overhead and reliance on the AI’s fidelity. The three tools collectively illustrate a nascent ecosystem: GitHub’s open‑source, highly configurable CLI; AWS’s streamlined VS Code extension; and Tessl’s ambitious spec‑driven codebase synchronization. As Blaine concludes, the shift from “write the code, then debug” to “write the spec, then generate” may reduce the post‑generation debugging burden, but developers must still treat the spec as a contract that the AI may only partially honor.