Confidence: Tier 2 — Validated by multiple production reports and official documentation.
Last updated: February 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/.
Multi-agent governance with constitution as guardrail
Enterprise 10+ teams, long-term projects
⭐⭐ Niche but powerful
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) inverts the traditional paradigm: documentation becomes the source of truth, not code. Uses specialized agents (Analyst, PM, Architect, Developer, QA) orchestrated with strict governance. Note: BMAD’s role-based agent naming reflects their methodology; see §9.17 Agent Anti-Patterns for scope-focused alternatives.
Key concept: Constitution.md as strategic guardrail
When to use: Complex enterprise projects needing governance
When to avoid: Small teams, MVPs, rapid prototyping
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
Not just a feature (/plan command) — a systematic discipline.
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
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.
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.