For all the magic of AI coding assistants, they share one critical flaw: they don’t really know what you want. Sure, they’ll generate some code and modules in a matter of seconds based on a prompt or a few lines of context, but they often miss the point of your project entirely. GitHub’s answer to that chaos is Spec Kit — an open-source toolkit that puts structure and intent at the heart of AI-assisted software development.
Released quietly in September, Spec Kit offers a lightweight way to capture and organise software requirements so that AI agents can actually work from them without trying to read the developer’s mind. It turns specifications into a living blueprint: something both humans and machines can interpret, refine, and execute.
What, exactly, is Spec Kit?
At its core, Spec Kit is a set of conventions and templates for describing software projects in a way that AI tools can interpret. It’s a structure for organising intent before any code is written.
A Spec Kit project is organised around a small set of Markdown files that live under a .specify directory:
spec.md– outlines the project’s goals and requirements.plan.md– describes the approach and architecture.tasks/– contains individual work units derived from the plan.constitution.md(optional) – records project principles or standards.
Together, these files form a structured, version-controlled record of what a team intends to build and how they plan to build it.
How to get started with Spec Kit
The easiest way to set up a Spec Kit project is with the Specify CLI, which scaffolds the .specify directory and populates it with templates for the main files: spec.md, plan.md, and a tasks folder. It also generates prompt files under .github/ for use with supported coding agents, which includes Copilot, Claude Code, Gemini CLI, Cursor, Windsurf, among others.
Once the structure is in place, Spec Kit follows a phased workflow designed to keep intent and implementation aligned. Each phase produces or updates one of the Markdown artefacts:
1. Specify – Define what the project should do and why. This step captures goals, constraints, and user needs in spec.md.
2. Plan – Translate that intent into a technical approach. The plan.md file records architectural choices, data flow, libraries, and external dependencies.
3. Tasks – Break the plan into smaller, self-contained pieces of work. Each file in the tasks/ folder describes a single unit of work with enough context for an AI or a developer to act on it.
These phases can be initiated in two ways: by running a corresponding slash command (/specify, /plan, /tasks) in a supported coding agent, or by editing the Markdown files directly. The commands serve as structured prompts, telling the AI what kind of document to generate or refine.
Developers can repeat these steps as a project evolves — updating the spec, regenerating plans, or adding tasks as requirements change. Every change is version-controlled, so there’s a visible trail from the original intent through to the resulting implementation.
Betting on a spec-driven future
While Spec Kit could be read as a structured antidote to the well-documented problems of vibe-coding — the tendency to throw vague prompts at an AI and accept whatever it produces — its ethos isn’t entirely new. The idea of capturing intent in a formal specification has been circulating for a while, with several other projects betting on a similar spec-driven future.
GitHub itself explored similar ideas with SpecLang, a research project that kicked off back in 2023 with the purpose of treating natural-language specifications as the primary source of truth for code generation. While SpecLang has seemingly not moved beyond the experimental stage, it hinted at the structured, specification-first approach that Spec Kit is now striving to put into practice.
Elsewhere, Amazon Web Services (AWS) is exploring similar territory with Kiro, an “agentic” IDE that lets AI agents plan and build software directly from written specifications. It’s a more integrated, productised take on spec-driven development — one that shows how far the idea can go when tied to a full IDE (listen to the AI Native Dev podcast all about Kiro). For GitHub, it hints at where Spec Kit could head if its framework ever folds into the broader Copilot and Codespaces ecosystem.
Startups, too, have been taking note of spec-driven development. Last week, AI Native Dev profiled Codeplain, a fledgling venture that’s building around a dedicated specification language called Plain. The language extends Markdown syntax so developers can express intent, behaviour, and constraints in plain English that an AI can translate into code, tests, and validation steps.
And then there is, of course, Tessl (which sponsors AI Native Dev), which recently launched a spec-driven framework and registry to make AI coding agents more reliable.
Taken together, these projects point to a clear shift in how AI-assisted development is being framed: less about generating code on demand, and more about defining intent in a form machines can reliably act on. Whether that approach proves to be a lasting foundation or another passing abstraction layer will depend on how well these tools hold up once real teams start building real systems with them.
‘Slog coding with Spec Kit’
Early testers have been enthusiastic but cautious about Spec Kit’s early promise. On the vibe coding Subreddit, one developer described using Spec Kit with Claude Code and Copilot as “wild,” noting that it “changes everything.”
On the one hand, the user praised its “consistency at scale,” “tech-agnostic specs,” and “better AI context,” saying it allows entire teams to work from the same instructions rather than relying on ad-hoc prompts. But they also noted that it can feel “overkill for small features or bug fixes,” with “a learning curve” and the sense that “UI-heavy work still needs visual tools.”
In a separate post from the same Subreddit, a user referred to Spec Kit as something akin to “slog coding.” Curiously, they said that using Spec Kit felt like “...micromanaging a super talented developer. It did what I asked but NOTHING more.”
While that was clearly intended as a dig at Spec Kit, another user responded to say that this behavior was precisely the point of spec-driven development.
“Doing ‘exactly what I asked and NOTHING more’ is a glowing endorsement,” they wrote. “That is how agentic coding becomes viable at the enterprise level. The single biggest problem with AI coding is its tendency to go off the rails and do its own thing.”
Over on GitHub, one user argued that Spec Kit’s structure could be the basis for something larger — a shared framework for AI-assisted development that enforces consistency and quality across teams. They cautioned that without common standards, AI-assisted development (AID) could fragment into competing workflows and uneven results. “This leads to defragmentation of technique, workflows and a wide range of quality, and a degradation of trust in AID,” they wrote.
They went on to suggest that Spec Kit could help prevent that fragmentation by formalising how humans and AI agents work together — “clearly defining human/AI boundaries and handover protocols,”* as they put it.
The post also proposes adding ways to generate a project’s `constitution.md` automatically from its existing codebase, and to share specifications and artefacts across teams and repositories. In their view, those kinds of extensions could turn Spec Kit from a lightweight developer toolkit into a consistent framework for managing AI-assisted work at scale.
Gojko Adzic, a consultant and author of several books covering software delivery and specification practices, frames spec-driven development as both a logical evolution and a potential overcorrection. In a LinkedIn post titled: Spec-Driven Development: the revenge of Waterfall or BDD taken to a new level, posted in response to the launch of Spec Kit, Adzic notes that the movement builds on the same intent-first ideas as Behaviour-Driven Development (BDD) but warns that its structure could re-introduce some of the rigidity agile methods sought to escape. As he puts it, spec-driven development “formalises a workflow around AI agent coding, extracting and codifying successful patterns for … code generation,” which, he cautions, might risk “bringing back the worst parts of Waterfall under a shinier name.”
It’s still early days for Spec Kit, and while it won’t fix the challenges of AI-assisted coding overnight, it points to where the next wave of tools might be heading: systems that don’t just generate code, but understand what that code is meant to achieve. If GitHub can make that work at scale, Spec Kit could become more than a developer toolkit – it could mark the point where spec-driven development shifts from a novel idea to shaping how teams actually build.
