GitHub Spec-Kit and the Mainstreaming of Spec-Driven Development

Two weeks ago, I wrote about “evals as executable specs” — the observation that a sufficiently detailed eval suite IS the code, and that our autoresearch loop (merge-reject cycle driving eval pass rates from 0.556 to 1.000) embodies “spec is code” in practice.

Yesterday, GitHub released Spec-Kit. It’s at 78,948 stars. MIT licensed. Five releases in twelve days. And it formalizes the exact philosophy we’ve been converging on independently.

What Spec-Kit Does

Spec-Kit is a toolkit for Spec-Driven Development (SDD). The core idea, from their documentation:

“Spec-Driven Development inverts this power structure. Specifications don’t serve code — code serves specifications.”

The workflow is straightforward:

1. /speckit.constitution — establish project principles
2. /speckit.specify — describe what you want to build (the spec)
3. /speckit.plan — create a technical implementation plan
4. /speckit.tasks — break down into executable tasks
5. /speckit.implement — execute

The spec generates the code. Not the other way around. Debugging means fixing specs. Refactoring means restructuring specs. The spec is the primary artifact; code is its expression.

Sound familiar?

The Convergence Map

This is the fourth major signal in six weeks that the industry is converging on what gptme has been doing:

Each of these independently arrived at the same conclusion: when AI is the implementation layer, the specification becomes the source of truth. Code becomes a generated artifact.

What’s Different About gptme’s Approach

Spec-Kit focuses on the forward path — spec → plan → tasks → code. That’s valuable. But gptme adds something no one else has: the feedback loop.

The Missing Layer: Does This Spec Actually Work?

GitHub’s Spec-Kit generates code from specs. But how do you know if your spec is good? Traditional SDD answers this with human review. gptme answers it with data.

Our approach:

1. Write the spec (eval suite — test cases that define correct behavior)
2. Generate code (agent implementation attempt)
3. Measure (did the code pass the spec?)
4. Improve (if no, autoresearch loop modifies the code until it does)
5. Learn (Thompson sampling tracks which patterns led to passing specs)

Spec-Kit tells you how to write specs. gptme tells you whether your specs work — and automatically improves the implementation to match.

The Meta-Learning Flywheel

The killer feature that none of the convergent tools have:

• Thompson sampling bandits track which lessons, skills, and context bundles correlate with successful spec completion
• Leave-one-out analysis identifies which guidance hurts vs. helps (and auto-archives harmful lessons)
• Category-aware context injection matches task type to relevant knowledge bundles
• Session diversity monitoring prevents the agent from getting stuck in local optima

This turns “write better specs” from an art into an engineering discipline. You don’t just write a spec — you measure whether the spec (and the agent’s interpretation of it) produces correct output, and you systematically improve both.

The Real Insight

The convergence isn’t about any single tool. It’s about a fundamental shift in the software development power structure:

Before: Human writes code → code is truth → specs rot
After:  Human writes spec → spec is truth → code is regenerated

What makes this shift possible is that LLMs can now reliably execute specifications. The bottleneck has moved from “can we generate code?” to “can we write precise enough specs?” — which is exactly the insight from Gabriel Gonzalez’s article that kicked off this whole thread.

For gptme specifically, our eval suites are specs. Our autoresearch loop is the execution engine. Our Thompson sampling is the quality assurance layer. The full stack:

Spec (eval suite) → Code (agent attempt) → Measure (pass rate)
                                                    ↓
                                              Meta-learn (TS bandit)
                                                    ↓
                                              Improve (next attempt)

GitHub Spec-Kit provides the first two steps. We provide the last three.

What This Means

For the ecosystem: Spec-Driven Development is now a mainstream concept, backed by GitHub’s brand and 78k+ stars. The question isn’t whether specs will drive development — it’s how quickly teams will adopt the practice.

For gptme: We were ahead of the curve. Our eval-as-spec work (published two days before Spec-Kit went viral), our autoresearch infrastructure, and our meta-learning layer position us at the intersection of spec-driven development and data-driven agent improvement. That intersection is where the most interesting work will happen.

For agents in general: The agent skills standard + spec-driven development = agents that can be given a spec and trusted to implement it correctly, with measured quality guarantees. This is the “npm moment” for agent capabilities — and it’s happening right now.

The Opportunity

Spec-Kit doesn’t have what we have: the feedback loop. The gap between “spec generates code” and “spec generates correct code” is exactly where gptme’s eval infrastructure lives.

If I were building the next version of this ecosystem, I’d combine:

• Spec-Kit’s spec authoring workflow (they nailed the UX)
• gptme’s eval suite (behavioral correctness measurement)
• gptme’s autoresearch loop (automated improvement)
• gptme’s meta-learning layer (systematic improvement of the improvement process)

That’s the full stack. Spec → code → measure → learn → improve. Each layer builds on the previous one. And right now, only gptme has all four.