Spec-Driven Development
A structured operating model for engineering teams building with AI — where the bottleneck has moved from typing to deciding. SDD is the methodology GeekByte uses to run its own work and the backbone behind every advisory engagement. Open, documented, and licensed under AGPL-3.0.
Read the SDD Brief
What SDD Is
Spec-Driven Development is a lightweight operating model for engineering teams where human judgment — not human typing — is the scarce resource.
It assumes AI assistance is everywhere in the stack: drafting specs, proposing architectures, writing implementations, generating tests. The methodology’s job is to put structured gates around that work so the organization still accumulates institutional knowledge instead of disposable output.
Three commitments make SDD different from retrofitted Scrum:
Specs before code, always
No feature, no framework migration, no architectural change begins without a spec file committed to the repository. A plan in a chat window is not a spec.
Gates you can defend
Four gates run every piece of work from intent to production. At each gate, specialist AI agents produce a structured review and a human operator writes the approval — with reasoning, not just a checkbox.
The reasoning is the artifact
SDD captures why decisions were made, not just what was built. Decision Rationale, Gate Annotations, Post-Completion Retros, Learning Log, Stack Quirks — each is a lightweight mechanism for preserving the context that normally evaporates when people move on.
Who It Is For
PE portfolio CTOs and VPs of Engineering
You have AI tooling across the team. Your individual developer productivity metrics look great. Your release velocity has not moved, and your board is starting to notice. SDD gives you a defensible operating model that survives the next integration and the next reorganization.
Engineering managers running small, fast teams
You do not need heavy process. You need the minimum structure that prevents AI-assisted work from generating technical debt faster than you can review it. Start with the pipeline, add mechanisms as you hit the problems they solve.
Solo operators and independent builders
Every gate is a self-review when you are the only person shipping. SDD’s Solo Operator Model uses specialist AI agents as structured second reviewers so you still get the benefit of a gate, without inventing fictional teammates.
The AI Productivity Paradox
Individual developers are measurably faster with AI assistance. Most teams report 20–30% gains on the tasks where AI helps. And yet release velocity, defect rates, and cycle times have barely moved.
The speed gains do not reach production. They are absorbed by the organizational bottlenecks AI did not touch: decision latency, architectural drift, reviewer overload, and institutional memory loss when code outruns documentation.
SDD is a response to that gap. It moves the structure upstream — to the point where decisions are made and recorded — rather than trying to compress the downstream review lane that is already the bottleneck.
Explore the Methodology
The Pipeline
Four gates from intent to production. What each gate produces and who owns it.
Complexity Tiers
Trivial, Standard, Complex, Critical. Right-sizing process to the work at hand.
Preserving the Why
Five lightweight mechanisms for capturing reasoning that normally evaporates.
Anchor Specs
Living documents for domain state, synthesized from transactional specs.
Governance
The Solo Operator Model, tier assignment, gate ownership, escalation rules.
Resources
The methodology brief, the learning bundle, and the anchors explorer.