Method · product development
Value-stream mapping
The Lean Enterprise Institute maps decisions and handoffs across functions before redesigning the work.
Read the LEI method ↗ Navigation Explore Code Guide
20 methodologies mapped 8 recommended stacks
AI-assisted development methodologies
AI-assisted development doesn't mean using Claude the same way for every project. Different team sizes, maturity levels, and contexts need different approaches.
12 questions · under 2 minutes · no sign-up
Find your methodology stack
Answer 12 short questions about how you work. We will match you to the methodology stack that fits your workflow, team size, and context, not just a single technique.
Question text
Your methodology stack
Best match
Also a good fit
The two-axis map
Every methodology sits somewhere on two axes. Knowing where you need to be narrows the field fast.
Spec-first vs code-first
The spec-first side makes intent explicit before implementation: SDD uses feature specs, while BDD uses shared behavior examples. BMAD spans direct building for a clear fix and deeper planning for uncertain work. These positions describe a workflow choice, not a permanent property of a tool.
Lightweight vs governed
This axis compares the setup and coordination cost of development workflows. Lightweight methods can use one file and short feedback cycles; governed methods add traceability and explicit gates. It does not classify the Toyota Production System or Lean management. For flow and stop rules in AI-assisted delivery, see the review-admission method.
Positioning map (20 methodologies)
SPEC / PLANNING FIRST
▲
── light · spec ── │ ── governed · spec ──
│
[Doc-Driven] [SDD] │ [BDD] [ATDD] [Req-Driven]
[GSD] [Plan-First] │ [CDD] [ADR-Driven] [DDD] [BMAD full]
│
LIGHTWEIGHT ──────────────────┼────────────────────────────────► GOVERNED
│
── light · code ── │ ── governed · code ──
│
[Context Eng.] [TDD] │ [Multi-Agent]
[Prompt Eng.] [Iterative] │ [Eval-Driven] [FDD]
[Ralph Loop] │ [JiTTesting]
│
CODE / EMERGENTBMAD is placed here for its full planning path; a small change can use direct build. Full quadrant analysis: guide/methodologies/
Lean software engineering · across every stack
Test the flow, not just the method
Mary and Tom Poppendieck's software adaptation of Lean asks teams to build quality in and optimize the whole path from customer need to deployed software. A better spec or a faster agent can still leave the request waiting at review, release or adoption. Lean is a delivery lens across the map above, not a twenty-first position on its axes.
| Lean question | Methods to examine | Check in the workflow |
|---|---|---|
| Is the demand worth doing? | SDD · BDD · BMAD | Name the user problem and acceptance condition before expanding a spec. Decline or narrow work without a clear need. |
| Where does work wait? | BMAD · GSD · SDD · Multi-Agent | Map one request through verification and release. Control work in progress at the constrained stage, not just inside the coding step. |
| Is quality built in? | TDD · ATDD · BDD · Eval-Driven | Check behavior early and stop affected work when a test or evidence check fails. Record correction effort as well as pass rates. |
| Can the plan change? | SDD · OpenSpec · BMAD | Keep reversible decisions open. Update a spec when evidence changes the requirement instead of preserving obsolete paperwork. |
| Did the process improve? | Retrospectives · ADRs · verification loops | Turn a recurring failure into an upstream control, then check whether recurrence and effort fall. |
The Kanban Guide makes the flow test concrete with a defined start and finish, work-in-progress control, and four flow measures: WIP, throughput, work-item age and cycle time. Throughput counts finished items, not solved customer problems. Follow one AI-assisted request to the user and define the additional outcome measure.
Method · knowledge work
Kanban
Define the workflow, control work in progress and inspect its four flow metrics. A board by itself does not establish pull.
Read the Kanban Guide ↗Repository · phase checks
RaiSE
Persists workflow state and runs deterministic checks at phase boundaries. The repository describes a mechanism, not a measured user outcome.
Inspect RaiSE ↗Repository · recurring defects
Andon
Records agent defects and proposed countermeasures. Its completion check still depends on the trustworthiness of the recorded evidence.
Inspect Andon ↗Skill packs to test against the flow
These packs encode steps, not a Lean result. Use only the controls that address a real constraint, then check the same request from intake to user outcome.
Integrated workflow · gstack
From demand to release
/office-hours challenges the request; /landing-report exposes the ship queue; /qa checks changed behavior and /retro reviews the work. The full sequence can also add waiting stages.
Composable skills · Matt Pocock
Spec only when the work needs one
/triage handles incoming requests; /to-spec is for work spanning sessions; /to-tickets creates thin, testable vertical slices. /tdd and /retro help close the loop.
8 recommended stacks
These are starting combinations, not measured productivity gains. Add an artifact or gate only when it addresses a real decision, failure or handoff.
Solo MVP Builder
SDDTDD
Keep the feature intent in a short task spec and use TDD for its risky behavior. CLAUDE.md should carry stable repository rules, not become a growing pile of per-feature specs. Check the delivered result as well as test status.
Quick start
Write the user outcome and acceptance checks in a task file; keep stable project rules in CLAUDE.md. Ask for a failing test before implementation.
Team Greenfield
Spec KitTDDBDD
Spec Kit can make feature intent explicit, BDD can align product and engineering on examples, and TDD can check implementation. Use all three when the team has a real alignment or regression problem; record the cost of maintaining the artifacts.
Quick start
Run /speckit.constitution to set guardrails, write Given/When/Then scenarios with your PM, then TDD each scenario.
API Contract Stack
CDDSpecmaticTDD
Contract-first, parallel development. Define your OpenAPI specs before writing a line of code. Specmatic auto-generates tests and stubs from those contracts, so teams can develop independently without integration surprises. TDD handles the implementation behind each contract.
Quick start
Write your OpenAPI spec first, run Specmatic to generate contract tests and stubs, then TDD the implementation behind each endpoint.
Existing Product Evolution
OpenSpecBDDJiTTesting
OpenSpec records proposed changes, and BDD gives stakeholders shared behavior examples. Disposable diff-focused tests are an experiment, not a guarantee against regression or a substitute for Meta’s published JiTTesting system.
Quick start
Set up OpenSpec to capture current specs, write BDD scenarios for the feature you are changing, and add a pre-merge prompt: "Generate tests that catch regressions in this diff."
Enterprise Governance
BMADSpecmatic
Use BMAD for the planning and build path that the change needs, and Specmatic where services have explicit API contracts. Keep one planning source of truth. Add another spec system only if it serves a distinct team or interface need; neither tool proves compliance or delivery value by itself.
Quick start
Choose the BMAD path for one change, from direct build to fuller planning. Add Specmatic contract checks at an actual service boundary; measure review wait and accepted delivery.
AI Product Builder
Eval-DrivenMulti-Agent
TDD for AI outputs. When your product surfaces LLM responses to users, traditional tests are not enough. Eval-driven development gives you measurable quality gates for non-deterministic outputs. Multi-agent orchestration lets you build systems where specialized agents collaborate on complex tasks.
Quick start
Define eval criteria for your AI outputs (accuracy, safety, format), build an eval harness, then iterate until evals pass consistently.
Power User Loop
TDDRalph LoopIterative Loops
Autonomous iteration for experienced Claude users. TDD anchors quality. The Ralph Loop spawns fresh contexts per task so context rot never accumulates. Iterative loops let Claude converge autonomously on complex work. Minimal ceremony, maximum throughput.
Quick start
Set up a CLAUDE.md with your test command, use fresh context per task (git + progress files), and prompt: "Keep iterating until all tests pass and lint is clean."
Structured Planner
Plan-FirstSDDContext Engineering
Think before you code, but do not over-engineer. Plan Mode forces exploration before execution. SDD captures the plan as a spec. Context Engineering ensures Claude has exactly the right information at each step. The sweet spot between ad-hoc coding and heavy governance.
Quick start
Start every complex task in Plan Mode (Shift+Tab), validate the plan, write the spec in CLAUDE.md, then execute with progressive context loading.
At a glance
| Stack | Methodologies | Best for | Setup | Team size |
|---|---|---|---|---|
| Solo MVP Builder | SDD + TDD | Solo, greenfield, quality-first | Minimal | 1 |
| Team Greenfield | Spec Kit + TDD + BDD | 5–10 devs, new project, shared understanding | Moderate | 2–10 |
| API Contract Stack | CDD + Specmatic + TDD | Microservices, parallel teams, explicit contracts | Moderate | 5–20 |
| Existing Product Evolution | OpenSpec + BDD + JiTTesting | Brownfield SaaS, 100+ features, no regressions | Moderate | 3–15 |
| Enterprise Governance | BMAD + Specmatic | Traceable work with API contracts; keep one planning source | Heavy | Any |
| AI Product Builder | Eval-Driven + Multi-Agent | Product exposes AI to users, non-deterministic outputs | Moderate | 1–10 |
| Power User Loop | TDD + Ralph Loop + Iterative Loops | Solo, long sessions, autonomous iteration | Minimal | 1 |
| Structured Planner | Plan-First + SDD + Context Engineering | Architecture-minded, medium codebase, mixed teams | Light | 1–5 |
Want the full picture?
The guide covers all 20 methodologies in depth, with setup instructions, CLAUDE.md templates, combination patterns, and tradeoff analysis.