Last time I wrote about the three-skill workflow I use to ship payment infrastructure, and about where the bottleneck went once code stopped being the bottleneck.
I thought it was prudent to answer a question I often get when discussing my workflow; 'Why this approach?'. There are a dozen named methodologies in this space now, several of them with more GitHub stars than my entire company has customers, and I picked a particular combination for particular reasons.
So this post is the survey I wish I'd had when I started. I'll walk the landscape first, honestly, including the parts of it I rejected. Then I'll tell you why I landed on spec-driven development plus loop engineering, and what each half is actually doing.
The organizing question
Here's the lens that made this landscape legible to me.
Context windows are volatile memory. They fill, they compact, they lose the thread. Every session ends and takes its understanding with it. So every agentic methodology, every single one, whether or not its authors frame it this way, is an answer to one question:
Where does truth live between agent runs?
That's it. That's the whole taxonomy. Sort the methodologies by where they park durable state and the differences between them stop being marketing and start being architecture.
| Methodology | Truth lives in | Fails when |
|---|---|---|
| Vibe coding | The chat session | The session ends |
| Context engineering | The assembled context / repo files | Assembly is wrong or stale |
| Spec-driven development | A durable spec artifact | The spec drifts from reality |
| Loop-based autonomy | The filesystem + git history | The stop condition is wrong |
| TDD governance | The test suite | Tests encode the wrong contract |
| Multi-agent orchestration | The orchestrator's task graph | A handoff silently corrupts |
Let's go through them.
1. Prompt-native development (vibe coding)
Truth lives in the chat. You describe, you get code, you eyeball it, you continue.
I covered this in part one so I won't relitigate it. I'll just note that it remains the correct tool for spikes, throwaway scripts, and exploring an unfamiliar API, and that its defining property is that nothing survives the session. When the context compacts, your intent compacts with it.
Where it lives on the map: the origin point. Everything else is a strategy for surviving what this one loses.
2. Context engineering (and its cousin, harness engineering)
Truth lives in the assembled context: AGENTS.md, CLAUDE.md, repo conventions, retrieval strategy, file layout designed for agent navigation.
This is the discipline of making sure that whatever the agent reads at the top of a run actually orients it correctly. There's now real research on it, a body of work on structured context engineering for file-native agentic systems, and an emerging line on "harness engineering", which studies the scaffolding around the model rather than the model itself.
I don't think context engineering is a rival methodology. I think it's a substrate. Every other approach on this list is doing context engineering whether it admits it or not, a spec is context, a task list is context, a test failure is context. The people who talk about it explicitly are just being honest about the mechanism.
My take: necessary, not sufficient. A perfectly engineered context still doesn't tell you what to build, or how you'll know it worked.
3. Spec-driven development
Truth lives in a specification artifact that outlives every session.
This is the biggest cluster by far, and it's worth being precise, because "SDD" now names at least four meaningfully different things. The common thread is that a structured specification, usually Markdown, sometimes machine-readable, becomes the authoritative source from which implementation, tests, and docs are derived, rather than documentation written retrospectively.
The variants differ mostly in how much ceremony they impose and how far they push the spec toward being literal source code.
Lean and constitution-driven, GitHub Spec Kit
A four-phase workflow: specify, plan, tasks, implement. Every spec inherits from a project-wide "constitution" that encodes durable rules, stack, conventions, non-negotiables. GitHub's distribution has made it the highest-star option in the category.
Good: minimal ceremony, tool-agnostic, the constitution idea is genuinely excellent. Less good: it's optimized for greenfield and for reasonably-sized changes; small edits fight the phase structure.
Lightweight and brownfield-first, OpenSpec
Purpose-built for modifications rather than net-new work, using delta markers, ADDED, MODIFIED, REMOVED, so a change proposal describes what shifts rather than restating the world.
If your reality is a mature codebase where every task is an amendment, this is the most honest model on the list. It's also the cheapest to run.
Full agile simulation, BMAD-METHOD
The maximalist option: a dozen-plus specialized agent personas, Analyst, PM, Architect, Scrum Master, Developer, QA, passing artifacts down a pipeline that mirrors a full SDLC.
I want to be fair to BMAD, because it's genuinely impressive and it solves a real problem for teams that already think in PRDs and sprint stories. But the critique I find most convincing is structural: a persona pipeline is only as good as its weakest handoff. When the Architect makes an assumption the PM never documented, the Scrum Master faithfully propagates it into stories and the Developer implements it with total confidence. You discover it in QA, or in production. More personas means more handoff surface, and handoff failures are a nasty debugging class because every individual agent behaved reasonably.
The cost is also non-trivial. One consultancy reports BMAD runs averaging in the low tens of thousands of tokens per workflow and monthly frontier-model bills in the high hundreds to low thousands of dollars per developer. Your mileage will vary enormously, but it's not a rounding error.
Environment-native, Kiro, and the platform tier
AWS Kiro is a full IDE with the spec workflow built in from the ground up rather than layered on top. Same for various "agentic development environment" platforms that coordinate agents around a shared living spec.
The trade is explicit: tighter integration in exchange for moving into someone's environment. That's a real cost if your team's tooling is already settled, and a real benefit if it isn't.
Spec-as-source, Tessl and friends
The radical position: the spec is the primary artifact and the code is a build output. Edit the spec, regenerate. The analogy people reach for is Terraform or a SQL query planner, you write intent, the system produces the plan.
I find this directionally correct and practically premature, and I'll come back to why.
4. Loop-based autonomy, the Ralph technique
Truth lives on disk: a task list, per-task specs, logs, and git history.
Geoffrey Huntley named this one in mid-2025 after Ralph Wiggum, on the theory that any single iteration is a plain agent run that might get something slightly wrong, and the loop wins through persistence and a stable source of truth rather than one brilliant prompt. The minimal form is almost insultingly simple, a bash while loop that re-invokes a non-interactive agent until a todo list is exhausted.
The insight that makes it work is the one people miss: each iteration gets a fresh context. A single long session accumulates fatigue, the window fills, compaction drops details, the model loses the thread. A series of short sessions that re-orient from files on disk stays sharp. Progress doesn't live in the chat; it lives in committed code, a task file, and a log the next iteration reads on boot.
There are now many implementations, TUIs for visibility, a Vercel Labs wrapper that loops until a verifyCompletion function passes, and enterprise write-ups running Ralph across dependency-ordered backlogs inside test-gated SDLCs.
The catch, and it's a big one: canonical Ralph runs in --yolo mode. Full permissions, no confirmations. That mandates real sandboxing, and it means the technique in its pure form is unusable on anything where a bad iteration can move money or drop a table.
But note what Ralph actually is. It isn't a replacement for structured development, it's an execution engine for a structure you already have. Its own documentation says as much. That distinction turns out to matter a lot.
5. TDD governance
Truth lives in the test suite. Tests are written first and act as executable specifications, so correctness is defined before generation begins.
This has picked up serious academic attention, work presented at EASE 2026 on TDD governance for multi-agent code generation, and systems like TDFlow building agentic workflows around test-driven cycles. The motivating argument is one every distributed-systems person will recognize: LLMs are non-deterministic, identical prompts produce different outputs, and in multi-agent settings a small logic error propagates across the whole workflow. Automated guardrails aren't a nicety.
The research also finds that test cases reduce ambiguity by functioning as executable specs, which is the same claim SDD makes about prose specs, arrived at from a different direction.
Where it's weak: tests specify behavior beautifully and architecture terribly. A test suite cannot tell you that a module shouldn't know about another module, or that this queue is at-least-once, or why a constraint exists. It's a verification layer, not an intent layer.
6. Multi-agent orchestration
Truth lives in the orchestrator's task graph and shared memory.
Anthropic's 2026 agentic coding trends work describes the shape: an orchestrator coordinating specialized agents in parallel, each with dedicated context, results synthesized into integrated output, as against single-agent workflows that process sequentially through one window.
Addy Osmani's tiering is the most useful practical framing I've found:
- Conductor tier, subagents inside one session. No extra tooling. Your context window is the ceiling.
- Local orchestration tier, multiple agents in isolated git worktrees, with dashboards and merge control. Best at roughly 3–10 agents on a codebase you know.
- Cloud async tier, assign, close laptop, return to a pull request.
The honest counterweight: production-scale orchestration is a multi-quarter engineering effort, observability tooling doesn't work on non-deterministic flows out of the box, and Thoughtworks' radar has been flagging the accumulation of cognitive debt as AI-assisted development scales, the organizational version of the review bottleneck I wrote about in part one.
My take: orchestration is an execution strategy, not a methodology. It answers "how many at once," not "toward what."
The axes that actually matter
Strip the branding and I think you're choosing along five axes:
| Axis | The question |
|---|---|
| Durability | Does intent survive a context compaction? |
| Re-derivability | Can you regenerate the work from the artifact, or only document it? |
| Correction cost | When you're wrong, do you fix one thing or N things? |
| Human position | Where does judgment enter, before, during, or after generation? |
| Overhead | What does one cycle cost in tokens, wall-clock, and ceremony? |
Re-derivability is the one I'd underlined three times if this were paper. Most teams evaluating SDD are asking whether the spec is good documentation. That's the wrong question, and it's the question that gets you a spec nobody maintains.
Why I landed on spec-driven plus loop engineering
Here's my actual reasoning, and it's less about picking winners than about noticing that two of these categories are answering different questions and therefore compose.
The spec is an anchor, and anchors let you re-derive
The property I care about most is durability that enables regeneration.
When I have a well-specified PRD, I'm not holding a description of what got built. I'm holding the thing the work is generated from. That gives me three capabilities I refuse to give up:
One, I can iterate on the same requirement many times. Not "revise the code," revise the requirement, and let everything downstream follow. The unit of change moves up a level.
Two, I can fan out. One artifact spawns many tasks. The PRD is the source; the issues are derived; the implementations are derived from those. That's a tree with a single root I control, not a pile of chat sessions I have to reconcile.
Three, and this is the one that sold me, I can throw implementations away. When an agent goes off the rails on slice four because it invented an assumption nobody wrote down, I don't debug the agent's reasoning or nurse the code back to health. I go to the document, fix the assumption, and regenerate. Completely. As many times as I need to.
The mental shift: implementations became disposable and the specification became the asset. That inverts the relationship I was trained on, where code was the thing you protected and documentation was the thing that rotted.
Notice this is the spec-as-source thesis, but I take it partway, deliberately. I don't accept "the spec compiles to code and you never read the output." In payments I have to be able to read, own, and be on call for what shipped. What I accept is the weaker, more useful claim: the spec is what work is re-derived from. Code stays reviewable and owned. It just stops being precious.
The loop is how the anchor gets corrected
Here's what spec-driven development does not do: guarantee that the spec is right.
A specification is a hypothesis. It's a good hypothesis, it's been through clarifying questions and human review, but it is written before contact with the actual system, and mine are regularly wrong in ways I could not have predicted. Spec-driven development on its own, with no feedback mechanism, is waterfall with better tooling. Same failure mode, faster.
That's what loop engineering is for, and I want to be precise about what I take from it. Not --yolo autonomy. I took the structural insights:
- Fresh context per iteration beats one long degrading session
- State on disk, task files, logs, git history, is the memory layer, not the chat
- An explicit stop condition so the loop ends on a signal rather than a guess
- Verification delegated into the loop so the agent finds its own errors before I do
Applied on top of a spec, the loop stops being brute force and becomes something much more useful: a mechanism that invalidates spec assumptions and pushes corrections back upstream. Validation fails on slice two, the assumption behind it was wrong, the PRD gets edited, and slices three through seven re-derive before an agent ever touches them.
That's the cascade I described in part one. It only works because both halves are present.
Stated as control theory, because that's what it is
For anyone who builds distributed systems, this framing will land immediately:
spec ────────▶ SETPOINT (what "correct" means)
│
▼
agent ────────▶ ACTUATOR (does the thing)
│
▼
loop ────────▶ FEEDBACK (measures the gap, corrects)
│
└──────▶ error signal updates the SETPOINT
when the setpoint was the problem
- Spec without loop is open-loop control. Dead reckoning. Fine until reality diverges from your model, and you find out late.
- Loop without spec is a controller with no setpoint. It will converge on something, reliably, persistently, cheerfully, just not necessarily on what you wanted. Or it oscillates.
- Both is closed-loop control with a defined target and an error signal that can correct the target itself.
That's not a novel idea. It's the oldest idea in engineering, applied to a new actuator. Which is roughly why I trust it more than the approaches that feel newer.
What I took from the others anyway
Methodologies aren't teams. You don't have to pick one and wear the jersey:
- From Spec Kit, the constitution idea. Durable project-level rules every spec inherits, so I'm not restating non-negotiables in every PRD.
- From OpenSpec, delta thinking. Most of my work is amendment, not creation, and specs that describe changes beat specs that restate the world.
- From TDD governance, tests as the loop's ground truth. Property-based and contract tests are what make the agent's self-correction meaningful rather than self-congratulatory.
- From orchestration, parallelism bounded by the dependency graph, and worktree isolation. As an execution strategy underneath the loop, not as the loop.
- From the security research, this one's my favourite. There's work on "constitutional" SDD that embeds non-negotiable security constraints, derived from CWE/MITRE Top 25 and regulatory frameworks, into the specification layer, so generated code satisfies them by construction rather than by inspection. If you read part one, you know why that lands for me. It's the compliance bottleneck, addressed at the only place it can be addressed cheaply: upstream, in the artifact.
And what I rejected, plainly
- BMAD, the handoff surface. In a domain where a silently propagated wrong assumption means a double-charge, I want fewer inter-agent boundaries, not more. Also the token bill.
-
Canonical Ralph, I took the pattern and left the
--yolo. Human gates on money-moving paths are non-negotiable, which is incompatible with the pure form. - Kiro and the platform tier, I'm not moving environments for a brownfield payments codebase. That's a fine trade for other people; it isn't for me.
- TDD governance as a whole methodology, rejected, because tests can't carry architectural intent. But hold this one loosely; I come back to it at the end, and my position on it has changed.
The strongest objection to my position
I'd rather state this than have it stated at me.
The most rigorous comparison I've found of these tools flags two things that should give any SDD advocate pause. First: it's genuinely unclear when SDD adds value versus overhead, for trivial changes, the heavier frameworks are a sledgehammer cracking a nut. Second, and sharper: the historical parallel to Model-Driven Development, which made structurally similar promises in the 2000s and did not survive contact with real software.
I think the counterargument is that MDD failed partly because the generation step was rigid and the abstraction leaked badly, you got code you couldn't touch from models you couldn't express real systems in. LLM-generated implementations are readable, editable, and idiomatic, and specs are prose. That's a materially different failure surface.
But I hold it loosely. The honest version is that the Stack Overflow numbers keep telling us adoption isn't the problem, most developers use these tools and far fewer trust their output. Every methodology on this list is a bet about how to close that gap. Mine is a bet too.
There is no correct answer, and that isn't a cop-out
I want to be careful here, because "it depends" is what people say when they haven't thought about something. I have thought about this, and it still depends, for two reasons that are worth separating.
The first is that your constraints genuinely differ from mine. Blast radius, brownfield versus greenfield, team size, regulatory posture, how much of your work is amendment. Those are real inputs and they point at different answers.
But there's a softer input that I think gets dismissed too easily: your implementation preferences are a real engineering constraint, not a personality quirk. A methodology you abandon in week three has negative value, you paid the setup cost and got none of the compounding. If a seven-persona pipeline makes you want to close the laptop, that's data. Ceremony you won't sustain is worse than ceremony you never adopted.
The second reason is that the ground moves, and it moves fast. Not just the tooling, the models. They differ from each other in ways that matter to methodology design: instruction-following, how gracefully they degrade over long context, whether they ask or assume when a spec is ambiguous, what their characteristic failure modes even are.
Which leads to an uncomfortable observation about this entire field guide:
A large fraction of what we call methodology is really model-specific error correction with a good name on it. Some of these practices exist to compensate for a particular failure mode of a particular generation of model. When the model changes, the compensation may become unnecessary, or insufficient.
So treat everything above, mine included, as a snapshot. Retune when you switch models. Notice which of your rituals are load-bearing and which are scar tissue.
But the shape of the near-optimum is visible
Here's where I'll be less hedging. I don't think there's a perfect methodology. I do think the shape of a very good one is now clear, and it isn't any single entry on this list.
It's three layers doing three genuinely distinct jobs, with no overlap between them:
| Layer | Methodology | Job |
|---|---|---|
| Intent | Spec-driven development | Defines what correct means, and why. Durable, re-derivable. |
| Verification | TDD governance | Determines whether it's correct, mechanically, in a way no agent can talk past. |
| Correction | Loop engineering | Closes the gap, and pushes errors back up to Intent when the intent was the problem. |
Earlier in this post I drew the control loop with two components. That was incomplete, and deliberately so, because I wanted to arrive here. The full picture:
spec ────────▶ SETPOINT what "correct" means
│
▼
agent ────────▶ ACTUATOR does the thing
│
▼
tests ────────▶ SENSOR measures reality, honestly
│
▼
loop ────────▶ CONTROLLER computes the error, acts on it
│
└───────▶ and when the error is in the SETPOINT
itself, corrects upstream
Adding the sensor is not a garnish, and this is the part I got wrong for a while. A feedback loop with an untrustworthy sensor is worse than no loop at all, because it converges, confidently, persistently, at machine speed, on the wrong thing. That is precisely the failure mode of an agent writing its own tests from the same misunderstanding that produced its code. It measures, it agrees with itself, it proceeds.
That's why I've moved TDD governance from "component I borrowed" to co-equal layer. Spec-driven development gives the loop something to converge toward. Test governance gives it something to converge by. Remove either and the third stops working.
Composing rather than choosing
If the three layers are the skeleton, the individual frameworks become a parts bin rather than a set of competing religions:
| Take | From | Because |
|---|---|---|
| Project constitution | Spec Kit | Non-negotiables shouldn't be restated per feature |
| Delta specs | OpenSpec | Most real work is amendment, not creation |
| Fresh context per iteration, state on disk | Ralph | Long sessions degrade; files don't |
| Test-first gating, adversarially derived | TDD governance | The sensor has to be independent of the actuator |
| Worktree parallelism | Orchestration tooling | Execution strategy under the loop, not the loop |
| Constraints in the spec layer | Constitutional SDD | Compliance is cheapest upstream |
Two warnings before you go shopping.
Every layer is an artifact you now have to keep true. Composition has a maintenance cost that compounds, and the failure mode of a hybrid is a spec that no longer describes the system, gating agents that trust it. Adopt a layer only if you'll maintain it.
And don't confuse composition with accumulation. Bolting six frameworks together gets you the union of their ceremony and the intersection of their benefits. The point is to take one thing from each that does a job nothing else does, and to be able to say what that job is.
So, four questions, and they're about composing rather than picking:
- Amendment or creation? → delta specs versus phase-structured ones.
- What's your cost of being wrong? → determines how much sensor you need and where the human gates go.
- Re-derive or just document? → if you'll never regenerate from the artifact, you're maintaining documentation, and it will rot the way documentation always has.
- What ceremony budget will you actually sustain? → answered honestly, not aspirationally.
What I'm building next
The obvious move, once you see the three layers, is to stop treating them as three methodologies you're running concurrently and start treating them as one strategy with a single control flow. Intent, verification, and correction as first-class stages in one system rather than three practices you're manually keeping in sync.
That's what I've been working on. It's a hybrid, spec-driven at the anchor, test-governed at the gate, loop-driven at the correction step, and the interesting problems turn out to be at the seams: how the sensor gets derived from the spec without inheriting its blind spots, and what exactly happens when the loop concludes the setpoint was wrong.
That's the next post.
In the meantime: if you're running a combination I haven't covered, especially if you've made a persona-pipeline approach work at scale, because I would like to be wrong about that, tell me what broke and what held.
Part two of a series on agentic engineering in production. Part one covered the three-skill workflow and where the bottleneck goes when code stops being the constraint. Part three is the hybrid.
Top comments (0)