Method · Doc

DARE vs. Other Methodologies

Comparisons — DARE vs other approaches

An honest comparison between DARE and other common methodologies / practices. Each one has an ideal scenario — there is no "absolute winner".

🌪️ DARE vs Vibe Coding

Vibe Coding = "Give me code that does X" + hope.

Dimension DARE Vibe Coding
Structure 4 mandatory phases None
Speed to prototype Medium High
Speed to evolve High Drops with complexity
Auditability Full None
Production risk Low High
New dev onboarding Easy (DESIGN/BLUEPRINT explain it) Hard (read the code to grasp intent)
Learning curve Medium Zero

When to use Vibe Coding instead of DARE

When NOT to use Vibe Coding

📋 DARE vs BDD (Behavior-Driven Development)

BDD = behavior specification through "Given / When / Then" scenarios before implementation.

Dimension DARE BDD
Focus Overall structure of dev with AI Behavior specification
Who writes specs Human (DESIGN) + AI (BLUEPRINT) Human (with PO/QA)
Granularity Feature → architecture → tasks Behavioral scenario
Execution AI implements with the Ralph Loop Human implements to make scenarios pass
Do they combine? Yes — fully —

How to combine them

BDD scenarios can be inputs to DESIGN.md in the "Success criteria" or "Use cases" section. BLUEPRINT.md references these scenarios when deciding on tests. The task-NNN.md files list the scenarios as Validation Gates.

✅ DARE vs TDD (Test-Driven Development)

TDD = the Red → Green → Refactor cycle. Write the test before the code.

Dimension DARE Classic TDD
Focus Overall structure of dev with AI Test coverage via test-driven design
Who writes tests AI (in the task spec) Human
Who writes code AI Human
"Red" equivalent Validation Gates failing Test failing
"Green" equivalent Ralph Loop until gates pass Code making test pass
Do they combine? Yes —

How to combine them

DARE's Execute phase naturally incorporates TDD when tasks are defined test-first:

# task-005

## Validation Gates
- npm test -- src/auth/jwt.spec.ts  ← TESTS FIRST
- npm run typecheck
- npm run lint

## Specification
Create JwtService with sign() and verify() methods.
The tests in src/auth/jwt.spec.ts already exist (created in task-004).
Implement to make the tests pass.

The AI runs the Ralph Loop trying to make the test pass — exactly the Red → Green cycle of TDD, but with the AI as the agent.

🏗️ DARE vs Waterfall

Waterfall = sequential phases: Requirements → Design → Implementation → Testing → Deploy. No iteration.

Dimension DARE Waterfall
Sequential Yes, but iterative between phases Yes, no going back
Granularity Feature/task Entire project
Time between phases Minutes / hours Weeks / months
Going back allowed Yes, and encouraged No (by design)
Suitable for AI Yes No — AI requires iteration

DARE may look like Waterfall because it has phases. It isn't: the Design → Architect → Review → Execute cycle runs per feature (minutes to hours), not per project (months). And there is explicit feedback between phases.

🌀 DARE vs Agile / Scrum

Agile/Scrum = an organizational framework with sprints, backlog, retros, etc.

Dimension DARE Scrum
Level Tactical (how you develop) Organizational (how you plan and deliver)
Unit Technical task User story
Cadence Per feature Per sprint
Do they replace each other? No —

DARE operates inside Scrum. Each user story in the sprint becomes a DARE feature with its own Design → Architect → Review → Execute cycle. It works well in both worlds.

🚀 DARE vs Spec-Driven Development (SpecKit, and similar)

Spec-Driven = tools like SpecKit (Anthropic), Spec by Example, etc.

Dimension DARE Spec-Driven (general)
Structure 4 canonical phases Varies by tool
Implementation Markdown + IDE commands Specific DSL + tooling
Lock-in Zero (pure markdown) Medium-High (depends on the tool)
Validation mechanics Ralph Loop with bash gates Tool-specific
Focus Generalist, IDE-agnostic Usually a single stack/scenario

DARE is less opinionated about tooling — you implement it in Cursor, Antigravity, or wherever you like. Spec-Driven usually comes with proprietary tooling.

🎯 When to use what — quick guide

Question: will the code ship to production and last?
  ├─ NO → Vibe Coding (fast and disposable)
  └─ YES → continue...

Question: does the domain have well-defined behavioral requirements?
  ├─ YES → DARE + BDD (scenarios in DESIGN.md)
  └─ NO → continue...

Question: do you have a large team / multiple simultaneous PRs?
  ├─ YES → DARE + Scrum (Scrum organizes, DARE executes)
  └─ NO → plain DARE

Question: do you want maximum test coverage?
  ├─ YES → DARE + TDD (test-first in the task specs)
  └─ NO → DARE with minimal gates

🔗 Related topics