The Evolution of Spec-Driven Development

Architectures, Methodologies, and Frameworks in AI-Assisted Engineering

Enrico Papalini

This article presents a condensed version of the theses developed in *Non-Deterministic Spec-Driven Development: Enterprise Edition* — available on Amazon.com and all local stores.

Abstract

The proliferation of Large Language Models has driven the marginal cost of code generation toward zero, but the initial euphoria surrounding conversational AI coding assistants has been tempered by harsh empirical evidence. A December 2025 analysis by CodeRabbit of 470 open-source GitHub pull requests found that code co-authored by generative AI contained roughly 1.7 times more “major” issues than human-written code, with 75% more misconfigurations and 2.74× more security vulnerabilities. The prompt-and-pray workflow popularized as vibe coding by Andrej Karpathy in February 2025 ships working prototypes in hours yet collapses into unmaintainable sprawl within months — a phenomenon driven less by model weakness than by a structural limitation of transformer architectures known as context rot.

In response, the industry has converged on Spec-Driven Development (SDD): a methodology that treats machine-readable, behavior-oriented specifications — not source code — as the primary engineering artifact and absolute source of truth. This report traces that convergence across four movements. It opens with a cognitive analysis of why vibe coding fails at scale, drawing on the Chroma Context Rot study (Hong et al., 2025), Stanford’s “Lost in the Middle” research (Liu et al., 2024), and commentary from Addy Osmani, Martin Fowler, Kent Beck, and Simon Willison. It then conducts an architectural evaluation of eleven open-source frameworks — from minimalist behavioral nudges to fully autonomous state-machine-driven runtimes. With the practical landscape mapped, the report consolidates the theoretical foundations of SDD (the anatomy of executable specifications, the adversarial agent pattern, the three tiers of rigor, and the relationship to TDD/BDD/MDD), and closes with a cross-framework synthesis that distills fourteen evaluation dimensions into convergence patterns, three Magic-Quadrant classifications (scope/autonomy, governance/weight, team/ceremony), a best-of-breed capability map, and a four-layer adoption stack. The central thesis is that SDD transforms LLMs from unpredictable novelties into dependable engines of software creation by replacing ephemeral conversational context with immutable contractual artifacts.

The Cognitive Limits of AI Agents and the Menace of Context Rot

Spec-Driven Development is best understood as the engineering response to a specific set of failure modes in its predecessor, vibe coding. Practically, it treats AI as a literal-minded pair programmer: high-throughput, but only as reliable as the precision of the intent it receives. This section dissects those failure modes, from their rhetorical origin to their architectural root cause in transformer attention.

The Birth of Vibe Coding

The term was coined by Andrej Karpathy, co-founder of OpenAI and former AI lead at Tesla, in a tweet on February 2, 2025:

“There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

— Andrej Karpathy, X (Twitter), Feb 2, 2025

The programmer guides, tests, and gives feedback about AI-generated source code rather than writing it manually. One year later, Karpathy clarified the term’s narrow original intent: at the time, LLM capability was low enough that vibe coding was mostly useful for throwaway projects, demos, and explorations. He now favors the term agentic engineeringfor professional work, emphasizing that the developer is not writing the code directly 99% of the time but rather orchestrating agents who do, and acting as oversight.

Simon Willison drew a sharp boundary on the definition:

“If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book — that’s using an LLM as a typing assistant.”

— Simon Willison, simonwillison.net, Mar 2025

Willison further warned that vibe-coding into a production codebase is risky precisely because most engineering work involves evolving existing systems, where the understandability of the underlying code is essential.

The Three-Month Wall

Vibe coding is highly effective for zero-to-one exploration, allowing developers to ship functional prototypes rapidly. At scale, however, it invariably hits a “three-month wall”: technical debt compounds, new features require extensive debugging of legacy AI code, and delivery stalls because teams no longer understand their own systems. Addy Osmani, Head of Chrome Developer Experience at Google, describes the emergent antidote as requiring explicit structure:

“AI-assisted engineering is a more structured approach that combines the creativity of vibe coding with the rigor of traditional engineering practices. It involves specs, rigor and emphasizes collaboration between human developers and AI tools, ensuring that the final product is not only functional but also maintainable and secure.”

— Addy Osmani, Beyond Vibe Coding, 2026

Osmani’s widely cited thesis, published on O’Reilly Radar on February 20, 2026 and backed by GitHub’s analysis of over 2,500 agent configuration files, is uncomfortable: AI coding quality fails at the specification layer before it fails at the model layer.

Martin Fowler, Chief Scientist at Thoughtworks, frames the same risk through the lens of non-determinism:

“LLMs will change software development to a similar degree as the change from assembler to the first high-level programming languages. […] With the distinction that it isn’t just raising the level of abstraction, but also forcing us to consider what it means to program with non-deterministic tools.”

— Martin Fowler, LLMs bring new nature of abstraction, June 2025

Fowler’s practical conclusion is that every LLM contribution must be treated as a pull request from a rather dodgy collaborator — very productive in lines of code, but untrustworthy. The root cause of this distrust is not developer intent but a structural limitation within transformer architectures known as context rot.

Context Rot: The Chroma Research

The term was formalized in a July 2025 technical report by Kelly Hong, Anton Troynikov, and Jeff Huber at Chroma. The authors evaluated 18 frontier LLMs — including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3 — and showed that models do not use their context uniformly. Performance grows increasingly unreliable as input length grows, and crucially this is notcontext-window overflow: a model with a 200K token window can exhibit significant degradation at 50K tokens. Figure illustrates the monotonic decay.

Stylized context-rot curves reconstructed from the Chroma (2025) study. All eighteen frontier models tested showed monotonic performance degradation as input length increased — well below their nominal context-window limits.

Hong’s recommended mitigation, expanded on in Husain’s summary of her presentation, is the subagent dispatch pattern: spawn fresh agents for each atomic subtask so that working memory never compounds. This recommendation becomes a recurring design pattern in the frameworks surveyed in §2.

Lost in the Middle and Attention Budget

Context rot is reinforced by two related phenomena. The first, empirically established by Nelson F. Liu and colleagues at Stanford in their TACL 2024 paper Lost in the Middle, is positional bias:

“We observe that performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models.”

— Nelson F. Liu et al., TACL, 2024

LLM retrieval accuracy follows a U-shaped curve (Figure): relevant code found mid-search sits in a blind spot. The second phenomenon, articulated by Anthropic researchers in a September 2025 post, is the attention budget:

“Context must be treated as a finite resource with diminishing marginal returns. Like humans, who have limited working memory capacity, LLMs have an “attention budget” that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount.”

— Anthropic Engineering, Effective Context Engineering, Sep 2025

Stylized reproduction of the U-shaped retrieval curve reported by Liu et al. (2024).

In agentic coding workflows, context rot is amplified through context compounding: as an agent autonomously reads files, executes commands, and generates partial solutions, each output is appended to the active session. A minor hallucination becomes baked into the context for all subsequent turns. Critical architectural constraints and initial requirements get buried, leading the agent to contradict earlier decisions, reinvent existing patterns, and generate unaligned code. Vibe coding fails at scale because it relies entirely on the model’s ephemeral, increasingly polluted short-term memory. Spec-Driven Development emerged to externalize that memory into durable artifacts.

Architectural Analysis of Open-Source AI Frameworks

Before consolidating the theory, it is instructive to survey how the industry has responded in practice. The transition to SDD has catalyzed a Cambrian explosion of open-source tooling. Under different names, each framework still instantiates the same process backbone: Specify, Plan, Tasks, Implement, with an explicit gate at each boundary. Figure groups the eleven frameworks analyzed here by primary functional role, spanning minimalist behavioral nudges to fully autonomous state-machine runtimes. Each subsection that follows presents a framework’s identity, core architecture, and single defining innovation — leaving comparative analysis for §4 and §5.

Taxonomy of the eleven analyzed frameworks, grouped by primary functional role. Frameworks stacked within the same column share its color and belong to the same category. Agent Skills sits alongside Karpathy Skills in the Behavioral & Skill-based category but reaches further into lifecycle coverage through its 21 skills and 7 slash commands.

Karpathy Skills: The Minimalist Behavioral Layer

Derived from commentary by Andrej Karpathy on LLM coding pitfalls, “Karpathy Skills” is an exercise in minimalist governance. It has no execution runtime, no state machine, and no dependencies; it is simply a single ‘CLAUDE.md’ file (or lightweight IDE extension) that injects four principles into any LLM’s system prompt (Table). The distribution ships an ‘EXAMPLES.md’ companion with eight before/after code pairs illustrating each principle in context, and is available as a Claude Code plugin, a Cursor rules bundle, and a raw skill file.

Karpathy Skills: core principles and corrective strategies

Its defining trait is universal composability: the four principles layer atop any other framework or tool. Its defining limitation is unenforceability: compliance depends entirely on the LLM honoring markdown instructions.

Agent Skills: The Three-Layer Composition Toolkit

Agent Skills, maintained by Addy Osmani, packages production-grade engineering workflows as composable Markdown artifacts. Where Karpathy Skills supplies four behavioral principles in a single file, Agent Skills scales the skill-file idea into a full SDLC toolkit: 21 skills, 3 specialist personas, and 7 slash commands. Its defining architectural choice is the three-layer composition model: Skills describe how to perform a workflow (with explicit exit criteria), Personas describe who is performing it (with a specialist perspective), and Commands describe when a workflow is invoked (composing skills and personas into user-facing entry points). A strictly enforced rule keeps the control flow predictable: the user or a slash command is always the orchestrator, and personas never call other personas.

Agent Skills: lifecycle commands and skill activation

Its defining innovation — unique across all eleven frameworks surveyed — is the anti-rationalization table: every skill ships with an explicit list of the excuses agents commonly invoke to skip quality steps (“the tests are flaky anyway,” “we can add types later,” “this edge case is unlikely”), each paired with the correct rebuttal and action. This codifies known AI failure modes as structured knowledge rather than relying on the model to resist shortcut temptations on its own. Additional distinguishing features include:

• Progressive context loading: only skill descriptions (roughly 4K tokens total) are loaded at startup; full ‘SKILL.md’ content is pulled on demand, keeping the baseline context budget an order of magnitude smaller than frameworks that eagerly load all instructions.
• Source-driven development: the DETECT → FETCH → IMPLEMENT → CITE workflow, backed by the ‘sdd-cache’ hook (HTTP 304 revalidation for ‘WebFetch’ calls), grounds decisions in official documentation rather than training-data recall.
• Block-level protection: the ‘simplify-ignore’ hook lets developers mark code regions as off-limits to zealous refactoring.
• Parallel fan-out review: ‘/ship’ spawns the three specialist personas concurrently for pre-launch review, combining their findings before handoff.
• Broad IDE reach: native Claude Code plugin plus setup guides for Cursor, GitHub Copilot, Windsurf, Gemini CLI, OpenCode, and Kiro — seven integrations in all, driven by a plain-Markdown core that works with any agent that can read files.

Its defining limitations mirror its philosophy: skills are advisory Markdown with no programmatic enforcement, there is no persistent memory or cross-session state beyond ‘SPEC.md’ and ‘tasks/’, and no cost tracking or crash recovery. Agent Skills is a composable toolkit, not a runtime.

AI-RPI Protocol: Adaptive Repository Governance

The AI-RPI (Research, Plan, Implement) Protocol is a repo-native SDLC governance framework. It ships with 15 subagents, 12 skills, 23 named behavioral rules, and 21 artifact templates, structured into three phases (Table). A four-tier confirmation classification ([NC] no-confirm, [N] notify, [RC] require-confirm, [NA] never-automatic) governs every destructive action, and a structured memory subsystem (‘decisions.md’, ‘lessons.md’, ‘research-cache.md’, ‘session-state.md’, ‘metrics-log.md’) carries context across sessions without a database.

AI-RPI Protocol: phases, sub-phases, and outputs

Its defining innovation is adaptive ceremony: three protocol levels (ultra-light, lite, full) scale documentation overhead to task risk, while an 8-layer progressive context-loading system enforces soft token budgets to mitigate context rot. A distinctive secondary feature is role-based output packaging: the same work is formatted differently for engineers, tech leads, PMs, and stakeholders.

BMAD Method: Persona-Driven Agile Orchestration

BMAD (Breakthrough Method for Agile AI-Driven Development) approaches SDD through organizational roles. Rather than treating the AI as a monolithic assistant, it introduces specialized agent personas with dedicated system prompts and domain vocabularies — an approach echoed in Thoughtworks’s own multi-agent code-generation experiments, where each step is handled by a separate LLM session with a specific role and instruction set.

BMAD Method: SDLC phases, personas, and artifacts

Its defining innovation is Party Mode, which allows multiple personas to debate within a single session, combined with a TOML-based per-skill customization system and a community module marketplace stratified into official, community, and custom-URL tiers (BMB, CIS, GDS, TEA modules being the notable official packages). A cross-IDE installer auto-generates skill files for Claude, Cursor, Junie, KiloCoder, and several others, and a ‘bmad-quick-dev’ track exists for small tasks that cannot justify full ceremony.

OpenSpec: The Brownfield Change Lifecycle

OpenSpec addresses a specific friction point: applying specifications to legacy systems. Instead of generating monolithic specs, it uses delta specs that represent isolated modifications. Driven by a Node.js CLI, it integrates via slash commands across 24+ AI coding tools including Junie, Lingma, ForgeCode, IBM Bob, Pi, and Kiro. The CLI emits JSON (‘openspec validate –all –json’), making it the most CI-friendly governance tool in the survey.

OpenSpec: action commands and lifecycle effects

Its defining innovation is the actions-not-phases philosophy, enabling parallel development streams where multiple agents work concurrently without cross-contamination.

Spec Kit: Constitutional Governance by GitHub

GitHub’s Spec Kit is an open-source Python CLI that formalizes natural language into executable applications through a sequential command pipeline (Table). It currently supports 27 AI agents out of the box — the broadest agent portability of any framework surveyed — and is extended by 78 community extensions. Addy Osmani highlights its positioning: GitHub’s AI team promotes spec-driven development where specs become the shared source of truth.

Spec Kit: workflow commands and artifacts

Its defining innovation is the Constitution: a persistent governance document of nine articles with mandatory gates (simplicity, anti-abstraction, integration-first, and others) that programmatically constrain AI behavior. A secondary innovation is the 4-level preset stacking resolution (core → extensions → presets → local) with deterministic override rules, making Spec Kit the most composable framework for enterprise customization.

Get Shit Done (GSD v1): Meta-Prompting and Context Isolation

GSD v1 is an opinionated context-engineering system for solo developers, orchestrating 33 specialized agents through 85 commands and 83 workflows across 14 supported runtimes. During execution, it uses a thin orchestrator pattern: instead of accumulating history in a single thread, it spawns fresh subagents for every task, each receiving a pristine 200K token window. This is a direct implementation of Chroma’s subagent mitigation for context rot (§1.3). A distinguishing operational control is agent size-budget enforcement: tiered line-count limits (XL=1600, Large=1000, Default=500) are checked in CI tests, preventing agent-file bloat over time. The system ships a TypeScript SDK (‘@gsd-build/sdk’) with 90+ query handlers.

GSD v1: workflow phases and mechanisms

Its defining innovation is cross-AI convergence: plans are reviewed by a second model (often from a different provider) and iterated until all high-severity concerns are resolved. Secondary innovations include spike/sketch pipelines for pre-phase feasibility experiments and HTML mockup variants.

GSD-2: The Programmatic State Machine

GSD-2 is a standalone TypeScript application built on the Pi SDK that abandons conversational orchestration in favor of a rigid, disk-based state machine. It ships 13 agents, 24 extensions, 35 skills, and 60+ commands across six interfaces (CLI, VS Code extension, Web UI, TUI, MCP server, Telegram bot). It introduces three architectural upgrades over its predecessor:

1. Progressive Planning (ADR-011): the first task slice is planned in detail; subsequent slices are sketches dynamically refined after observing each slice’s execution, with mid-execution escalation when complexity exceeds the current plan.
2. Complete Memory System (ADR-013): a SQLite-backed relational knowledge graph tracking six memory categories (architecture, convention, gotcha, pattern, preference, environment) linked by five relation types (‘depends_on’, ‘contradicts’, ‘supersedes’, ‘derives_from’, ‘validates’), with auto-injection into every task’s context.
3. Code-Enforced Verification: real linters, test runners, and type-checkers gate progression. Failures trigger auto-fix retry loops with exponential backoff — the state machine reads actual subprocess exit codes, so the LLM cannot lie about success.

This architecture directly operationalizes Kent Beck’s advocacy for TDD in the AI era:

“Test driven development (TDD) is a “superpower” when working with AI agents. AI agents can (and do!) introduce regressions. An easy way to ensure this does not happen is to have unit tests for the codebase.”

— Kent Beck, The Pragmatic Engineer, June 2025

GSD-2: core systems and operational impact

Its defining innovation is cost-aware execution: GSD-2 is the only framework that tracks per-unit token and USD costs, enforcing budget ceilings and routing subsequent requests to cheaper fallback models once “budget pressure” thresholds (50%, 75%, 90%) are exceeded. It also stands alone in integrating 20+ LLM providers with capability-aware dynamic routing and fallback chains.

Ralph Copilot: Minimalist Autonomous Looping

Ralph Copilot implements the “Ralph Wiggum” pattern popularized by Geoffrey Huntley. The entire framework consists of four agent markdown files that use the host filesystem and Git as its state store.

Ralph Copilot: agent roles and outputs

Its defining innovation is atomic-commit-per-iteration: by destroying the context window after every git commit, the agent remains in the “smart zone” indefinitely, mathematically preventing context compaction with no infrastructure beyond the filesystem.

Spec Loop Engine: Durable Pipeline Execution

The Spec Loop Engine is a sequential phase runner (roughly 1,200 lines of Python core) designed to ingest massive specifications and execute them through catastrophic system failures. Runners and verifiers are both bound to strict JSON schemas, eliminating natural-language ambiguity in the control flow. Three execution backends are supported (Codex CLI, Claude CLI, shell), and every phase runs in its own sandbox tier. Its defining innovations are two-fold:

• Read-only verifier sandbox: the Executor has full codebase access (‘danger-full-access’), but the Verifier runs in a strict ‘read-only’ environment. This makes it architecturally impossible for the agent to “fix” a failing test by editing the test itself.
• Watchdog-based durability: all state transitions are written to a resumable ‘state.json’ file alongside an append-only JSONL audit journal with per-attempt artifact snapshots. External watchdog scripts detect process death and resume from the exact phase of failure, and can invoke repair passes on blocked phases autonomously during overnight runs.

AIDD: Vision-Anchored Autonomous Discipline

AIDD (AI-Driven Development) is a CLI-first autonomous workflow that combines strict intent anchoring with lightweight execution ergonomics. Its defining rule is vision precedence: a project-local ‘vision.md’ outranks ad-hoc prompts and acts as a hard conflict check before implementation. The framework adds quality-as-CI-property through explicit gates (notably churn and eval checks), so quality regressions are caught as pipeline failures rather than post-hoc review comments. In comparative terms, AIDD occupies a useful middle ground: more disciplined than minimalist autonomous loops, far lighter than heavyweight state-machine runtimes.

The Mechanics and Paradigms of Spec-Driven Development

Having surveyed the landscape of tools, we can now consolidate the theoretical foundations that unify them. Spec-Driven Development is a methodology in which machine-readable, behavior-oriented specifications serve as executable contracts. The core principle inverts traditional agile dynamics: the specification dictates intent, and code is a transient byproduct. Osmani captures the shift of source-of-truth in one line:

“Write a structured specification before writing any code. The spec is the shared source of truth between you and the human engineer — it defines what we’re building, why, and how we’ll know it’s done.”

— Addy Osmani, agent-skills repository, 2026

The Anatomy of an Executable Specification

For an AI agent, a specification differs fundamentally from a traditional Product Requirements Document. Traditional documents are written for human engineers who can infer missing context; AI agents fill gaps with statistically probable hallucinations instead. Osmani advocates hybrid formality: writing like a PRD ensures user-centric context (“the why behind each feature”), while expanding like an SRS nails down the specifics the AI needs to generate correct code.

A robust specification comprises six foundational elements:

1. Outcomes — precise definitions of verifiable user journeys and success states.
2. Scope boundaries — explicitly declaring what must not be built.
3. Constraints — non-negotiable technical requirements and performance thresholds.
4. Prior decisions — established patterns such as chosen database schemas.
5. Task breakdown — atomic execution units that fit safely within a fresh context window.
6. Verification criteria — how the implementation will be audited goal-backward.

Crucially, specifications are not write-once artifacts. They must be living documents, updated as decisions are made or new information is discovered, and treated as version-controlled documentation.

The Adversarial Agent Pattern

To execute specifications reliably, the industry has converged on the adversarial agent pattern (Figure). A Coordinatordecomposes the specification, Implementors execute sub-tasks, and a Verifier checks output against the spec. The Verifier’s incentive is inverted relative to the Implementor: it seeks failures rather than completions, catching hallucinations that self-verifying agents rationalize away. Kent Beck describes the failure mode this pattern prevents as the LLM’s tendency to “just change the test” when it cannot make the code pass — a behavior the read-only verifier sandbox (§2.10) makes architecturally impossible.

The adversarial agent pattern. The Verifier’s incentive is inverted relative to the Implementor.

The Three Tiers of SDD Rigor

Fowler and colleagues at Thoughtworks distinguish three tiers of SDD adoption (Figure), each representing a different commitment to the specification as source of truth.

The three tiers of Spec-Driven Development rigor.

At Tier 1 (Spec-First), a specification is meticulously drafted before any code is generated, but the source code becomes the ultimate source of truth once generation completes. At Tier 2 (Spec-Anchored), the specification is preserved post-implementation and kept in bidirectional sync with the code as the system evolves. At Tier 3 (Spec-as-Source), the specification is the only artifact a human touches; code is entirely derivative, regenerated on demand, and never manually edited. Tools at Tier 3 (e.g., Tessl) often insert headers into generated source code explicitly warning developers not to edit the files.

Methodological Distinctions: SDD vs. TDD, BDD, and MDD

SDD shares philosophical roots with TDD, BDD, and MDD but operates at a distinct architectural layer (Table). TDD and BDD are “Specification by Example” methodologies that leave broader architectural choices open to human interpretation. SDD acts as a comprehensive system-level contract, catching defect classes — API contract drift, architectural violations, security anti-patterns — that unit tests miss. Fowler makes the MDD parallel explicit: SDD is the natural-language descendant of UML-based model-driven efforts, with the twist that LLMs force a reconsideration of what it means to program with non-deterministic tools.

Comparison of software methodologies

Rebecca Parsons, former CTO of Thoughtworks, captured the deeper implication, as relayed by Fowler: hallucinations are not a bug of LLMs but the feature — all an LLM does is produce hallucinations, and some of them happen to be useful. SDD is the discipline that filters useful hallucinations from harmful ones.

Thematic Dimensions of AI Agent Architectures

Evaluating the eleven frameworks across a fixed set of structural dimensions reveals both convergence patterns and deliberate divergences. The fourteen dimensions below form an evaluation rubric that organizations should apply before committing to a toolchain: twelve core dimensions plus two operational dimensions specific to autonomous systems.

Framework Scope & Purpose

The most important evaluation question is: what layer of the stack does the framework occupy? The eleven tools do not compete head-to-head; they occupy fundamentally different niches along a spectrum from passive behavioral nudges to fully autonomous runtimes. Karpathy Skills acts as a minimalist composable behavioral layer; Agent Skills extends that skill-file idea into a full SDLC toolkit with 21 skills, 3 personas, and 7 slash commands. AI-RPI and Spec Kit serve as governance protocols that dictate how AI should plan and document work but do not execute commands. OpenSpec and BMAD climb another rung by modeling change lifecycle and full agile SDLC respectively. GSD-2, Ralph Copilot, Spec Loop Engine, and AIDD are complete execution runtimes that autonomously read specifications, write code, run tests, and commit to git without intermediate human approval. The practical implication: a single framework is almost never sufficient. Karpathy Skills without an orchestrator leaves the agent directionless; GSD-2 without a behavioral foundation produces correct-but-idiosyncratic code. The strongest setups layer tools from different scopes (§5.8).

Execution Model (Human-Driven vs. Autonomous)

Agent Skills, AI-RPI, BMAD, OpenSpec, and Spec Kit are inherently human-driven: each phase transition (or skill invocation) requires explicit human engagement. This creates tight oversight but makes these tools poor fits for overnight batch work. GSD-2, Ralph Copilot, Spec Loop Engine, and AIDD provide genuine walk-away capability through different mechanisms: GSD-2 uses a formal state machine; Ralph Copilot relies on a shell-level infinite-loop script; Spec Loop Engine employs watchdog processes; AIDD combines CI-gated quality loops with vision-anchored execution discipline. The philosophical divide is whether autonomy requires heavyweight infrastructure or can be achieved with lightweight filesystem primitives plus strict gates, and both camps have produced working systems in 2025–2026.

Agent Architecture

Frameworks organize their AI workforce through distinct patterns. BMAD adopts a persona-driven architecture, betting that role specialization narrows each agent’s cognitive scope. GSD v1 takes the microservices approach to an extreme, deploying 33 specialized subagents coordinated by a thin orchestrator that never writes code. Ralph Copilot goes in the opposite direction with a tight four-role loop. Agent Skills adopts a distinctive skill-first, persona-light posture — 21 skills carry the engineering workflows while only 3 personas (code-reviewer, security-auditor, test-engineer) handle specialist review, with an explicit anti-pattern prohibiting persona-to-persona routing. AI-RPI sits between the extremes, notably dedicating 6 of its 15 subagents entirely to specialized code review (architecture, conventions, documentation, patterns, security, test-quality) — reflecting the empirical finding that review is where LLMs are most likely to make catastrophic errors when self-evaluating. The key tradeoff is context isolation versus coordination overhead: more subagents mean cleaner context windows per task but more state to pass between them.

Quality & Verification

Verification is where frameworks diverge most dramatically. Karpathy Skills relies solely on behavioral nudges with no enforcement mechanism. Agent Skills introduces a unique countermeasure — anti-rationalization tables in every skill that explicitly rebut the excuses LLMs use to skip quality steps (“the tests are flaky,” “types can come later”) — but the tables themselves remain advisory Markdown. OpenSpec checks artifact coherence but not whether code actually works. AI-RPI deploys a 6-layer validation model (execution checks, behaviour checks, acceptance mapping, uncertainty reporting, review lenses, reviewer focus) but all layers remain prompt-driven and depend on LLM honesty. GSD-2 and Spec Loop Engine enforce programmatic verification: real linters (ESLint, Prettier), real test runners (Jest, Vitest, Pytest), and real type-checkers (TypeScript ‘tsc’, Python ‘mypy’) gate progression, with auto-fix retry loops on failure. The state machine reads actual subprocess exit codes, so the LLM cannot misreport success. Spec Loop Engine’s read-only verifier sandbox additionally prevents the agent from tampering with tests. Agent Skills’ ‘/ship’ command offers a third path: a parallel fan-out of three specialist personas reviewing in concert, which is thorough but still advisory.

Governance Philosophy

Three distinct philosophies emerge. Behavioral governance (Karpathy Skills, Agent Skills, AI-RPI) relies on voluntary LLM compliance with textual rules — cheap to implement but offering no hard guarantees; Agent Skills hardens this posture with anti-rationalization tables that counter known shortcut patterns, a partial structural overlay atop advisory text. Structural governance (Spec Kit, OpenSpec, BMAD) constrains through schemas, templates, and mandatory artifact sections; empty required fields are mechanically detectable, but the agent can still produce hollow boilerplate content. Programmatic governance (GSD-2, Spec Loop Engine, AIDD) uses deterministic code or CI-enforced gates that physically prevent progression until conditions are satisfied — expensive to implement but essentially immune to compliance drift, because the LLM is never asked to self-police.

IDE & LLM Portability

Spec Kit currently leads portability by supporting 27 different AI agents out of the box (Claude Code, Cursor, Windsurf, Codex, Cline, Aider, Gemini CLI, and more), emitting a standard ‘.specify/’ directory that each agent’s rule-loading mechanism can consume. OpenSpec integrates natively with 24+ coding assistants via its slash-command abstraction. Agent Skills achieves portability through simplicity: its plain-Markdown skills work with any file-reading agent, with dedicated setup guides for Claude Code (native), Cursor, Copilot, Windsurf, Gemini CLI, OpenCode, and Kiro. GSD v1 supports 14 runtimes and GSD-2 takes a different portability angle, targeting 20+ LLM providers via dynamic routing and fallback chains. Frameworks built as standalone CLIs (GSD-2, Spec Kit, OpenSpec, Spec Loop Engine) enjoy an inherent advantage over plugins tethered to specific editors.

Extensibility & Customization

Spec Kit provides the most sophisticated extensibility: a 4-level preset stacking resolution (core → extensions → presets → local) with deterministic override rules, plus 78 community extensions. GSD-2 uses a manifest-declared extension architecture with typed hooks, a plugin API (25 bundled plugins), and 24 first-party extensions, mirroring Webpack and Rollup. BMAD adopts a marketplace model distinguishing official, community, and custom URL modules with different trust levels. Agent Skills provides limited extensibility through Claude Code plugin hooks (‘sdd-cache’, ‘simplify-ignore’, pre-commit, post-commit), but its skill format is inherently extensible — adding a capability is as simple as adding a Markdown file. Karpathy Skills and Ralph Copilot resist extensibility as a design principle, arguing that every extension point is an opportunity for complexity to creep back in — defensible for personal tools but limiting for enterprise adoption.

Memory & State Persistence

Most frameworks rely on ephemeral session files: when the session ends, the agent has no durable recollection beyond what is committed to git. This works for one-shot tasks but fails for multi-week efforts. GSD-2 is unique in implementing a full SQLite relational knowledge graph. Six memory categories (architecture decisions, conventions, gotchas, patterns, preferences, environment facts) are linked by five relation types (‘depends_on’, ‘contradicts’, ‘supersedes’, ‘derives_from’, ‘validates’). Before each task, GSD-2 queries the graph for relevant nodes and injects them into the agent’s context. AI-RPI takes a lighter approach with structured markdown files (‘decisions.md’, ‘lessons.md’, ‘research-cache.md’, ‘session-state.md’, ‘metrics-log.md’) loaded as persistent project context at the start of every session. Spec Loop Engine generates an append-only JSONL audit trail optimized for forensic reconstruction. Agent Skills explicitly avoids memory: ‘SPEC.md’ and ‘tasks/’ are session artifacts, not persistent knowledge. The consensus is clear: durable, queryable memory is a prerequisite for AI agents tackling work spanning more than a few days.

Context Window Strategy

Frameworks divide into two philosophical camps on token management. The first attempts to maximize useful contextthrough intelligent loading; AI-RPI exemplifies this with its 8-layer progressive system (Layer 0 base invariants always loaded; Layer 1 persistent project context; Layer 2 runtime classification; Layer 3 phase-relevant guidance; Layer 4 skills; Layer 5 subagents; Layer 6 relevant docs and files; Layer 7 guardrail escalation, with soft per-Depth file-count budgets of roughly 4–6 loads at minimal, 8–12 at balanced, and 12–20 at full). Agent Skills applies the same principle at a different granularity: only skill descriptions (roughly 4K tokens) load at startup, and full ‘SKILL.md’ bodies are pulled on demand. The second camp (GSD v1, GSD-2, Ralph) pursues the opposite strategy: destroy the context and spawn fresh. Every atomic task begins with a pristine subagent that receives only the minimum briefing needed, executes, and terminates. This is the only approach that defeats context rot by construction, at the cost of making cross-task reasoning harder.

Planning Sophistication

Static, upfront plans are the original sin of waterfall development, and frameworks vary greatly in how well they avoid repeating it. GSD-2’s ADR-011 sketch-then-refine architecture plans only the first slice in detail; subsequent slices are sketches refined only after the preceding slice executes, with mid-execution escalation when complexity exceeds the original plan. No other framework in this analysis offers mid-execution plan rewriting. GSD v1 employs cross-AI convergence, looping between planner and reviewer agents (often from different providers) until high-severity concerns are resolved. AI-RPI scales planning depth proportionally to risk, routing trivial fixes to one-paragraph plans and high-risk migrations to full technical specifications with ADRs and rollback procedures. Agent Skills’ ‘spec-driven-development’ skill provides a structured 4-phase planning pipeline (Define → Spec → Plan → Tasks) with explicit exit criteria at every gate.

Cost & Resource Awareness

Financial oversight is almost entirely ignored by the ecosystem, with one exception. GSD-2 tracks per-unit token and USD costs, attributing each to specific tasks and models. It enforces hard budget ceilings (default $50/session), projects run-rates, and uses budget-pressure thresholds (50%, 75%, 90%) to dynamically route subsequent requests to cheaper fallback models — downgrading from Claude Opus to Claude Haiku once pressure exceeds 75%, for example. All other frameworks assume the user will monitor spend externally, which is inadequate for autonomous overnight runs where cost awareness must be embedded in the execution loop itself.

Crash Recovery & Durability

In autonomous systems, surviving failures is a prerequisite for viability. GSD-2 uses lock files, session forensics, and exponential backoff to survive rate limits, server disconnects, and process crashes. Every state transition is fsync’d to disk; provider errors (429, 503, 529) trigger backoff with jitter rather than session loss. Spec Loop Engine achieves similar durability via constant writes to ‘state.json’ combined with external watchdog scripts that detect process death and relaunch from the exact phase of failure, typically within 30 seconds. The other eight frameworks lose all context on crash — tolerable for human-driven workflows but fatal for walk-away autonomy.

Knowledge Management

Extracting value from completed work ensures compounding velocity. GSD-2 auto-ingests lessons learned and gotchas into its relational memories table: when the agent discovers that a particular library requires a non-obvious initialization order, that gotcha is captured as a memory node linked to the relevant architecture node, surfacing automatically in any future session touching that subsystem. Agent Skills contributes a different form of codified knowledge — the anti-rationalization tables capture known AI failure modes as structured per-skill knowledge, the only framework to do so. Its source-driven-development skill (DETECT → FETCH → IMPLEMENT → CITE) plus the ‘sdd-cache’ hook grounds decisions in official documentation rather than training-data recall. GSD v1 packages ‘/gsd-spike’ findings into reusable project-local skills. Spec Kit uses its versioned Constitution to permanently encode project conventions in human-reviewable, auditable form. Frameworks without explicit knowledge management (Karpathy Skills, Ralph Copilot) rely on git history alone, which is low-bandwidth: unstructured prose does not lend itself to targeted retrieval.

Team vs. Solo Orientation

Each framework’s architectural assumptions reveal its target user. BMAD is inherently team-first, mirroring agile ceremonies with sprint governance, management personas (PM, Architect), formalized handoff protocols, and artifacts designed for stakeholder review (PRFAQs, sprint summaries). AI-RPI provides role-based output packaging: the same work is formatted differently for tech leads (architectural diagrams, risk analyses), stakeholders (feature summaries, acceptance criteria), and PM-founders (product framing summaries with scope edges and acceptable cuts). GSD v1, GSD-2, Ralph Copilot, Spec Loop Engine, Karpathy Skills, and Agent Skills are solo-developer architectures, designed to act as an individual’s personal engineering team. The practical guidance: match the framework’s social assumptions to your organization — a two-person startup should not adopt BMAD’s full ceremony, and a 200-person engineering org should not rely solely on Ralph Copilot.

Cross-Framework Synthesis and Strategic Layering

The fourteen dimensions of §4 reveal dozens of individual design choices. This concluding chapter distills them into six synthesis lenses: three visual Magic Quadrants (scope/autonomy, governance/weight, team/ceremony), convergence patterns where the industry has independently agreed, a best-of-breed capability map, a gap analysis showing why frameworks are complementary rather than competitive, and a concrete four-layer integration strategy. Read this synthesis as the junction of three views introduced across Part I: process spine (four phases), artifact lens (instructions/prompts/agents/skills), and ecosystem map (five families). Taken together, these lenses answer the question: what does the collective evidence tell us about the correct shape of an AI-native engineering pipeline?

The Magic Quadrant: Scope vs. Autonomy

Plotting the eleven frameworks against the two most discriminating dimensions — execution autonomy and architectural complexity — yields four strategic groupings (Figure):

• Top-Right — Comprehensive Execution Engines: heavy-duty, fully autonomous SDLC platforms. GSD-2, Spec Loop Engine, and AIDD.
• Top-Left — Orchestrators & Methodologies: deep frameworks requiring a human in the loop. BMAD, AI-RPI, Spec Kit, GSD v1.
• Bottom-Right — Lightweight Autonomous Loops: full autonomy without massive architecture. Ralph Copilot.
• Bottom-Left — Behavioral & Lifecycle Tools: lightweight, composable, human-driven. Karpathy Skills, Agent Skills, and OpenSpec.

The AI Engineering Frameworks Magic Quadrant (Scope vs. Autonomy). Four strategic groupings emerge from plotting execution autonomy against architectural complexity.

Convergence Patterns: Where the Industry Agrees

When independent teams arrive at the same design choice without coordination, that choice is almost certainly correct. Table enumerates the patterns on which the eleven frameworks — developed by different authors, in different languages, targeting different user populations — have nonetheless converged. These are not coincidences; they are the crystallizing canon of Spec-Driven Development.

Convergence patterns across the eleven frameworks

The final row deserves particular attention. The fact that eight of eleven frameworks have no crash recovery whatsoever is the single largest systemic weakness in the current generation of tooling. As autonomous runs become longer and more expensive, the absence of durability will increasingly be treated as a disqualifying flaw rather than a missing feature. AIDD adds a second frontier contribution: quality-as-a-CI-property via churn and eval gates, turning quality from aspiration into a regression-tested invariant.

Governance vs. Implementation Weight

The first divergence spectrum — how each framework enforces discipline — maps naturally onto a second dimension: the architectural weight required to deliver that enforcement. Plotting governance style (X axis) against implementation cost (Y axis) produces a second Magic Quadrant (Figure) that explains the price of rigor. Reliability rises from left to right, but so does the cost of the surrounding machinery. The correct position depends on the organization’s appetite for hard guarantees.

• Top-Right — Heavyweight Programmatic: code-enforced governance inside large runtimes. GSD-2.
• Top-Left — Heavyweight Behavioral/Structural: rich methodologies enforced by prompts, personas, or templates. BMAD, Spec Kit, AI-RPI, GSD v1.
• Bottom-Right — Lightweight Programmatic: minimal code with schema/sandbox enforcement. Spec Loop Engine, Ralph Copilot, AIDD.
• Bottom-Left — Lightweight Behavioral: advisory Markdown with negligible infrastructure. Karpathy Skills, Agent Skills, OpenSpec.

Magic Quadrant: Governance Style vs. Implementation Weight. Reliability rises rightward; cost rises upward. Spec Loop Engine’s bottom-right position illustrates that programmatic enforcement does not require a heavyweight runtime.

Two observations stand out. First, Agent Skills’ anti-rationalization tables pull it slightly to the right of Karpathy Skills — still fundamentally advisory, but with a partial structural overlay that counters known failure modes. Second, Spec Loop Engine proves that the top-right corner is not the only way to achieve programmatic enforcement: roughly 1,200 lines of Python core, JSON schemas, and a read-only verifier sandbox deliver hard guarantees without the architectural surface area of GSD-2.

Social Orientation vs. Ceremony Weight

The second divergence spectrum — who the framework is for — combines naturally with a third dimension: how much process ceremony the framework imposes to do its job. Figure plots target audience (solo → team) against ceremony weight (lightweight → heavy process), producing a Magic Quadrant that maps cleanly onto team size and regulatory context.

• Top-Right — Team with Full Ceremony: agile-native frameworks with sprint governance, role packaging, and audit artifacts. BMAD, AI-RPI.
• Top-Left — Solo with Heavy Ceremony: opinionated solo-developer systems that pay the full ceremony cost in exchange for rigor. GSD v1, GSD-2, Spec Kit.
• Bottom-Right — Mixed / Lightweight Collaboration: lifecycle tools usable by small teams without enforcing process weight. OpenSpec, Spec Loop Engine, AIDD.
• Bottom-Left — Solo Minimalist: zero-or-near-zero ceremony, optimized for individual throughput. Karpathy Skills, Agent Skills, Ralph Copilot.

Magic Quadrant: Target Audience vs. Ceremony Weight. Team-oriented frameworks cluster top-right; minimalist solo tools anchor the bottom-left.

The practical implication is that selecting a framework requires plotting one’s own requirements on each of the three Magic Quadrants (scope/autonomy, governance/weight, team/ceremony) before committing. A two-person startup shipping prototypes occupies a radically different position on all three axes than a regulated enterprise shipping financial software.

The Feature Landscape: Best-of-Breed by Capability

Table answers a different question: for each distinct engineering capability, which framework represents current industry best practice? The answers are sharply non-uniform — no single framework dominates, which is precisely why strategic layering (§5.8) is essential.

Best-in-class framework per engineering capability

Gap Analysis: How Frameworks Complement Each Other

The eleven frameworks are complementary rather than competitive. The gap in one framework is precisely the strength of another (Table), which is why the right adoption strategy is almost always combinatorial.

Complementary gap-filling across frameworks

Strategic Layering: From Combination to Composition

Treating the eleven frameworks as a composable stack rather than a menu of alternatives is the single most important strategic insight this analysis yields. Figure shows the four-layer reference architecture; Table specifies the concrete artifact handoffs that make the layers cohere into a single pipeline rather than four loosely-connected tools.

The four-layer Spec-Driven Development reference architecture.

Concrete integration points between layers

The bidirectional arrows from Layer 4 back to Layers 3 and 2 are what transform the stack from a static pipeline into a learning system. A failing test becomes a delta-spec revision; a recurring bug class becomes a new Constitutional article or anti-rationalization entry; a pattern of successful micro-prompts becomes an update to the behavioral foundation. This is the AI-native analogue of what Martin Fowler calls the feedback flywheel: each AI interaction generates useful signal, and systems that capture and promote that signal into durable infrastructure improve continuously, while systems that discard it stagnate.

What an Ideal Unified Framework Would Look Like

Drawing the best from each of the eleven, a hypothetical next-generation SDD framework would combine:

• Karpathy’s four behavioral principles as an immutable system-prompt foundation;
• Agent Skills’ anti-rationalization tables and progressive skill-description loading as the portable knowledge layer;
• Agent Skills’ three-layer composition model (Skills / Personas / Commands) as the workflow primitive;
• Spec Kit’s nine-article Constitution as the structural governance layer;
• AI-RPI’s adaptive-ceremony classifier to size planning depth to task risk;
• BMAD’s persona model for work that must traverse multiple organizational roles;
• OpenSpec’s delta-spec isolation pattern for all brownfield changes;
• GSD v1’s thin-orchestrator pattern dispatching fresh subagents per atomic task, plus cross-AI plan convergence for high-risk plans;
• GSD-2’s SQLite relational knowledge graph for durable cross-session memory;
• GSD-2’s ADR-011 progressive planner for mid-execution adaptation;
• GSD-2’s code-enforced verification gates with auto-fix retry loops;
• GSD-2’s budget-pressure dynamic model routing for cost discipline;
• Ralph Copilot’s atomic-commit-per-iteration for context hygiene;
• Spec Loop Engine’s read-only verifier sandbox and watchdog-based crash recovery for true walk-away durability;
• AIDD’s vision-precedence rule and CI-enforced quality gates as a quality-as-code layer.

Building a tool like this is a substantial engineering undertaking. However, every primitive on this list has been proven in production by at least one open-source project in 2025–2026, meaning the ingredients were all on the shelf.

Instead of waiting for a team to integrate them, I have tried to combine these frameworks into a single one that keeps the best elements for the Enterprise SDLC. The result is the **Enterprise SDD framework**, available at https://github.com/popoloni/enterprise-sdd.

Closing Argument

The central thesis of this report is that Spec-Driven Development is not a single methodology but a convergence point: the place where the cognitive limitations of LLMs (Chroma’s context rot, Stanford’s lost-in-the-middle, Anthropic’s attention budget) meet the engineering wisdom of Karpathy, Osmani, Fowler, Beck, Willison, and Parsons, and crystallize into a new discipline. The eleven frameworks surveyed here are the first generation of tooling for that discipline. They are imperfect, occasionally incompatible, and collectively still leave major gaps — durability, cost, memory, learning feedback — only partially solved. But together they have established the shape of the answer.

Vibe coding succeeded as a rhetorical device because it named a visceral new experience. Spec-Driven Development will succeed as a practice because it names a durable new discipline. Through explicit constraints, isolated execution contexts, adversarial verification, and programmatic governance, SDD transforms Large Language Models from unpredictable novelties into dependable engines of software creation. As Kent Beck observed alongside Martin Fowler at the Pragmatic Summit, the landscape is still being explored — but the direction is now unambiguous. The engineering organizations that invest in this discipline today will compound velocity for years; those that continue to treat AI coding as vibes-and-prompts will spend the next decade paying down the resulting trust debt.

From the book. This article presents a condensed version of the theses developed in *Non-Deterministic Spec-Driven Development: Enterprise Edition* — available on Amazon.com and all local stores.

References

[1] A. Karpathy, “There’s a new kind of coding I call ‘vibe coding’,” X (Twitter), Feb. 2, 2025. https://x.com/karpathy/status/1886192184808149383 [2] A. Karpathy, “One year retrospective on vibe coding / agentic engineering,” X (Twitter), Feb. 2026. https://x.com/karpathy/status/2019137879310836075 [3] S. Willison, “Not all AI-assisted programming is vibe coding (but vibe coding rocks),” Mar. 19, 2025. https://simonwillison.net/2025/Mar/19/vibe-coding/ [4] CodeRabbit Research, “A semantic history of vibe coding: from tweet to production,” Mar. 2026. https://www.coderabbit.ai/blog/a-semantic-history-how-the-term-vibe-coding-went-from-a-tweet-to-prod [5] A. Osmani, Beyond Vibe Coding: From Coder to AI-Era Developer. O’Reilly, 2026. https://beyond.addy.ie/ [6] A. Osmani, “How to Write a Good Spec for AI Agents,” O’Reilly Radar, Feb. 20, 2026. https://addyosmani.com/blog/good-spec/ [7] A. Osmani, “agent-skills: Production-grade engineering skills for AI coding agents,” GitHub repository, 2026. https://github.com/addyosmani/agent-skills [8] M. Fowler, “LLMs bring new nature of abstraction,” martinfowler.com, June 24, 2025. https://martinfowler.com/articles/2025-nature-abstraction.html [9] M. Fowler, “Some thoughts on LLMs and Software Development,” martinfowler.com, Aug. 28, 2025. https://martinfowler.com/articles/202508-ai-thoughts.html [10] M. Fowler, “Exploring Generative AI: Understanding Spec-Driven Development (Kiro, spec-kit, and Tessl),” Oct. 15, 2025. https://martinfowler.com/articles/exploring-gen-ai.html [11] B. Boyter and M. Fowler (eds.), “How far can we push AI autonomy in code generation?,” martinfowler.com, Aug. 2025. https://martinfowler.com/articles/pushing-ai-autonomy.html [12] K. Beck and G. Orosz, “TDD, AI agents and coding with Kent Beck,” The Pragmatic Engineer Podcast, June 11, 2025. https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent [13] K. Hong, A. Troynikov, and J. Huber, “Context Rot: How Increasing Input Tokens Impacts LLM Performance,” Technical Report, Chroma, July 2025. https://research.trychroma.com/context-rot [14] H. Husain and K. Hong, “P6: Context Rot,” LLM Evals course notes, Sept. 2025. https://hamel.dev/notes/llm/rag/p6-context_rot.html [15] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the ACL, vol. 12, pp. 157–173, 2024. https://aclanthology.org/2024.tacl-1.9/ 16] Anthropic Applied AI, “Effective Context Engineering for AI Agents,” Anthropic Engineering Blog, Sept. 2025. [17] Wikipedia contributors, “Vibe coding,” Wikipedia, accessed Apr. 2026. https://en.wikipedia.org/wiki/Vibe_coding [18] G. Huntley, “Everything is a Ralph Loop,” ghuntley.com, 2025. https://ghuntley.com/loop/ [19] GitHub, Inc., “Spec Kit: Bootstrap your next project with Spec-Driven Development,” GitHub repository, 2025. https://github.com/github/spec-kit [20] G. Orosz, “The Pragmatic Summit recordings and summaries,” Feb. 2026. https://newsletter.pragmaticengineer.com/p/the-pragmatic-summit-recordings