Spec-Driven Development: What It Is and How to Measure It (2026)

Spec-driven development means writing a detailed specification before an AI coding agent touches the keyboard, instead of prompting your way to working code and hoping it holds. It's the workflow question every team running Cursor, Claude Code, or GitHub Copilot eventually runs into: the agent works fast, but who signed off on what it actually built?

A: Spec-driven development is a workflow where you write a spec, requirements, architecture, data model, acceptance criteria, before an AI coding agent generates the implementation. The spec becomes the source of truth the agent works from, instead of a chat history nobody can audit later.

A: Vibe coding is prompting an agent iteratively until the output looks right, with no durable record of intent. Spec-driven development front-loads that intent into a written document your team and the agent can both review before code exists.

A: A spec forces clearer scope, but that alone doesn't prove anything. The only way to know is to watch PR cycle time, review health, and the AI-versus-human split in your own delivery data, which is what Abloomify pulls from GitHub, Jira, and connected AI coding tools.

A: GitHub's open source Spec Kit, Amazon's Kiro, and the Tessl framework are the three most discussed as of 2026. Claude Code and Cursor both support spec-first workflows natively, without requiring a separate toolkit.

A: Spec existing isn't the signal. Track whether PR cycle time is actually trending down, whether review comment volume is dropping because reviewers argue about the plan instead of the diff, and whether the AI-versus-human contribution split holds up over weeks, not one good sprint.

Spec-driven development is a way of building software where a written specification, not a chat prompt, is the artifact an AI coding agent implements against. The spec covers what a general prompt usually skips: the requirements, the interfaces and data contracts, the edge cases, and the acceptance criteria that define done. A developer or team writes it, an agent like Claude Code, Cursor, or a purpose-built toolkit such as GitHub's Spec Kit turns it into a plan and then code, and the spec stays around afterward as the record of what the system is supposed to do. That last part is the actual difference from prompting an agent freehand: the intent survives the session. IBM's framing splits it into a spectrum, from spec-first (write it, then build, then move on) to spec-anchored (keep referring back to it) to spec-as-source (treat the spec, not the code, as the thing you edit when requirements change). Most teams experimenting with it in 2026 sit somewhere between the first two.

The appeal is obvious once you've watched an AI agent generate a thousand-line pull request from a two-sentence prompt. Nobody wrote that architecture. Nobody signed off on those tradeoffs. The code might work, but there's no artifact to review before it exists, only after, when reviewing it costs more than writing the spec would have.

AI coding agents got good enough to generate real production code fast, and that speed is exactly what exposed the problem with skipping the spec. Companies now run 7 or more AI tools on average, up from about 2 in 2023, and most of that growth is coding assistants and agents layered on top of each other with no shared plan for what any of them should build. I've watched this up close: at Abloomify, we switched from GitHub Copilot to Cursor, and my co-founder Amir has called it one of the best decisions we made for the company that year. That switch is also exactly why we started caring about specs. A faster agent without a clearer brief doesn't produce better software, it produces bigger diffs, faster, and you only notice the difference once you're the one reviewing them. Spec-driven development is the industry's answer to the same realization at scale, and it's not really a new idea. It's requirements engineering with an AI agent as the implementer instead of a junior developer, revived because the implementer is now fast enough that skipping the requirements step actually shows up as a cost.

The backlash against pure vibe coding is part of this too. Teams that shipped fast on unstructured prompting hit the same wall: code that works in the demo and falls apart under a second feature request, because nothing captured why the first version looked the way it did.

The first sentence of a spec-driven workflow always starts the same way: write down what you want built before you ask an agent to build it, in enough detail that a different engineer, or a different agent, would build roughly the same thing from the same document. GitHub's Spec Kit formalizes this into four steps:

Kiro and Tessl structure the same idea slightly differently, one leans toward keeping the spec anchored throughout the build, the other treats the spec as the actual source artifact and generates code as a derived output. All three exist because the same problem kept surfacing: agents left alone with a vague prompt make confident, undocumented decisions, and undocumented decisions are the ones that break six weeks later when nobody remembers making them.

In practice this looks less like ceremony and more like writing the pull request description before the pull request exists. A good spec for a single feature is a page, not a document. It names the interfaces, the data model changes, and the cases that have to work, then hands that to the agent and to a human reviewer at the same time.

Writing a spec is easy to turn into theater, where a team produces detailed, well-organized specifications for every task and still ships slower than before, because review cycles balloon around arguing over the document itself, or because the spec goes stale the moment the agent hits an edge case nobody anticipated and quietly improvises around it. IBM's own writeup on the practice names the failure mode directly: over-engineering the spec for problems that didn't need one, which burns the time savings the whole approach was supposed to buy back. The spec is a hypothesis about what should get built. Whether it worked is a question about the code that actually shipped, not the document that preceded it, and that question only has an answer if someone is looking at delivery data instead of taking the spec's polish as a proxy for quality.

This is also where "AI wrote most of this PR" stops being a meaningful claim on its own. A large AI-authored diff against a good spec and a large AI-authored diff against no spec at all can look identical in the pull request. The difference only shows up in what happens after merge: how often it gets reverted, how long review actually took, how many follow-up PRs it generated.

The first honest answer to "is spec-driven development working for us" is usually "we don't know," because most teams aren't tracking anything that would tell them. The signals that actually matter are the same ones that mattered before AI agents existed, just harder to see by hand now that a chunk of the code has no human author to ask. PR cycle time should trend down if specs are cutting review friction, not just look faster in one good week. Review health, comment volume, time to first review, self-merge rate, tells you whether reviewers are actually engaging with the plan or rubber-stamping large AI-generated diffs because reading them properly takes too long. And the split between AI-authored and human-authored code, tracked as a cohort over time rather than a one-off snapshot, tells you whether the workflow is holding up under real feature work or only worked for the demo task. Abloomify pulls all three directly from GitHub, Jira, and connected AI coding tools like Cursor and Claude Code, and treats AI leverage as one of the tunable pillars behind its Engineering Velocity Score, specifically so a VP of Engineering can answer this without assembling a spreadsheet by hand every sprint.

None of this requires new tooling if the engineering data is already connected. It requires someone to actually look at the trend instead of trusting that a well-written spec automatically produced a well-built feature.

Start with one team and one repo instead of a company-wide mandate, and pick a feature that's medium-sized: big enough that an unstructured prompt would produce something sprawling, small enough that writing the spec takes an hour rather than a week, so the experiment stays cheap either way. Use whatever the team already has, Claude Code and Cursor both handle a markdown spec as input without extra tooling, and reach for something like Spec Kit only once the team has felt the difference and wants more structure around it. Measure the same team's PR cycle time and review comment volume for a few weeks before and after, and don't declare victory on the first sprint. Then decide whether it's worth doing for more of the codebase, based on what the data showed rather than how the meetings felt.

Specs without measurement is theater. Measurement without specs is guessing.

No. Waterfall locks a full spec for months before anyone writes code. Spec-driven development writes a scoped spec for one feature or task, feeds it to an AI agent, and regenerates or revises it in minutes when reality disagrees with the plan.

Spec Kit is GitHub's open source toolkit for spec-driven development. It walks a team through four steps, specify, plan, tasks, and implement, and hands each step to an AI coding agent with the previous step's output as context.

It can, if the spec becomes a ceremony nobody reads before the agent runs. Teams who treat the spec as a living artifact, not a sign-off document, report faster review cycles because reviewers argue about the plan instead of the diff.

Yes. Both support spec-first workflows natively: write a markdown spec, point the agent at it, and ask it to implement against the spec rather than a loose prompt. Spec Kit and similar toolkits add structure and repeatability on top, they are not a requirement.

There is no fixed target, and treat anyone who quotes one with suspicion. What matters is whether the split between AI-authored and human-authored code holds up under your own delivery data, not a number borrowed from someone else's team.

Related reading: vibe coding, what are DORA metrics, AI ROI, and Cursor vs Claude Code.