AIDD · Manifesto · v1.1.1 · 2026

The AI-Driven Development Manifesto

A standard for building software in the age of AI — written by developers, for developers.

Preamble

As AI-Driven Developers, we are discovering better ways of building software by working with AI as a deliberate partner — and helping others do the same.

AI-Driven Development

AIDD

/ˌeɪ.aɪ ˈdrɪv.ən dɪˈvɛl.əp.mənt/ noun

A way of building software in which a developer works with AI as a deliberate partner — planning, decomposing, and reviewing every change — while remaining the architect accountable for what ships.

Related practices AI-assisted development, AI pair programming, agentic coding, spec-driven development, context engineering

Same acceleration. Different quality bar.

AIDD vs vibe coding

Vibe coding optimizes for shipping speed without making code quality a requirement. AI-Driven Development keeps the same acceleration while building quality, review, and maintainability into the delivery process.

Method
AIDD learn intent spec plan implement review + test release VIBE CODING prompt prod
Over time
value time compounds spikes, then debt

AIDD Ship fast, with quality built into the process.

Vibe coding Ship fast. Do not care about code quality.

4 values of
AI-Driven Development

These non-technical values guide every AI-assisted coding session.

1
Method
over
Model
Bet on the method, not the model — every LLM release will fade.
Your method endures and standardizes your team’s practices across models, vendors, and versions.
methoddo
  plan ──→ implement
              
  assert ←── review
———————————————
any ide · any model
workflow leads.
modeldon't
$ claude
$ codex
$ cursor
$ copilot

swap tools · same speed.
2
Ownership
over
Delegation
You own what you ship — even what the AI wrote.
Every commit is signed by a human; the AI accelerates, you decide.
ownershipdo
$ git commit
  → reviewed   
  → tested     
Signed-off-by: you 
———————————————
the human owns it.
delegationdon't
$ ai "ship it"
+ 1,240 lines      merged
———————————————
 no review
  nobody read it.
who owns this?
3
Understanding
over
Acceptance
Don’t accept what you don’t understand.
The AI is your collaborator — not your replacement.
understandingdo
ai: auth via JWT.
$ why? we use
  HttpOnly sessions.
ai: rewriting. 
———————————————
you understood.
acceptancedon't
ai: auth via JWT.
$ ok            accept
———————————————
 3am
  why is this here?
nobody knows.
4
Outcome
over
Output
Writing code is easy. Creating useful outcomes is not.
Ship small, learn quickly, and measure results for users, product reliability, and the business — not lines, tokens, or commits.
outcomedo
users helped      +410
task time          -32%
incidents avoided    
———————————————
outcomes improved.
outputdon't
lines generated  12k
tokens burned   1.2M
commits/day       38
———————————————

vanity · zero impact.

12 principles for durable AI-driven development.

01

Ship in verified increments.

Working software is the output of spec, plan, tests, review, and release.

02

Start from a clear spec.

A story, PRD, or spec gives AI work a contract humans can inspect.

03

Plan before generation.

The plan is the handoff between human judgment and agent execution.

04

Decompose until delegable.

Small tasks survive async work, model changes, and team handoffs.

05

Craft context with the care we give code.

Specs, markdown, rules, skills, and memory deserve the same quality bar as software.

06

Capture learning for reuse.

Each lesson becomes memory, a rule, a decision, or a skill others can use.

07

Own every shipped change.

AI may produce it; humans approve, merge, and maintain it.

08

Do not delegate what you cannot evaluate.

Use AI where you can judge tradeoffs, read the output, and prove behavior.

09

Improve the system before forcing the model.

When output degrades, clarify boundaries, names, tests, and context before asking harder.

10

Rebuild context when coherence drops.

Reset from memory, docs, rules, and the current plan instead of improvising.

11

Treat AI failure as a signal.

When the model stalls, inspect scope, context, assumptions, and tests before pushing harder.

12

Make the practice transferable.

A shared method lets different people produce the same quality of code across tools.

Public signature registry

Sign the manifesto publicly.

Signing starts a GitHub contribution. Your name appears in the public registry after the pull request is reviewed and merged.

54 signatories

Public signature

Continue on GitHub

Submit the contribution form to request your public signature. Your name appears in the registry only after the pull request is reviewed and merged.

  1. 1Submit the GitHub form
  2. 2Review the generated pull request
  3. 3Join the registry after merge

Tweaks

Accent