Everyone Grew the Same Eye: A Field Guide to the Spec-Driven Wave

The views expressed here are my own and do not represent those of any current or former employer.

In Part 1 I argued that spec-driven development isn’t new; it’s a forty-year-old idea with a new generator bolted on. This post is the field survey. Because the genuinely remarkable thing about 2025–2026 isn’t that someone invented spec-driven development. It’s that seven different teams invented it at the same time, independently, and mostly didn’t know they were doing the same thing.

Eyes evolved independently dozens of times in the history of life, because light is a constant and a light-detector is a good idea. What you’re about to read is the software version of that. The environment changed (models got good) and the same organ kept growing in unrelated codebases.

Let me introduce the specimens, and then explain the environment that grew them.

The catalog

I’ll go in rough order of how much machinery sits behind the idea, from “a folder of prompts” to “an actual engine.”

GitHub Spec Kit

The one everyone knows. A specify CLI plus a set of slash-command templates (constitution, specify, plan, tasks, implement, and a few optional ones) that you drop into your project and drive through your AI agent of choice. It supports something like thirty agents. It came out of John Lam’s research into making LLM-driven development “a tiny bit more deterministic,” and GitHub’s backing took it to six figures of stars almost overnight.

It is also, architecturally, the lightest thing in the catalog. As one good teardown put it, the CLI “all it does is download an existing package from the GitHub repository that contains the pre-baked prompts.” The intelligence lives entirely in carefully written markdown that the agent interprets. There’s no database, no persistent execution engine. It generates spec.md, plan.md, tasks.md and trusts the agent to act on them. Verification is the agent grading its own output against a checklist embedded in the prompt, with a human in the loop.

That’s not a criticism. It’s a design choice, and a deliberate one. Spec Kit’s whole thesis is to be air-gapped, dependency-light, and runnable anywhere. But it means the spec is, in the maturity terms I’ll define below, mostly spec-first: written, used, and then quietly abandoned to drift.

AWS Kiro

Amazon’s entry: a spec-driven IDE. You work in a spec → design → tasks flow and the artifacts persist in your workspace as you go. Because it’s an IDE rather than a folder of prompts, the spec is more genuinely anchored: it lives alongside the code and evolves with it, and there are hooks for automating steps. It’s the most “product” of the bunch, with AWS’s weight behind it. What it doesn’t have is multi-agent coordination: leases, locks, a shared task ledger across parallel workers. It’s one developer, one agent, one anchored spec.

Tessl

The most ideologically pure. Tessl’s bet is spec-as-source: the spec isn’t a scaffold you discard or even a document you anchor: it’s the actual source artifact, and the code is regenerated from it. This is MDA’s original dream (see Part 1) reborn for the LLM era, complete with the ambition of a “spec registry.” It’s the furthest-right point on the maturity spectrum, and also the one making the biggest bet on the generator being reliable enough to trust with that much.

claude-task-master

The pragmatist’s favorite. It takes a PRD and turns it into a task graph (parse → expand → execute) and drives your agent task by task. Hugely popular because it solves a concrete, immediate pain: “I have a big thing to build and the agent loses the plot halfway through.” State lives in a tasks.json. There’s no evidence gate and no leasing (“done” is whatever the agent reports), but as a task-decomposition layer it’s genuinely useful, and it’s the closest sibling to the planning half of what I built.

BMAD-METHOD

The “Breakthrough Method of Agile AI-Driven Development.” This one leans hard into personas: an analyst agent, a PM agent, an architect agent, a dev agent, each playing a role and producing a document the next one consumes: PRD, then architecture, then stories. If you’ve read my piece on teaching agents to work like a team, you’ll recognize the instinct: specialists communicating through artifacts beat generalists improvising in a shared context. BMAD is spec-driven development organized as a role-play, with human review between the acts.

Agent OS

A spec-plus-standards layer. The interesting move here is that it doesn’t just capture per-feature specs; it captures your standards: how your team writes code, your conventions, your golden paths. That’s the same instinct behind a “constitution” in Spec Kit, and it’s a genuinely good one. A spec without standards generates technically-correct code that doesn’t look like your codebase.

OpenSpec

The minimalist. A lightweight workflow built around change specs: you propose a spec for a change, it gets reviewed, then it’s implemented. Less “rewrite your whole process,” more “add a reviewable spec gate to the changes you were already making.” For a lot of teams that incrementalism is exactly right.

The maturity spectrum

There’s a clean way to sort all of these, and I’m borrowing it from a comparison project called spec-compare, which identifies three stages of spec-driven development:

1. Spec-First: you write the spec, use it to generate, then discard it. The spec was scaffolding. (Most “write a PRD, then code” flows; Spec Kit’s default gravity.)
2. Spec-Anchored: the spec persists and evolves alongside the code. It stays true because you keep it true. (Kiro, Agent OS, OpenSpec.)
3. Spec-as-Source: code is auto-generated from specs only; the spec is the program. (Tessl’s ambition; MDA’s twenty-five-year-old dream.)

This spectrum is useful and I’ll use it. But I want to flag something it quietly assumes, because the assumption is the whole subject of the next post.

The spectrum measures the durability of the spec. It says nothing about the durability of the execution: the record of who claimed which task, what was actually done, whether the work passed, and how you’d prove any of it three weeks later. Those are different things. You can be fully spec-anchored and still have execution state that evaporates the instant your chat session resets. Most of these tools are exactly that.

Hold that thought.

The environment that grew the eye

Why did all of this happen at once? Seven teams, twelve months, no coordination. When you see convergent evolution this sharp, you look for the environmental pressure. Here are the forces, and they’re worth naming because they’re the same forces that will shape whatever comes next.

The bottleneck moved. This is the big one. For years the hard part of AI coding was getting the model to write decent code. Around 2025 that stopped being the hard part. As the team at Praetorian put it in a writeup I’ll lean on heavily next time: “the primary bottleneck in autonomous software development is not model intelligence, but context management and architectural determinism.” Once the model can write the code, the scarce resource becomes steering, and a spec is a steering wheel.

The vibe-coding hangover. 2025 was the year a lot of people prompt-and-prayed something into production and then had to live in it. Spec Kit is explicitly positioned as the antidote: it treats the LLM as an over-eager junior engineer who does better work when you hand it crisper requirements. Critics, not entirely unfairly, called the whole movement “waterfall strikes back.” They’re not wrong that it’s a swing back toward up-front design. They’re wrong that that’s a bad thing when your implementer is nondeterministic.

Determinism and auditability. You cannot ship a nondeterministic black box into a regulated enterprise. A durable spec is the handle that makes the black box governable: it’s the thing the compliance team can read, the thing that doesn’t change when the model’s temperature does. Spec Kit was born from exactly this: research into making LLM development more deterministic.

Context windows are finite. A real build overflows any context window. The state of the work has to live somewhere outside the conversation. Externalizing the spec is the first, obvious move. Externalizing the execution state is the second, less obvious move, and, as I’ll argue, the one most of the field hasn’t made.

More than one agent. The instant you run two agents, you need a shared source of truth and a way to stop them stepping on each other. This is the pressure that forces the serious systems past “a folder of nice prompts” and into leases, locks, and ledgers. It’s the pressure that, for me, made state the product.

What the field guide tells us

Step back from the seven specimens and one shape emerges. The popular, fast-growing tier of this wave (Spec Kit, task-master, BMAD, Agent OS, OpenSpec) is, architecturally, stateless prompt-scaffolding. Brilliant prompts, real ergonomic wins, genuine adoption. And underneath: markdown files and trust. The spec might be durable. The execution is a conversation that ends when you close the tab.

That’s not a flaw they overlooked. It’s the natural stopping point of the spec road: you came from “how do we steer the model,” you solved that with a great document, and you stopped. The people who don’t stop there tend to be the ones who came from a different road, where they already learned, the hard way, that a declaration of intent is worthless without a durable, drift-aware record of what’s actually true.

That’s the road I came in on. And in the next post I want to show you the specific organ this whole field is missing (the one Terraform grew twenty years ago) and why I think it’s the only genuinely hard, genuinely defensible thing left to build in this space.

Part 3: the layer nobody wants to build, with durable state, task leases, and evidence.