← Back to SRDD entry page
| Document | Length | Audience |
|---|---|---|
| One-liner | 1-2 sentences | Everyone (hook) |
| Elevator pitch | ~150 words / 60 sec | Networking, intros |
| One-minute read | ~250 words | Time-poor anyone |
| Executive brief | ~600 words | Managers, CTOs, VPs |
| Technical brief | ~800 words | Tech leads, architects |
AI coding is a force multiplier, not a replacement — SRDD keeps developers in control while AI handles execution, so understanding compounds instead of decaying.
Coding at scale and intensity is hard — architecture, interfaces, testing, debugging. AI handles this effortlessly. It’s a genuine advancement. But AI can’t understand architecture beyond its context window. It knows the how, not the why. Businesses that fired their developers are rehiring them. AI is a force multiplier, not a replacement.
So how do we harness AI’s power while keeping developers in control?
Every approach hits the same wall as systems grow: the AI forgets earlier decisions, architectural drift accumulates, teams stop understanding what they’re shipping. Vibe coding forgets. Agentic coding echoes. Spec-driven development fossilizes.
SRDD closes the loop.
Specifications guide implementation — but code becomes the source of truth. Periodically, understanding is extracted back out through regeneration: fresh specs synthesized from the living system, informed by everything learned along the way.
The developer dreams; the AI disciplines. Developers stay hands-on — reviewing, steering, choosing when to regenerate — not deskilled into passengers watching the AI drive off a cliff. Understanding compounds instead of decaying. Systems stay maintainable. Velocity doesn’t collapse at scale.
And when it’s time to rebuild, you’re not reverse-engineering legacy code. The regenerated specs already capture what the system became and what it will become — in English, not yesterday’s code or framework.
Why AI coding matters: Coding at scale and intensity is hard — architecture, interfaces, testing, debugging demand enormous cognitive load. AI handles this effortlessly: identifies broken interfaces, writes tests covering every code path, surfaces edge cases, never gets bored. AI coding is a genuine advancement.
But AI has limits: AI can’t understand architecture beyond its context window. It knows the how, not the why. Businesses that fired their developers are rehiring them. AI is a force multiplier, not a replacement.
The problem: AI-assisted coding accelerates everything — including architectural decay. Vibe coding forgets earlier decisions as context windows overflow. Agentic coding echoes mistakes across autonomous loops. Context engineering curates inputs meticulously but has no mechanism to extract understanding back out. Spec-driven development fossilizes — specs written upfront drift into fiction as reality evolves. Each approach optimises for something real, but none of them close the loop. Teams ship systems they no longer fully understand.
The insight: Vibe and agentic coding externalize nothing. Context engineering curates inputs but never extracts outputs. SDD writes specs upfront and watches them fossilize. SRDD inverts this: specs are snapshots, not contracts. Code evolves. Periodically, understanding is extracted back out — not as rescue, but as a planned phase.
The method: SRDD is a six-phase workflow where specs guide implementation, but code becomes the source of truth. When accumulated drift signals misalignment, regeneration synthesizes fresh specs from the living system — capturing everything learned, surfacing technical debt, and reasserting direction. Then the loop begins again: clearer, cleaner, and ready for the next revolution.
The result: Understanding compounds instead of decaying. Velocity stays high because confidence stays high. Developers remain in control — shaping direction, reviewing PRs, deciding when to regenerate — while AI handles execution.
For larger systems: Scaled SRDD (SSRDD) coordinates multiple independent SRDD loops across domains, enforcing boundaries without bureaucracy.
Bottom line: SRDD makes “burn it down and rebuild properly — keeping everything we learned” a repeatable workflow, not a fantasy.
Coding at scale and intensity is hard. Architecture, interfaces, testing, debugging — all demand enormous cognitive load. AI changes this: it identifies broken interfaces, generates implementations from design documents, writes tests covering every code path, and surfaces edge cases. It works in any framework and never gets bored.
AI coding is a genuine advancement in software development.
AI cannot understand an architecture that exceeds its context window. It doesn’t dream. It cannot generate truly novel ideas. AI knows the how, not the why — why we’re building this software, who it’s for, what problems they’re solving.
Too many businesses assumed AI coding meant they could eliminate most developers. Many did. Those businesses are now rehiring.
AI is a force multiplier, not a replacement.
Spec-Roundtrip Driven Development (SRDD) is an AI-assisted development methodology designed for systems that must remain maintainable over time.
Unlike approaches that treat specifications as fixed contracts or ignore them entirely, SRDD treats specs as snapshots — initially created to establish intent, then periodically regenerated from the living codebase to capture what the system has become and what it will be.
AI-assisted coding delivers significant productivity gains on small projects. But as systems grow, predictable failure modes emerge:
These failures are not unique to any single tool. They emerge from a structural gap: understanding flows into AI-generated code, but nothing flows back out.
SRDD introduces a closed loop:
Regeneration extracts understanding — Periodically, fresh specs are synthesized from the living system, informed by code, PRs, issues, tests, and production discoveries — and incorporating new functional and non-functional requirements for what it will become next.
This is not a rescue operation. It is a planned phase in the system’s lifecycle.
| Outcome | Mechanism |
|---|---|
| Sustained velocity | Confidence enables speed; regeneration prevents the slow hardening that makes change risky |
| Reduced rework | Architectural misalignment is surfaced early, before it becomes expensive to fix |
| Lower onboarding cost | Understanding is externalized into regenerated specs, not trapped in tribal knowledge |
| Retained optionality | Systems remain comprehensible and changeable as requirements evolve |
| Developer retention | Engineers work on coherent systems with clear direction, not archaeological rescue missions |
Traditional systems trap knowledge in code. When that code becomes brittle, you face an unpleasant choice: expensive rewrite or slow decay. And rewrites typically reuse existing code to reduce cost — importing the same architectural constraints into the new system.
SRDD inverts this.
Understanding is continuously extracted into regenerated specs — language-agnostic, architecture-agnostic documentation of what the system does and why. The code is one implementation of that understanding, not the understanding itself.
When technology shifts — and it will — the cost of targeting a new language, framework, or architecture is not significantly higher than rewriting in the same stack. You’re not reverse-engineering legacy code. You’re re-implementing documented understanding, informed by everything learned, with AI doing the heavy lifting.
| Traditional rewrite | SRDD rebuild |
|---|---|
| Reverse-engineer understanding from brittle code | Understanding already captured in specs |
| Reuse old code to save time → import old constraints | Fresh implementation from documented intent |
| Locked to existing language/architecture | Free to target new stack |
| Knowledge walks out the door with developers | Knowledge externalized and versioned |
SRDD doesn’t just maintain systems. It makes them portable across time.
SRDD is a methodology, not a product. Adoption requires:
The methodology can be adopted today using documentation and rules files. Tooling for enforcement (CLI, MCP integration) is on the roadmap.
SRDD suits projects that:
For multi-domain systems, Scaled SRDD (SSRDD) coordinates independent SRDD loops across bounded contexts.
For teams experiencing velocity decay, architectural drift, or loss of system understanding in AI-assisted development, SRDD provides a structured path back to clarity — without abandoning the productivity benefits of AI.
Pilot adoption on a single project with a willing team. Evaluate after one full cycle including regeneration.
Coding at scale and intensity is hard. Architecture, interfaces, testing, debugging — enormous cognitive load. AI handles this effortlessly: identifies broken interfaces, generates implementations from specs, finds every linearly independent path through code (cyclomatic complexity) and writes tests to cover them all, surfaces edge cases, works in any framework, never gets bored. It’s already ingested StackOverflow.
AI coding is a genuine advancement.
AI can’t understand architecture beyond its context window. It doesn’t dream. It can’t generate novel ideas. AI knows the how, not the why — why we’re building this, who it’s for, what problems they’re solving.
Businesses that fired their developers are rehiring them. AI is a force multiplier, not a replacement.
Spec-Roundtrip Driven Development (SRDD) is a six-phase AI-assisted development methodology that maintains architectural coherence through planned regeneration cycles.
Core principle: Specs are snapshots, not contracts. Code becomes the source of truth. Understanding is periodically extracted back out.
| Phase | Purpose | Key outputs |
|---|---|---|
| 1. Design | Establish intent | Planning docs (00-07) |
| 2. Implementation | TDD, scope-guarded development | Code, tests, PRs |
| 3. Review | Coherence validation | Approved PRs |
| 4. UAT | Observe and accumulate evidence | Findings in 07-NextCycle.md |
| 5. Triage | Analyze findings, choose path | Decision: iterate, regenerate, or release |
| 6. Production | Version and release | Tagged release, continued observation |
Each cycle produces a dated planning directory:
docs/plans/2025-01-15_v2_post-regeneration/
00-PLANNING.md ← Requirements questionnaire
01-REQUIREMENTS.md ← Functional and non-functional requirements
02-USECASES.md ← User stories with acceptance criteria
03-QA-SESSION.md ← Clarifying Q&A transcript
04-ARCHITECTURE.md ← Technical design, components, data model
05-IMPLEMENTATION.md ← Phased build plan
06-TESTPLAN.md ← Test strategy
07-NextCycle.md ← Accumulated signals, candidate contracts, version history
During implementation, the AI operates under explicit constraints:
Human review remains mandatory. The AI determines whether code works; the reviewer determines whether it fits.
The AI monitors for spaghettification signals:
When signals accumulate, the AI advises regeneration. The decision remains human.
Regeneration synthesizes fresh specs from multiple sources:
Output: A new dated planning directory describing the system as it now stands — not as it was once imagined.
Key principle: Holistic diagnosis, selective intervention. The entire system is re-understood; only drifted subsystems are redesigned.
For multi-domain systems:
contracts/consumes.yaml| SRDD provides | SRDD requires |
|---|---|
| Sustained velocity at scale | Planning document discipline |
| Externalized understanding | Human judgment at triage/review |
| Managed technical debt | Acceptance that regeneration has real cost (days, perhaps weeks, not hours) |
| Clear audit trail | More ceremony than vibe coding |
SRDD’s regeneration cycle produces specs that are implementation-independent:
This means:
The marginal cost of rebuilding in a new stack versus the same stack is low — because the specs, not the code, carry the knowledge.
Good fit:
Not ideal for:
This delivers 60-70% of value. Tooling for reliable enforcement is on the roadmap.
© 2026 Brooke Smith. All rights reserved.
This repository constitutes a public disclosure and defensive publication of the Spec-Roundtrip Driven Development (SRDD) and Scaled SRDD (SSRDD) methodologies.
The author expressly places the concepts, processes, and workflows described herein into the public domain as prior art, for the purpose of preventing subsequent patent claims or exclusive ownership by third parties.
Commercial use, redistribution, or derivative works of this text require explicit permission from the author.