Method · Doc

The DARE Method — Overview

DARE — Detailed Methodology

Canonical methodology document. Specific implementations (Cursor, Antigravity) follow this document as a contract. Changes here are breaking changes to the method.

🧭 Founding principles

DARE was not invented in a vacuum — it is a response to 3 problems observed in AI-assisted development in 2024-2025:

Problem 1: Vibe Coding scales poorly

When you ask the AI "give me some code that does X" and accept whatever comes back, it works for a prototype. But in a real codebase:

Problem 2: Traditional specification wastes AI

If you write detailed specs the old way (with the human doing all the thinking), the AI becomes just a sophisticated auto-complete. It doesn't leverage real generative capability.

Problem 3: Lack of checkpoints is expensive

AI + full autonomy + complex task = 30 minutes of burned tokens producing code that goes against what you wanted. Without checkpoints, you find out too late.

DARE solves all 3 by separating strategy (human) from tactics (AI) with mandatory checkpoints.

📐 The 4 stages in depth

1. Design — what and why

Who: the human drives, the AI assists with questions

Output: DARE/DESIGN.md

Expected content:

Anti-pattern: A Design that already contains architecture or implementation. If you are writing class names or folder structure, that is Architect, not Design.

Phase 1 details →

2. Architect — how

Who: the AI proposes, the human validates

Output: DARE/BLUEPRINT.md

Expected content:

Anti-pattern: A blueprint without explicit trade-offs. Every choice excludes alternatives — which ones, and why?

Phase 2 details →

3. Review — explicit human approval

Who: the human (decision), the AI does not participate

Output: ✓ approval or rejection with feedback

What to do:

Anti-pattern: A "skim review" — glancing over it quickly and approving. Every architectural bug not caught here costs 10x more in the next phases.

Phase 3 details →

4. Execute — implementation with the Ralph Loop

Who: the AI implements, the human monitors

Output: Code + green tests

How it works:

  1. The AI reads a task-NNN.md (extracted from BLUEPRINT.md)
  2. Implements the code
  3. Runs the Validation Gates (tests + linter + type checker)
  4. If it fails: reads the error, fixes it, tries again (Ralph Loop)
  5. When all gates pass: ✓ task complete
  6. Next task

Anti-pattern: Tasks without Validation Gates. Without gates, "done" becomes an opinion, not a fact.

Phase 4 details →
The Ralph Loop in depth →

🔁 When to go back

Situation Which phase to return to
The Ralph Loop enters an infinite loop (same error 3+ times) Architect — the BLUEPRINT is probably wrong
BLUEPRINT.md becomes huge and confusing Design — the scope is poorly defined
You approved Review but the very first task already reveals a problem Architect — the Review was superficial
A stakeholder changed a requirement Design — don't try to "patch" it — redo it

Going back is not a failure. It is the method working — you found out early, not late.

🚫 What DARE is NOT

📊 When to use it

Scenario Does DARE make sense?
New feature in a serious product ✅ always
Complex bug fix (>1h estimated) ✅ use /generate-bugfix-design
Architectural refactor ✅ explicit Design + Architect
Throwaway POC ⚠️ overkill — Vibe Coding will do
Hello world / learning spike ❌ don't use it
One-shot script (<50 lines) ❌ don't use it

🎯 Principle summary

Humans think. AIs execute. Checkpoints validate.

Every attempt to violate this degrades the quality of the output.

🔗 Further reading