Skip to content

AI-Driven Development

A complete, practical book on building software when AI writes the code

Edition: 1.0 · Type: Methodology + operating manual

What this book is

This is a complete guide to AIDD (AI-Driven Development) — a way of building software in which an AI agent writes most of the code and people do the two things AI cannot reliably do alone: decide what to build, and verify that what was built is correct.

The method's center in one sentence: the agent is the hands; ADD is the memory, judgment, and conscience — the part of the team that survives when the context window doesn't. Everything an agent structurally cannot keep — what is true so far, what was promised, what worked here before, what must never be traded away — lives as artifacts on disk, not in a conversation. That is why a fresh session loses nothing, and why the method's quality holds across milestones while chat-carried work decays.

It is written to be read once front to back, then kept open beside you as a working manual. The early chapters explain why the method has the shape it does; the middle chapters explain each step in detail; the later chapters explain how to operate it across a real team and product; the appendices are copy-paste reference material.

A single worked example — transferring money between a user's own accounts — runs through the entire book so that every abstract step has a concrete form you can see.

Who it is for

Anyone who builds software with AI in the loop: engineers, architects, testers, designers, product owners, and the managers who lead them. No part assumes you have read the others; cross-references point you to what you need.

The method in one paragraph

For every feature, before AI writes any code, you write four short artifacts in order — the rules it must obey, those rules as pass/fail scenarios, the data and interface contract, and the failing tests — and then you direct the AI to make the tests pass without changing them, and finally you verify the result through evidence rather than inspection. That ordered set of artifacts is the method. The code is disposable; the artifacts are the durable asset. Direction comes before speed, and trust comes from passing tests rather than from reading code and finding it plausible.

The flow

Specify → Contract → Tests & Scenarios → Build → Verify → observe, then repeat.

Table of contents

Part I — Foundations - 00 · The shift: why AIDD exists - 01 · Core principles - 02 · The flow, and what is disposable

Part II — The method, step by step - 03 · Step 1 — Specify - 05 · Step 3 — Contract - 06 · Step 4 — Tests & Scenarios - 07 · Step 5 — Build - 08 · Step 6 — Verify - 09 · The loop — observe and learn

Part III — Operating the method - 10 · Project setup and stages - 11 · Governance - 12 · Roles and responsibilities - 13 · Adoption and onboarding - 14 · The foundation: project context across milestones

Lineage - 15 · Foundations & Lineage

Releasing - 16 · Releasing

Part IV — Reference - Appendix C · Glossary - Appendix D · The worked example, end to end - Appendix E · Checklists - Appendix G · References & lineage - Appendix H · ADD vs spec-kit — the honest comparison

Conventions used in this book

  • ▶ Example marks the running worked example.
  • Do / Don't boxes give the rule in its shortest form.
  • A gate is a checkpoint with an explicit pass/fail exit. Its outcome is always one of PASS, RISK-ACCEPTED (a signed waiver), or HARD-STOP.
  • Paths like .add/tasks/<slug>/, .add/specs/, and graph.json refer to files inside the bundle the engine writes; see 12 · The .add/ bundle.
  • Every term the method uses — beat, node, receipt, lens, wave, lane, covers — is defined once in Appendix C.