The four methods
The frameworks, and how they merge into P0 to P3
AI-DLC, AIDD, BMAD and spec-driven development on one lifecycle: how they merge into the SkyWays PDLC, every acronym decoded, and where each came from.
Who this page is for, and how to use it
Anyone who keeps meeting AI-DLC, AIDD, BMAD, SDD and forty acronyms and wants them placed on one map, and anyone who wants to know how much to trust a number in this manual.
Settle three questions fast: which method covers what, what an acronym means here, and where a framework came from. Then carry four pictures in your head.
- Start with the picture: four methods on one lifecycle. They are not competitors, they cover different phases.
- Use the pictures as arguments: each one ends in a rule you can apply tomorrow.
- Check the lineage column before you quote a figure: documented, established, or this manual's own default.
Four methods on the four phases
- P0 · Framea spec sketch, lightly: the pain and the ceiling
- P1 · Design & Specthe spec is the artefact: eight fields, stable IDs
- P2 · Build & Provecode generated from the spec, regenerated on change
- P3 · Run & Learnlightly: the incident edits the spec first
- P0 · Framethe Analyst's brief, or none at all
- P1 · Design & SpecPM, UX and Architect: PRD, DESIGN.md, the spine
- P2 · Build & Provea spec and its stories, then Build per story
- P3 · Run & Learnextended here: learn and adjust, into the next brief
- P0 · Frameinception: an intent becomes units of work
- P1 · Design & Specmob elaboration, NFRs captured
- P2 · Build & Proveconstruction in bolts, mob construction
- P3 · Run & Learnoperations, run adaptively
- P2 · Build & Provecontext files, story files, a harness in CI, review by risk
- Silent in P0, P1 and P3
- P0 · Framethe AI-fit verdict, the autonomy ceiling, the value line
- P1 · Design & Specwhat the sign-off needs: spec, bar, guardrails, and the authority budget
- P2 · Build & Proveone unknown per bolt, a lower bound not a score, the shadow run
- P3 · Run & Learntwo numbers, drift, the incident as the next P0
A filled cell is where the method says something about that phase; a dashed cell is where a team has to bring its own answer. The last row is where this manual's own devices sit.
Four methods, one lifecycle: where each one sits
They are not competitors. Each speaks to part of the lifecycle, and the decision that matters is not which method to adopt but how deep to go on this change. A filled cell is where a method says something about that phase; a dashed cell is where you bring your own answer.
| Method | What it is | Where it sits | When to use it |
|---|---|---|---|
| SDD Spec-driven development | The spec, not the code, is what you maintain. Code is generated from it and regenerated on change. | P1 and P2 mainly; lightly in P0 and P3 | Always. It is the backbone. |
| BMAD Breakthrough Method of Agile AI-Driven Development | Skills in your coding tool: five named agents, one Build loop, and documents (a brief, a PRD, a spine, a spec, stories) added around it as the work grows. | P0 to P2, sized to the change; extended here into P3, as learn and adjust | Complex, multi-team, audited work. Its project path is six documents before any code; its own docs send a small change straight to Build. |
| AI-DLC AI-Driven Development Life Cycle (AWS) | Adaptive: run only the lifecycle stages a given change actually needs. | A principle across all four phases | When the depth of a change is unknown up front. The architect judges depth per change. |
| AIDD AI-driven development | The day-to-day craft: context files, story files, editor agents, review by risk, cost habits. | P2 mostly | Every day, by everyone who writes code. |
How the four methods merge into the SkyWays PDLC
Each method gives the part it does best. The SkyWays PDLC puts those parts in one order, with one owner for each phase. It also adds four things no method carries: the hard gate (the sign-off before anything is built), a pass mark for each kind of case, a limit on what the agent may do alone, and the report that starts the next round.
- One hard gate: the signed spec, before anything is built
- A bar per slice, derived from money at risk
- An authority budget for every step the agent takes
- The two-number report that starts the next P0
Four methods merge into one loop
The SkyWays PDLC adds: the autonomy ceiling, decided before anything is built
The SkyWays PDLC adds: a bar per slice and an authority budget, signed before the build
sign-off (the hard gate)
The SkyWays PDLC adds: prove the bar first: a lower bound, never a score, before traffic
The SkyWays PDLC adds: the two-number report that starts the next P0
One order, one owner per phase, one sign-off. The parts keep their names; the four phases keep them in order.
Traditional versus agentic: what changes when the product decides
A traditional lifecycle decides everything once, up front. When part of the product is right a share of the time rather than always, three things move: a bar per slice, an authority budget, and one hard gate before anything is built. Production then feeds the next frame instead of ending the story.
Traditional PDLC vs Agentic PDLC
- 1Discoveryinterviews, adjectives
- 2PRDthirty pages, approved
- 3Designarchitecture, once
- 4Buildtwo-week sprints
- 5Testacceptance, at the end
- 6Releasethen a metric
Every decision is made once, by a person, before the build starts. Quality is a demo and a checklist, and both come at the end.
Breaks when the product contains something that decides: nobody wrote how right it must be, or what it may do alone.
- P0 · Framethe pain in cases, minutes and money · pain register, AI-fit verdict
- P1 · Design & Speceight fields, a bar per slice · eight-field spec, authority budget
- sign-off (the hard gate)
- P2 · Build & Provebolts, a harness in CI, the shadow run · golden set, shadow run
- P3 · Run & Learntwo numbers, drift, the incident · two-number report, drift readout
- the incident is the next briefback to P0 · Frame
The sign-off halts P1 until three things are signed: the spec, the bar and the guardrails.
The other three crossings are soft: they can cross with a placeholder, a named owner and a date.
Gate by risk, never by size
Size measures typing. Four hundred lines of help text cannot move money; three lines in a refund cap can. The band a change sits in comes from what it touches, and the band decides who reviews it and whether a person signs before it ships.
Gate by risk never by size
- What it touchesA draft in a sandboxnothing real changes
- The checkReview at the endthe reader owns the outcome
- At the airlineDraft the passenger message
- What it touchesReal work, undoablea change with an undo
- The checkOne reader before mergea second pair of eyes
- At the airlineSearch flights, rank options
- What it touchesSmall blast radiusone customer, one booking
- The checkApprove firsta person before the action
- At the airlineRebook onto a new flight
- What it touchesConsequentialthe ledger or the law
- The checkA named approver, every timeand a cap in the tool signature
- At the airlineRefund, capped at $400
- What it touchesCannot be undoneor somebody gets hurt
- The checkNot delegated at alla person does it
- At the airlineChange a passenger's identity
A change inherits the band of whatever it touches: three lines in a refund cap are R4; four hundred lines of help text are R1.
Size measures typing. Risk measures what a mistake costs and whether it can be undone.
Why long chains of steps fail, and what to do about it
Every step that is only probably right multiplies. Four chained steps at 90 percent succeed 66 percent of the time, and they fail fluently, with no error to catch. Two defences, in order: keep chains short, then put an independent checker after the steps that are costly and easy to miss.
6 steps at 90% each = 53% end to end
- 1Step 1: right 90% of the time90% right end to end
- 2Step 2: right 90% of the time81% right end to end
- 3Step 3: right 90% of the time73% right end to end
- 4Step 4: right 90% of the time66% right end to end
- 5Step 5: right 90% of the time59% right end to end
- 6Step 6: right 90% of the time53% right end to end
Multiply, never average. Four steps each right 90% of the time are right 66% of the time end to end, and they fail fluently: no error, a confident wrong answer.
- Keep chains short: fewer probabilistic steps per case
- Put an independent checker after the steps that are costly and easy to miss
- Make exact steps exact code: a calculator behind an agent is a provable step made probabilistic
The acronym decoder
Every short form this manual uses, what it means here, and where it came from.
| Short | Long | What it means here | From |
|---|---|---|---|
| ADR | Architecture decision record | One decision with its context, consequences and what it rejected, versioned next to the code. Written only at a trade-off point. | Nygard, 2011 |
| AI-DLC | AI-Driven Development Life Cycle | Run only the lifecycle stages a change needs. | AWS |
| AIDD | AI-driven development | The craft of building software with coding agents. | No single owner |
| ATAM | Architecture Tradeoff Analysis Method | Where utility trees and sensitivity points come from. | Kazman, Klein, Clements, SEI, 2000 |
| BMAD | Breakthrough Method of Agile AI-Driven Development | Skills and five named agents, one Build loop, a document per decision. | BMad Code |
| EARS | Easy Approach to Requirements Syntax | WHEN a trigger AND a condition THE SYSTEM SHALL a behaviour, within a measure. | Mavin et al., Rolls-Royce, 2009 |
| MCP | Model Context Protocol | One plug so any AI client can use your tools and data. Turns M apps x N systems into M + N. | Specification |
| NFR | Non-functional requirement | Written as a six-part scenario so it can be tested, ranked and traded off. | Bass, Clements, Kazman |
| PDLC | Product development lifecycle | Here: P0 Frame, P1 Design & Spec, P2 Build & Prove, P3 Run & Learn. | Stage-gate, Cooper 1990 |
| R1 to R5 | The risk ladder | Reversible draft, reversible change, hard to reverse, money/identity/policy, irreversible. | this manual |
| RACI | Responsible, accountable, consulted, informed | One accountable name per artefact, never a committee. | No single source |
| SDD | Spec-driven development | Maintain the spec; regenerate the code. | No single owner |
| TCO | Total cost of ownership | Three years, with the people counted, usually the larger number. | Gartner, 1987 |
| p^n | Chained probability | Steps multiply. Four steps at 90% is 66%. Length is the enemy. | Basic probability |
Where each framework came from, and how much to trust it
Every framework in this manual carries a lineage pill. Check it before you quote a figure: a vendor's documentation is dated, a published practice is named, and this manual's own defaults are there to tune on your own traffic, not to cite.
- documented a vendor’s published documentation, dated
- established a named, published practice
- working method this manual’s own default, to tune on your own traffic
| Framework | What it is | Lineage | Confidence |
|---|---|---|---|
| The four phases, P0 to P3 | Four phases every method walks: frame, specify, build and prove, run and learn. | Stage-gate systems (Cooper, 1990). The phase names are this manual's. | working method |
| The requirements chain | Discover, credit, consolidate, constrain, candidates, trees, workshop, ratify, name the sensitivity points. | ATAM utility trees (SEI, 2000); six-part scenarios. The chain is this manual's. | working method |
| The ADR at the trade-off point | A record is written only where two quality attributes pull against each other. | ADRs (Nygard, 2011); ATAM sensitivity points. | established |
| The exact and best-guess map | Which steps are computed in code and which are drafted by a model, with the proof each owes. | This manual's construction. | working method |
| Autonomy by the cost of a mistake | The level follows what a wrong action costs and whether it can be undone. | One-way and two-way doors (Bezos, 2015). | working method |
| The acceptance bar | bar = damage / (damage + saving), per slice. A hold lowers the damage and so the bar. | This manual's construction. | working method |
| Hard and soft gates | A decision halts the phase or runs alongside it, settled by four questions. | Stage gates (Cooper, 1990). The four questions are this manual's. | working method |
| The risk ladder R1 to R5 | The check grows with the band. A change inherits the band of whatever it touches. | Least privilege (Saltzer and Schroeder, 1975). | working method |
| Bolts and the walking skeleton | One risk per bolt, the skeleton first, the shadow run as the milestone. | Walking skeleton (Cockburn, 2004); the bolt from AWS AI-DLC. | working method |
| Prove the bar, then earn the traffic | A score is reported with its lower bound; a cut-over widens on live evidence. | Wilson (1927); stratified sampling (Neyman, 1934); canary release. | established |
| Review by risk band | Two readers, one, or the harness alone, set by what a change touches. | Little's law (Little, 1961). The banding is this manual's. | working method |
| The cache break-even | Caching pays once reuse outweighs the write premium. Break-even is the second use. | Prompt-caching pricing as documented by Anthropic and Amazon Bedrock, read September 2026. | documented |
| Decompose the bill | Four signatures in the per-call log, four factors that multiply, fix order (factor − 1) ÷ days. | FinOps unit economics. The decomposition is this manual's. | working method |
| The missing-control postmortem | Every layer is enforced, a request, or absent. The enquiry ends at the control that would have made it impossible. | Layered defences (Reason, 1990); blameless postmortems (Beyer et al., 2016). | established |
| The two-number report | Person-days saved and tokens spent, always together, with the rows that keep both honest. | Paired indicators (Grove, 1983); Goodhart's law (1975). | working method |
| The model gateway | A facade, a retry, a fallback and routing in front of every model call, with a per-call log. | Facade and circuit-breaker patterns; LiteLLM as the named example. | documented |
Seen where the methods sit. The method page draws the lifecycle they sit on.