Open Source Methodology

Multi- Adversarial Agent Driven Development

When AI codes faster than you can specify, your methodology must evolve. MADD provides the framework to control drift and drive convergence between intention and implementation.

The Architecture

6 Agents, Zero Conflict of Interest

Each agent has a unique role. None validates its own work. Domain-specialized Maker/Breaker pairs ensure deep expertise.

🎯
Conductor
Orchestrates workflow
orchestrates
📋
Architect
Formalizes intention
writes intention
📝
Witness
Documents reality
writes retro
📜
CONTRACT
Maker
Implements the contract
🔧
CI
Validates quality
🔍
Breaker
Verifies against the contract
🎯
Agent Conductor

The Workflow Conductor. Coordinates agents, detects domains, manages fraction-based iteration cycles.

  • Manages workflow state and transitions
  • Detects domains per fraction from task annotations
  • Dispatches domain-scoped Maker/Breaker pairs
📋
Agent Architect

The Intention Architect. Formalizes the "why" and "what", annotates tasks with domains.

  • Produces the Intention Document
  • Defines validation criteria
  • Structures the executable contract
Agent Maker

The Maker. Domain-specialized implementation guided by skills.

  • Generates the implementation
  • Respects the contract
  • Documents technical choices
🔧
Agent CI

The Quality Gate. Automated build, lint, type-check, and test validation between Maker and Breaker.

  • Runs build and type-check
  • Runs lint and format checks
  • Runs test suite with coverage
🔍
Agent Breaker

The Breaker. Domain-specialized verification. Challenges without complacency.

  • Analyzes produced code
  • Verifies intention/code alignment
  • Identifies drifts and risks
📝
Agent Witness

The Witness. Documents objective reality.

  • Analyzes what actually exists
  • Compares specs vs reality
  • Produces the retro-specification

Domain Specialization

Maker/Breaker Pairs, Specialized by Domain

The Conductor detects technical domains from task annotations and invokes specialized agent pairs. Each domain has dedicated Maker and Breaker skills.

AspectMaker producesBreaker audits
DatabaseNormalization, RLS, audit logging, temporal patterns, indexingMissing normalization, RLS, indexes, constraints, cascade risks
APIREST patterns, validation, rate limiting, pagination, error formatMissing validation, auth, CORS, N+1 queries, pagination
FrontendComponent architecture, state management, accessibilityPerformance, bundle size, accessibility, XSS vectors
SecurityOIDC/JWKS, RBAC, encryption, mTLS, security headersOWASP Top 10, privilege escalation, secrets exposure
InfrastructureDocker multi-stage, Compose, Terraform, secret managementRunning as root, missing healthchecks, hardcoded secrets, SPOF

The Problem

AI-assisted development changes everything,
except our methodologies.

Silent Drift

AI produces code that seems correct but subtly deviates from your intention. Without knowing it, you accumulate invisible technical debt.

False Alignment

The agent says "done" but left TODOs, partial implementations, ignored edge cases. The code passes tests but doesn't solve the problem.

Context Loss

Each session starts from scratch. Architectural decisions get lost. Conventions erode. The project becomes an incoherent patchwork.

Biased Validation

The agent that generates the code is the same one that documents it. It's the fox guarding the henhouse. Self-evaluation masks problems.

The Fundamentals

6 Principles for Zero Drift

01

Intention is a first-class artifact

Intention is not a forgotten conversation. It's a versioned, structured document that answers "why" and "what" before any "how".

→ Before generating code, intention must be formalized and validated.

02

The contract is executable

A specification that can't be automatically verified isn't a contract, it's a wish. Every requirement has automatable validation criteria.

→ Tests, assertions, schemas: the contract verifies itself.

03

No agent validates its own work

An agent that generates code cannot be the source of truth on that code's quality. Validation must always come from an agent that didn't participate in production.

→ Mandatory architecture with 6 roles.

04

Retro-specification is the system's memory

What was actually implemented must be documented objectively, independently of what the development agent claims to have done.

→ An independent Witness agent analyzes the code and produces the truth.

05

Foundations precede features

When marginal development cost decreases, investing in architecture becomes rational. We prioritize what de-risks what comes next.

→ Sequencing favors solidity, not immediate impressions.

06

Skills are knowledge contracts

AI has outdated training data. Skills inject up-to-date knowledge and define quality criteria between phases.

→ Each transition is mediated by an explicit skill.

Landscape

Landscape Comparison

MADD vs Legacy Methodologies

AspectScrum / Kanban / SAFeMADD
BottleneckDevelopment timeIntention clarity
Work unitStory / TicketIntention + Contract
EstimationPoints / DaysObsolete (too fast)
ValidationHuman code reviewIndependent agent audit
DocumentationOften neglectedAutomatic retro-spec
RhythmFixed sprints (2-3 weeks)Adaptive cycles
CoordinationTeam ceremoniesInter-agent contracts
Project memoryIn people's headsVersioned retro-spec

MADD vs Spec-Driven Development

MADD shares the "specification-first" philosophy with other methodologies, but differs in its approach to validation and memory.

AspectBMADSpecKitMADD
PhilosophyStructured promptsLiving specificationsExecutable contracts
ValidationManual reviewSpec conformanceIndependent agent audit
MemoryPrompt historySpec versioningRetro-specification
Drift detectionManualDiff-basedAutomated by Witness
Agent separationOptionalNot enforcedMandatory (6 roles)
Self-validationAllowedAllowedForbidden
DocumentationDeveloper-writtenSpec-derivedIndependent analysis
ObjectivityDev perspectiveSpec perspectiveCode reality
MADD's key differentiator: no agent validates its own work. The Witness provides objective truth about what actually exists in the code.

Quick Start

Getting Started with MADD

1

Separate your agents

Use 2-3 different models: Gemini for specs, Claude for dev, GPT for audit. Never let an agent validate its own work.

2

Formalize before coding

Before each dev session, write an Intention Document: why, what, success criteria. This is your contract.

3

Audit each delivery

Pass the produced code to your audit agent with a due diligence skill. Never merge without independent audit.

4

Generate the retro-spec

A 4th agent (or you) analyzes what was actually implemented and updates the documentation. This is your project memory.

1

Assign roles

Intention Architect (PM/PO), Agent Conductor (senior dev), Alignment Arbiter (QA or peer). Each role is responsible for a phase.

2

Centralize skills

A shared repo with all skills: Spec Skill, Dev Skill, Audit Skill, Retro-Spec Skill. Versioned like code.

3

Retro-spec as source of truth

The retro-specification is shared and updated each cycle. It's the starting point for every new iteration.

1

Sprints → Intention Cycles

No more fixed duration. A cycle starts when an intention is formalized and ends when the retro-spec is validated.

2

Stories → Intention Docs + Contracts

Each story becomes an Intention Document with executable validation criteria. No more "looks good to me".

3

Definition of Done → Audit Skill

The DoD becomes a formal skill that the audit agent executes. Verifiable, reproducible, non-negotiable.

4

Retrospectives → Consolidations

No more "how to improve the process". We consolidate retro-specs and improve skills.

Ready for Zero Drift?

MADD is open source. Join the community and help define the future of AI-assisted development.