Confidence: Tier 2, validated by multiple production reports and official documentation.
Last updated: October 2026
This is a quick reference for 15 structured development methodologies that have emerged for AI-assisted development in 2025-2026. For hands-on practical workflows, see workflows/.
Methodologies define how work is planned, checked, and improved. They do not determine whether a product owns the agent loop. Keep the four layers separate: the model generates tokens, the runtime harness executes the loop, the repository harness supplies project-specific feedback, and an orchestrator coordinates multiple runs.
Where each methodology sits on two axes: Spec-First vs Code-First (Y) and Lightweight/Solo vs Governed (X). The second axis describes workflow setup and coordination cost. It does not classify the Toyota Production System or Lean management; for a bounded application of flow and jidoka to AI-assisted delivery, see review-capacity admission.
Top-left (Spec-first lightweight): SDD, Doc-Driven, Plan-First. Natural entry point for solo devs and small teams moving away from “code first”.
Top-right (Spec-first governed): the full planning path of BMAD, Req-Driven, ATDD, DDD. Coordination and traceability can justify more artifacts; BMAD also supports direct building for a small change.
Bottom-left (Code-first lightweight): the natural Claude Code terrain. TDD + Ralph Loop + Iterative = core solo workflow.
Bottom-right (Code-first at scale): Multi-Agent, Eval-Driven, JiTTesting (Meta, 100M+ LoC). Emerging patterns for high-volume teams.
On the axis: Plan-First, CDD, ADR-Driven, GSD, hybrid approaches that adapt to any context.
Lean does not occupy one quadrant of this map. Mary and Tom Poppendieck’s software adaptation asks teams to build quality in and optimize the whole stream from a customer need to deployed software that addresses it. A method can produce a better spec or faster code while the request waits for a decision, review, release, or adoption.
Lean question
Methods already on this page
What to check in the real workflow
Is the demand worth doing?
SDD, BDD, BMAD
Name the user problem and acceptance condition before expanding a spec. Decline or narrow work that cannot be tied to a need.
Where does work wait?
BMAD, GSD, SDD, Multi-Agent
Map one request through verification and release. Set an explicit work-in-progress policy at the constrained stage instead of generating more drafts.
Is quality built into the work?
TDD, ATDD, BDD, Eval-Driven
Run checks early and stop affected work when a test, evaluation, or evidence check fails. A final review alone is a late gate.
Can the plan change with evidence?
SDD, OpenSpec, BMAD
Keep decisions reversible where possible. Update the spec or plan when learning changes the requirement; do not preserve an obsolete artifact for process compliance.
Did the process improve?
Retrospectives, ADRs, verification loops
Turn a recurring failure into a specific upstream check or rule, then observe whether recurrence and correction effort fall.
Is one unit really complete?
SDD, ATDD, TDD, incremental migration
For legacy work, characterize the existing behavior before changing it, deliver one usable unit through verification and release, and check whether the old path can be retired. A source citation or a passing build alone does not establish behavioral parity.
What does the method itself cost?
BMAD, SDD, Multi-Agent, review workflows
Count waiting, false blocks, repeated checks, human takeovers and upkeep as well as accepted changes. Keep a gate only when it prevents a failure or supplies evidence worth its delay.
The Kanban Guide makes flow operational: define when an item starts and finishes, how work in progress is controlled, and how the workflow changes. Its four minimum flow metrics are WIP, throughput, work-item age, and cycle time. Choose boundaries that include the queue you need to diagnose. Those metrics still need a separate user outcome; a finished pull request is not proof that a customer problem was solved. The Lean Enterprise Institute’s product-development mapping is a useful source for mapping decisions and handoffs across functions.
Apply the same test to the methodology itself. A spec that prevents one wrong implementation may earn its preparation and review time; a mandatory spec for a small, reversible correction may only add a queue. Compare the same class of request before and after the method changes, including rework and the time until an accepted result. The repository-harness countermeasure loop shows how to test a control before making it a standing rule.
A workflow also depends on the repository it enters. Factory’s Agent Readiness model checks whether instructions, builds, tests and operational signals make agent work verifiable. This complements SDD or BMAD specifications and TDD checks; it does not replace the Lean question of whether a completed change reaches a user. Fix a repeated repository failure before increasing agent parallelism, then compare the same task type and downstream queue. See the agent workflow example.
Two repositories expose narrower mechanisms. RaiSE describes persistent workflow state and deterministic checks at phase boundaries. Andon records recurring agent defects and proposed countermeasures. Their repositories make design choices inspectable; neither supplies independent evidence of improved customer outcomes. For a worked AI-assisted request map and its evidence limits, use the Lean and AI reading path and the team-metrics chapter.
These packs document repeatable steps. Their Lean relevance is an interpretation to test in a real delivery stream, not a claim made or measured by the projects.
/office-hours challenges demand; /review and /qa check work; /landing-report exposes a ship queue; /retro reflects on completed work.
Does the complete path shorten time to an accepted user outcome, or add planning and verification queues? Its /ship also performs Git and PR actions, so use it only at the intended release boundary.
/triage classifies incoming requests; /to-spec is reserved for work spanning sessions; /to-tickets makes thin, testable vertical slices; /tdd and /retro support quality and learning.
Can the team reject, narrow and complete one valuable slice before starting more? The skills describe controls, not a measured WIP limit or customer result.
The Superpowers pack is another existing guide example of planning, TDD and review gates. More gates can help when they prevent recurring failures, but can also increase wait. Keep the smallest set that addresses the observed constraint and measure WIP, cycle time, rework and user outcome across the same request type.
Thinking and building workflows sized to the change
Small fixes through complex initiatives
⭐⭐ Useful when its artifacts earn their cost
GSD
Meta-prompting 6-phase workflow with fresh contexts per task
Solo devs, Claude Code CLI
⭐⭐ Similar to patterns in guide
BMAD (Breakthrough Method for Agile AI-Driven Development) offers thinking skills and build workflows, with additional planning artifacts for larger or uncertain work. Its current documentation says a clear small fix can go straight to bmad-build; a larger change can start with bmad-spec or a fuller planning path. Role-based agents are an optional part of that system, not evidence that every change needs multiple agents.
Key concept: Size the planning and review path to the change and carry forward decisions that later steps need.
When to use: Use direct build for a well-understood small change; add planning when the decision or coordination cost warrants it.
When to avoid: Do not run a full artifact chain for a clear, reversible fix merely because the framework provides one. Revisit artifacts when requirements change.
Install and run it: see spec-first.md § With BMAD-METHOD for the installer and a choice between direct build and more structured planning.
Canonical repository: bmad-code-org/BMAD-METHOD. The community port linked below (BMAD-AT-CLAUDE) is a Claude Code-specific fork, not the source project.
GSD (Get Shit Done) addresses context rot through systematic 6-phase workflow (Initialize → Discuss → Plan → Execute → Verify → Complete) with fresh 200k-token contexts per task. Core concepts (multi-agent orchestration, fresh context management) overlap significantly with existing patterns like Ralph Loop, Gas Town, and BMAD. See resource evaluation for detailed comparison.
Emerging: Ralph Inferno implements autonomous multi-persona workflows (Analyst→PM→UX→Architect→Business) with VM-based execution and self-correcting E2E loops. Experimental but interesting for “vibe coding at scale”.
“Once the plan is good, the code is good.”
Boris Cherny, creator of Claude Code
A systematic discipline, not just a feature (/plan command).
Context Engineering: Thoughtworks designates this broader approach “Context Engineering” in their Technology Radar (Nov 2025)1, the systematic design of information provided to LLMs during inference. Three core techniques: context setup (minimal system prompts, few-shot examples), context management for long-horizon tasks (summarization, external memories, sub-agent architectures), and dynamic information retrieval (JIT context loading). Related patterns in Claude Code: AGENTS.md, MCP Context7, Plan Mode.
The Mental Model:
Planning isn’t optional for complex tasks. It’s the difference between:
❌ 8 iterations of “try → fix → retry → fix again”
✅ 1 iteration of “plan → validate → execute cleanly”
When to plan first:
Task Complexity
Plan First?
Why
>3 files modified
✅ Yes
Cross-file dependencies need architecture
>50 lines changed
✅ Yes
Enough complexity for mistakes
Architectural changes
✅ Yes
Impact analysis required
Unfamiliar codebase
✅ Yes
Need exploration before action
Typo/obvious fix
❌ No
Planning overhead > task time
Single-line change
❌ No
Just do it
How plan-first works:
Exploration phase (Plan Mode via Shift+Tab):
Claude reads files, explores architecture
No edits allowed → forces thinking before action
Proposes approach with trade-offs
Validation phase (you review):
Plan exposes assumptions and gaps
Easier to correct direction now vs after 100 lines written
Plan becomes contract for execution
Execution phase (toggle back to Normal Mode with Shift+Tab):
Plan → code becomes mechanical translation
Fewer surprises, cleaner implementation
Faster overall despite “slower” start
Boris Cherny workflow:
“I run many sessions, start in plan mode, then switch into execution once the plan looks right. The signature upgrade is verification—giving Claude a way to test and confirm its own output.”
Benefits over “just start coding”:
Fewer correction iterations: Plan catches issues before they become code
Better architecture: Forced to think about structure first
Clearer communication: Plan is shared understanding with team/Claude
Reduced cost: One clean iteration < multiple messy iterations (even if plan phase costs tokens)
Integration with CLAUDE.md:
Document your team’s plan-first triggers:
## Planning Policy
- ALWAYS plan first: API changes, database migrations, new features
- OPTIONAL planning: Bug fixes <10 lines, test additions
SDD (Spec-Driven Development): Make intended behavior explicit before implementation and revise the spec when evidence changes the requirement. A project instruction file such as CLAUDE.md carries stable conventions; it is not automatically the feature specification. Spec Kit’s SDD documentation covers both new and existing projects.
Doc-Driven Development: Living documentation versioned in git becomes the single source of truth. Changes to specs trigger implementation.
Requirements-Driven Development: Uses CLAUDE.md as comprehensive implementation guide with 20+ structured artifacts.
DDD (Domain-Driven Design): Aligns software with business language through:
Ubiquitous Language: Shared vocabulary in code
Bounded Contexts: Isolated domain boundaries
Domain Distillation: Core vs Support vs Generic domains
BDD (Behavior-Driven Development): Beyond testing, a collaboration process.
Discovery: Involve devs and business experts
Formulation: Write Given-When-Then examples
Automation: Convert to executable tests (Gherkin/Cucumber)
Feature: Order Management
Scenario: Cannot buy without stock
Given product with 0 stock
When customer attempts purchase
Then system refuses with error message
ATDD (Acceptance Test-Driven Development): Acceptance criteria defined BEFORE coding, collaboratively (“Three Amigos”: Business, Dev, Test).
In agentic development, ATDD is particularly effective because agents need unambiguous success conditions. The flow maps cleanly to agent tasks:
Define acceptance criteria in Gherkin (human-readable, machine-executable)
Agent writes failing tests based on scenarios (not implementation)
Agent implements until tests pass
Feature: Password Reset
Scenario: User resets via email
Given a registered user with email "user@example.com"
When they request a password reset
Then they receive a reset email within 60 seconds
And the reset link expires after 24 hours
This Gherkin scenario is the contract between intent and implementation. The agent cannot misinterpret scope because done is defined before a line of code is written.
Applied to agents: Pass the Gherkin file to Claude Code before implementing. “Write failing tests for this feature file, then implement until they pass.” The scenario writer role (human or agent) forces explicit scope before execution starts.
CDD (Contract-Driven Development): API contracts (OpenAPI specs) as executable interface between teams. Patterns: Contract as Test, Contract as Stub.
JiTTesting (Just-in-Time Testing): Tests generated on-the-fly at PR submission, designed to fail, then discarded after merge. No maintenance cost, no test suite growth.
TDD/BDD/ATDD all assume the developer controls the pace of code authoring. Agentic development breaks that assumption: an agent can generate 200 lines per hour, faster than any human test-writing workflow can keep up with. JiTTests are the industrial response to that mismatch.
The mechanism: at PR time, an LLM infers the intent of the diff, generates code mutants (deliberately broken variants), writes tests that catch those mutants, runs ensemble rule-based and LLM assessors to filter false positives, and surfaces only real regressions to the engineer. The tests never land in the codebase.
Meta deployed this at scale (100M+ LoC): 4x improvement in catching regressions over traditional hardening tests, 70% reduction in human review load, 4 serious production failures prevented from 41 candidates reviewed.
No open-source implementation exists yet. You can approximate this today: before merging any agent-generated PR, prompt Claude with “generate tests that would catch regressions introduced by this diff specifically. I’ll run them locally and discard them after the PR closes.” The ephemeral framing focuses test generation on what actually changed rather than general coverage.
Prompt Engineering: Foundations for ALL Claude usage:
Zero-Shot Chain of Thought: “Think step by step”
Few-Shot Learning: 2-3 examples of expected pattern
Structured Prompts: XML tags for organization
Position Matters: For long docs, place question at end
Fresh Context Pattern (Ralph Loop): Solves context rot by spawning fresh agent instances per task. State persists in git + progress files, not chat history. Ideal for long autonomous sessions (migrations, overnight runs). See Ultimate Guide - Fresh Context Pattern for implementation.
These are starting combinations, not measured productivity gains. Add a method when it addresses a real decision, defect or handoff. Inspect the resulting queue and maintenance cost.
Situation
Starting combination
What to verify
Solo change with risky behavior
Short task spec + TDD
Accepted behavior and correction effort
Team with recurring requirement misunderstandings
Spec Kit + BDD + TDD
Fewer disputed examples without an oversized spec backlog
Services with explicit API contracts
CDD + Specmatic
Contract failures found before integration
Existing product with changing behavior
OpenSpec + BDD
Current specs match shipped behavior after each change
Complex work across service boundaries
BMAD + Specmatic
One planning source, useful contract checks and manageable review wait
LLM product with recurring output failures
Eval-Driven; add Multi-Agent only for a distinct role
