Skip to content

The Intent-Driven Development Landscape

A reference map of where "spec-driven" / "intent-driven" agentic development comes from, who is building it in 2025–2026, why everyone converged at once, and where anvil sits in that picture.

Status: living reference. Compiled 2026-06-16 from a multi-agent research pass (competitor teardowns of github/spec-kit and DietrichGebert/ponytail, a fan-out web-research run with adversarial claim verification, and an audit of the fakoli plugin suite). Claims marked [V] were verified 3-0 or 2-1 by independent adversarial reviewers; everything else is analysis or domain knowledge and is labelled as such. Source list at the bottom.

0. TL;DR

  1. "Spec-driven development" is not new — only its agentic packaging is. The idea that an authoritative specification of intent should be the source of truth and code a derived artifact runs back through Readme-Driven Development (2010), Model-Driven Architecture (2001), TLA+ (1999), BDD (2006), literate programming (1984), and — most relevant to us — declarative infrastructure-as-code's "desired state" model.

  2. 2025–2026 saw a sudden convergence. GitHub Spec Kit, AWS Kiro, Tessl, claude-task-master, BMAD-METHOD, Agent OS, OpenSpec and others independently arrived at the same thesis within ~12 months. This is parallel invention driven by shared forces, not one project copying another.

  3. Almost all of them stop at the same place: stateless prompt-scaffolding. They generate markdown artifacts (spec / plan / tasks) and hand them to an agent. They do not maintain durable canonical state, exclusive task leases for parallel agents, or evidence-based verification. The few that do (Praetorian's internal platform; anvil) are the exceptions that prove the gap is real.

  4. anvil's moat is the layer the wave skips. It arrives at the same "desired state" thesis but from the infrastructure lineage (Terraform), and then goes one layer deeper: SQLite canonical state, lease+heartbeat task claiming, hook-captured evidence, and three-source reconciliation. That layer is structurally hard for a stateless scaffolder to add without becoming a different product.

1. The lineage — where the idea actually comes from

The through-line across all of these: a human-authored description of intent is the primary artifact; the executable is generated/derived from it. Each ancestor contributes one piece of the modern paradigm.

Year Idea One-liner What it contributed Cite
1984 Literate Programming (Knuth) Write the program as prose explaining intent, with code woven in. Intent-first authoring; the explanation outranks the code. (domain)
1999 TLA+ (Lamport) Formal spec language for designing & verifying systems before implementation. "Spec before code" to surface design flaws before implementation. [V] [TLA+]
2001 Model-Driven Architecture (OMG) Models are the primary artifact; code is generated by automated transformation. The literal "model/spec is source of truth, code is derived" thesis + forward engineering. [V] [MDA]
~2003 Domain-Specific Languages Narrow languages that express intent in domain terms. Raising the abstraction level from how → what. (domain)
2006 Behavior-Driven Development (Dan North) Express acceptance criteria as executable Given/When/Then. Executable specifications; acceptance criteria as the contract. Built on DDD + Connextra user stories. [V] [BDD]
2010 Readme-Driven Development (Tom Preston-Werner) Write the README before any code. "A perfect implementation of the wrong specification is worthless." Spec-as-authority, in plain English. [V] [RDD]
~2014 Declarative Infrastructure-as-Code (Terraform et al.) Declare desired state; the engine computes the diff and converges reality to it. The fakoli lineage. plan/apply, canonical state file, drift detection. (domain)
~1998→ Amazon Working-Backwards / PR-FAQ Write the press release and FAQ before building. Intent (the customer outcome) authored before implementation; org-scale discipline. (domain)
2017 Software 2.0 (Karpathy) Specify a goal; let optimization search for a program that satisfies it. "Intent as source of truth, the artifact is compiled." Dataset = source code; trained net = derived binary. [V] [SW2.0]
2023–24 "Vibe coding" (Karpathy, popularized 2025) Prompt-and-pray code generation. The anti-pattern the 2025 wave defines itself against. (domain)

The synthesis the modern wave makes: take MDA's "model is source of truth," express it in RDD's natural language instead of UML, make it executable in BDD's sense, aim it at an LLM instead of a code generator, and (the part most projects forget) borrow IaC's durable state + plan/apply discipline.

2. The 2025–2026 wave — a field guide

All of these appeared or exploded in roughly a 12-month window. The critical axis for us is the last three columns: State / Execution / Verification. "Stateless scaffolding" means it emits markdown and trusts the agent; "durable state" means there is a canonical store that survives the session.

Project What it is Core paradigm Traction* State Execution Verification
GitHub Spec Kit specify CLI + slash-command templates for 30+ agents Spec-Driven Development: constitution → specify → plan → tasks → implement Very high (GitHub-backed, ~100k★+) Stateless — markdown artifacts in .specify/, flat JSON; no DB [V] Delegated to the host agent; lightweight YAML workflow engine, fan_out sequential Human-in-the-loop; LLM self-grades a checklist [V]
AWS Kiro Spec-driven AI IDE (agentic) spec → design → tasks, persisted as files in the IDE workspace High (AWS-backed) Spec-anchored (files persist & evolve) IDE-native agent execution Hooks + human review; no cross-agent leasing
Tessl Spec-centric AI dev platform / "spec registry" Spec-as-source: the spec is the durable artifact, code regenerated from it Funded startup, high interest Spec-anchored → spec-as-source ambition Platform-managed regeneration Spec is the test surface
claude-task-master (eyaltoledano) MCP/CLI that turns a PRD into a task graph PRD → tasks → expand → execute, task-list driven Very high (popular OSS) Task list in files (tasks.json) Drives the host agent task-by-task Per-task "done"; no evidence gate / no leases
BMAD-METHOD "Breakthrough Method of Agile AI-Driven Development" Persona agents (analyst/PM/architect/dev) produce docs → stories High (popular OSS) Document artifacts (PRD, architecture, stories) Role-played agents, sequential Human review between roles
Agent OS (buildermethods) Spec + standards layer for coding agents standards + product spec + per-feature specs Moderate–high File-based specs + standards Host agent Human review
OpenSpec Lightweight spec-change workflow Proposed change specs reviewed before implementation Moderate, growing Spec files in repo Host agent Human review of change spec
Pimzino/spec-workflow-mcp MCP server for a spec workflow + dashboard requirements → design → tasks via MCP Moderate Files + MCP-served state Host agent Dashboard tracking
Praetorian internal platform Deterministic AI orchestration (writeup) LLM as nondeterministic kernel inside a deterministic runtime Internal / blog Durable dual-state (ephemeral JSON + persistent YAML), resumable [V] Parallel developer agents Evidence-based: independent Reviewer+Tester must pass; lockfile leases .claude/locks/{agent}.lock [V]
anvil Local-first SQLite state engine + MCP/CLI Terraform-for-agents: PRD=config, SQLite=state, apply=commit Early / first-party Durable canonical SQLite (WAL) + append-only/hash-chained event log Lease+heartbeat claims, conflict groups, worktrees Evidence contract per task; hook-captured, gate-enforced

* Traction is approximate and changes fast; treat as order-of-magnitude. Only the [V]-marked architectural claims were independently verified.

The maturity spectrum (a useful lens) [V]

The spec-compare project frames SDD as a three-stage spectrum — a clean way to place every project above:

  1. Spec-First — spec is written, used to generate, then discarded. (Most "write a PRD then code" flows; spec-kit's default mode leans here.)
  2. Spec-Anchored — spec persists and evolves alongside the code. (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 original dream.)

Note this spectrum is about the spec's durability. anvil adds an orthogonal axis the spectrum doesn't capture: the durability of execution state — claims, evidence, audit — not just the spec.

3. Why the convergence happened now

Multiple independent teams reached "spec/intent is the source of truth, code is derived" within ~12 months. The forces driving it (analysis, corroborated by the cited commentary):

  1. The capability threshold got crossed. Models got good enough that the bottleneck moved off code generation. Praetorian states it directly: "The primary bottleneck in autonomous software development is not model intelligence, but context management and architectural determinism." [V] Once the model can write the code, the scarce thing becomes steering it.

  2. The vibe-coding backlash. 2025's "prompt-and-pray into production" produced enough pain that the industry reached for structure. Spec Kit is explicitly positioned as a reaction — LLMs as "over-eager junior engineers" that produce better output with crisper requirements. [V] Spec-driven development is, in part, "waterfall strikes back" (a framing its critics use too).

  3. Determinism & auditability needs. Spec Kit was born from John Lam's research into making LLM development "a tiny bit more deterministic." [V] Enterprises can't ship nondeterministic black boxes; a durable spec is the determinism handle.

  4. Context-window / memory limits. A long build exceeds any context window. State has to live outside the conversation, which pushes toward externalized specs (and, if you follow the logic all the way, externalized state — the part most projects stop short of).

  5. Multi-agent coordination. The moment you run more than one agent, you need a shared source of truth and a way to stop them colliding. This is what forces the more serious projects (Praetorian, anvil) past scaffolding into leases and locks. [V]

The convergent-evolution reading: these aren't copies of each other. They're independent responses to the same environment — the way eyes evolved independently many times because light is a constant. Intent-as-source-of-truth is the "eye" that the 2025 LLM environment keeps re-growing.

4. The gap — what almost nobody is building

Sort the field by three capabilities and the picture is stark:

Capability Who has it
Durable canonical STATE (survives session reset, lives with the repo, queryable) Praetorian (dual-state) [V]; anvil (SQLite). Kiro/Tessl persist specs but not execution state.
Exclusive task LEASING for parallel agents (claims, locks, stale reaping) Praetorian (lockfiles) [V]; anvil (lease+heartbeat). Spec-kit, task-master, BMAD, Agent OS, OpenSpec: none.
EVIDENCE-BASED verification (independent proof, not self-report) Praetorian (Reviewer+Tester gate) [V]; anvil (evidence contract + hook capture). Everyone else: human-in-the-loop or LLM self-grades. [V]

The headline: the entire popular tier of the wave is stateless prompt-scaffolding. The two systems that close the gap (Praetorian's internal platform and anvil) arrived there independently — which is the strongest possible external signal that the gap is real and that durable state is the defensible layer.

5. Where fakoli sits — the three-layer model

The fakoli suite maps cleanly onto the paradigm, and its three plugins solve orthogonal problems:

  • fakoli-crew — the personality engine. Role-specialized agents (guido, critic, warden, scout, smith, welder, herald, keeper, sentinel) with durable personas, tool allowlists, and file-ownership rules. Durable role identity is independent of state management — it stays valuable even as dispatch mechanics commoditize.
  • fakoli-flow — the spec/gate engine. Intent-driven plans (what + acceptance criteria, not how) + critic gates + wave dispatch. Its own spec names the one thing it cannot do: team/task state is ephemeral, lost on context reset. That is the gap it hands to state.
  • anvil — the anvil. The durable, repository-scoped, evidence-bearing state layer. SQLite canonical store, lease+heartbeat claims, hook-captured evidence, six-dimension scoring, recursive expansion, three-source reconciliation.

Two things make fakoli's position distinctive in this landscape:

  1. It came from the infrastructure road, not the spec road. Where Spec Kit descends from John Lam's LLM-determinism research, anvil descends from Terraform's desired-state model — plan/apply, a canonical state file, drift detected and reported rather than papered over. Same destination, older and more battle-tested lineage. (See the author's own writing: "Documentation Is Infrastructure," "Platform Engineering Is Product Management," and the explicit Terraform analogy in "Plan, Claim, Apply: Building anvil.")

  2. It is built on the layer the wave skips. Intent-as-source-of-truth is now table stakes; spec-kit, Kiro, Tessl and a dozen others have it. Durable, lease-coordinated, evidence-gated state is not. That is the anvil — and "the hammers are becoming commodities; the anvil is mine."

Strategic implications (carried over from the competitive analysis)

  • Moat (technical): intact. No popular project has the state/leasing/evidence layer, and adding it contradicts the "stateless, runs-anywhere" thesis most of them sell.
  • Exposure: distribution, category narrative, spec-authoring polish, and self-proof. Spec Kit owns the "SDD" term and the mindshare; Kiro/spec-kit lead on spec-authoring craft (constitution, clarify, checklists-as-"unit-tests-for-English"); ponytail shows the power of benchmark-backed proof.
  • The wedge: integrate, don't compete. spec-kit/Kiro/task-master all end where anvil begins — they emit a tasks.md and have no execution-coordination layer. Ingest their artifacts as a PRD/task source and the pitch becomes: "they plan; fakoli coordinates the parallel, evidence-gated execution."
Priority Move Why
1 Self-benchmark harness (N agents on a fixture repo, with/without anvil; measure collisions, duplicate work, rework, % tasks with valid evidence) and publish it Closes the proof gap; no competitor can run this benchmark because they have nothing to measure
2 spec-kit / task-master artifact ingestion (parse tasks.md / tasks.json as a PRD source) Turns the 100k★ gorilla into top-of-funnel
3 Pre-claim PRD-quality checklist gate; wire fakoli-style principles ledger as the "constitution" Closes the only real spec-authoring craft gap, reusing parts already built
4 CI drift-canary for README ↔ registry ↔ marketplace.json Hardens an existing weakness; ponytail proved the canonical-source + generated-copies + CI-canary pattern
5 Broaden discipline beyond Claude Code via an integration-ABC pattern (spec-kit's IntegrationBase is the blueprint) Defends the portability flank long-term

7. Sources

Primary / verified anchors:

  • [RDD] Tom Preston-Werner, Readme Driven Development (2010-08-23) — https://tom.preston-werner.com/2010/08/23/readme-driven-development
  • [SW2.0] Andrej Karpathy, Software 2.0 (2017) — https://karpathy.medium.com/software-2-0-a64152b37c35
  • [BDD] Cucumber, BDD History — https://cucumber.io/docs/bdd/history/
  • [MDA] Model-Driven Architecture — https://en.wikipedia.org/wiki/Model-driven_architecture
  • [TLA+] TLA+ — https://en.wikipedia.org/wiki/TLA+
  • GitHub Spec Kit — https://github.com/github/spec-kit
  • Den Delimarsky, GitHub Spec Kit (origin / John Lam) — https://den.dev/blog/github-spec-kit/
  • Praetorian, Deterministic AI Orchestration — https://www.praetorian.com/blog/deterministic-ai-orchestration-a-platform-architecture-for-autonomous-development/
  • spec-compare (maturity spectrum) — https://github.com/cameronsjo/spec-compare

Catalog / comparison / commentary:

  • Martin Fowler, SDD with 3 tools — https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
  • ThoughtWorks, Spec-Driven Development: unpacking 2025's new practices — https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices
  • Reenbit, BMAD vs Spec-Kit vs OpenSpec — https://reenbit.com/bmad-vs-spec-kit-vs-openspec-choosing-your-spec-driven-ai-framework/
  • Tim Wang, Spec-Kit, BMAD and Agent OS — https://medium.com/@tim_wang/spec-kit-bmad-and-agent-os-e8536f6bf8a4
  • Daniliants, Understanding SDD: Kiro, Spec Kit and Tessl — https://daniliants.com/insights/understanding-spec-driven-development-kiro-spec-kit-and-tessl/
  • Tessl, A look at Spec Kit — https://tessl.io/blog/a-look-at-spec-kit-githubs-spec-driven-software-development-toolkit/
  • Marmelab, SDD: Waterfall Strikes Back (critique) — https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html
  • Augment Code, Multi-agent AI production requirements — https://www.augmentcode.com/guides/multi-agent-ai-production-requirements
  • BCMS, Spec-Driven Development — https://thebcms.com/blog/spec-driven-development
  • HN discussions — https://news.ycombinator.com/item?id=45935763 · https://news.ycombinator.com/item?id=47197595

Author's own thread (parallel-invention evidence, the author's own blog):

  • Platform Engineering Is Product Management for Infrastructure (2025-11-15)
  • Documentation Is Infrastructure (2026-02-15)
  • Teaching AI Agents to Work Like a Team — fakoli-crew (2026-03-25)
  • From Pressing Buttons to Intent-Driven Flow — fakoli-flow (2026-04-04)
  • Intent Should Be Durable / Building the Engine — Baara (2026-04-05)
  • State Is the Product (2026-04-19)
  • Plan, Claim, Apply: Building anvil (2026-04-24)
  • The Fakoli Style: An Operating Model for Building With Agents (2026-05-01)
  • The Anvil, Not the Hammers (2026-06-10)

Appendix: verified claims (adversarial vote in brackets)

Each was independently checked by 3 reviewers; a claim survived unless ≥2 voted to refute.

  1. [3-0] RDD coined by Tom Preston-Werner, 2010-08-23: write the README first. [RDD]
  2. [3-0] RDD: "A perfect implementation of the wrong specification is worthless." [RDD]
  3. [3-0] Karpathy coined "Software 2.0" (Nov 2017): NN weights, not human instructions, are the program. [SW2.0]
  4. [3-0] Software 2.0 = specify a goal, let optimization search for a satisfying program. [SW2.0]
  5. [3-0] Software 2.0 frames the dataset as the real source, the trained net as compiled/derived. [SW2.0]
  6. [3-0] BDD created by Dan North (2006 "Introducing BDD"), as a response to TDD. [BDD]
  7. [3-0] BDD's Given/When/Then drew on DDD (Evans) + Connextra user stories (Davies). [BDD]
  8. [2-1] Spec Kit = toolkit for SDD; specs become executable and generate implementations. [spec-kit]
  9. [3-0] Spec Kit credits John Lam's research as primary influence. [spec-kit]
  10. [3-0] Spec Kit frames traditional dev as code-centric and inverts it: spec as source of truth. [spec-kit]
  11. [3-0] Spec Kit = stateless prompt-scaffolding: markdown artifacts, no persistent execution engine. [spec-kit]
  12. [3-0] Spec Kit born from John Lam's research into making LLM dev more deterministic. [den.dev]
  13. [3-0] Spec Kit is architecturally a CLI that downloads pre-baked prompts/templates; no durable state engine. [den.dev]
  14. [2-1] Spec Kit positioned as backlash against vibe-coding; verification stays human-in-the-loop. [den.dev]
  15. [3-0] Praetorian: the bottleneck is context management & architectural determinism, not model intelligence. [praetorian]
  16. [3-0] Praetorian: dual-state model (ephemeral JSON + persistent YAML) survives session resets / resumable. [praetorian]
  17. [3-0] Praetorian: parallel agents coordinate via .claude/locks/{agent}.lock to prevent races. [praetorian]
  18. [3-0] Praetorian: code can't be marked complete until independent Reviewer + Tester pass. [praetorian]
  19. [3-0] OMG launched Model-Driven Architecture in 2001. [MDA]
  20. [3-0] MDA: models are the primary artifact; code derived via automated transformation. [MDA]
  21. [3-0] MDA emphasizes forward engineering: producing code from human-authored models. [MDA]
  22. [3-0] TLA+ = formal spec language (Lamport) for modelling/verifying concurrent & distributed systems. [TLA+]
  23. [3-0] TLA+ specs are formal logic/math meant to uncover design flaws before implementation. [TLA+]
  24. [3-0] spec-compare defines the SDD maturity spectrum: Spec-First → Spec-Anchored → Spec-as-Source. [spec-compare]

Refuted (did not survive): "Spec Kit defines a fixed eight-command workflow where the spec is the executable artifact / compiled specification" — [0-3 killed]: the command set is not a rigid eight, and spec-kit does not literally compile the spec; code remains agent-generated and human-reviewed.