Agentic SDLC — The Whole Lifecycle Map
Agentic SDLC — The Whole Lifecycle Map
AGENTIC SDLC The whole lifecycle, on one map Software made by a team of AI agents still goes round the same loop human teams do — it just goes round much faster, so every step needs a process that doesn't depend on you remembering it. Click a district to zoom in. Esc zooms out. Arrow keys walk the tour. GO DEEPER — SIBLING MAPS & DECKS Plan map ↗ Agents map ↗ Ship map ↗ Evolve map ↗ Git situations deck ↗ DevOps: ship deck ↗ Complexity ladder deck ↗ Day companion ↗ PLAN drafting room BUILD workshop floor REVIEW inspection gate SHIP shipping dock EVOLVE library & garden YOU the CTO vision · judgment · when to stop Each lap makes the system better — and the lap gets faster.
then build it then check it then ship it then learn from it …and the next lap starts smarter you steer
Drafting Room 1 · PLAN 1 · PLAN Drafting Room What are we building, for whom, and in what order? Agents build exactly what you describe — including the vague parts. So planning isn't a warm-up, it's the factory: a brain dump becomes requirements, requirements become a phased roadmap, and the roadmap becomes specs agents can be held to. → Brain dump → roadmap the pipeline of prompts → Artifacts roadmap ⊃ feature ⊃ story ⊃ spec ⊃ acceptance → Fast Waterfall spec it all, build in phases The pipeline produces the artifacts; Fast Waterfall is why you do it all up front. Plan map ↗ PROCESS Brain dump → Roadmap Six prompts turn what's in your head into specs an agent can build from. Brain dump you talk, it listens Requirements what must be true Business value what matters most Phased roadmap what order Parallelization what can run at once OpenSpec proposals one spec per feature Every arrow is a prompt to Claude. You answer questions; Claude writes the artifact. The artifacts — not the code — are the factory. SO WHAT: plan the whole thing fast, then build in phases, not tickets. Brain dump → Roadmap USE IT WHEN Before any code. Also whenever the project drifts — re-run the pipeline on what you've learned. IN AN AGENT 'Interview me about this app one question at a time, then write requirements.' Claude asks; you answer; it writes the artifact. GOTCHA Skipping the parallelization step means agents later collide on the same files. ASK THE ROOM What would your brain dump miss that a user would notice on day one? VOCABULARY The planning artifacts Roadmap, feature, user story, requirement, acceptance criteria — five words, nested. Roadmap phases, in order Feature a thing users can do User story As a __, I want __ so that __ Requirement / spec what must be true Acceptance criteria how we'll know it's done ONE OF EACH, NESTED Roadmap: Phase 1 = people can sign up. Feature: password reset. Story: as a user who forgot my password, I want a reset link by email so that I can get back in. Requirement: the link expires and works once. Acceptance: clicking a used link shows 'expired' and does NOT log you in. worked example zoom in ⌕ Plan › Artifacts › one of each BENCH · WHICH ONE IS IT? Click a sentence. Decide which box it belongs in first. 'Payments' 'As a teacher I want…' 'Refunds over $50 need a human' 'A $51 refund shows Pending' 'Phase 2: teams' 'It should be fast' Pick one ↑ — answer for your own agent first, then click to compare. The planning artifacts USE IT WHEN When someone says 'the spec' and you're not sure which box they mean. IN AN AGENT An agent's test asserts an acceptance criterion. If you didn't write one, the agent invents one. GOTCHA 'It should be fast' is a wish, not a requirement. Put a number on it. ASK THE ROOM Write one acceptance criterion for your project. Could a test check it? PHILOSOPHY Fast Waterfall Plan everything quickly, build in big phases, ship working systems — because building got cheap. WATER-FRAGILE (what most companies do) sprint 1 plan · build · demo sprint 2 plan · build · demo sprint 3 plan · build · demo sprint 4 plan · build · demo sprint 5 plan · build · demo sprint 6 plan · build · demo One feature per sprint made sense when one feature took a long time to build. With agents the building got cheap — the re-planning overhead didn't. FAST WATERFALL (what we do) Spec it all requirements, roadmap, specs — quickly Build in phases agents in parallel, big increments Working system not a minimal feature learn → re-spec → next lap Build the factory, not the thing. Your specs and prompts are the factory; code is what comes out. SO WHAT: the spec is the steering wheel. Agile ceremonies were for slow hands. Fast Waterfall USE IT WHEN Deciding how big a chunk of work to hand an agent. IN AN AGENT Instead of one ticket per sprint, a phase of 5 independent features goes to 5 agents at once. GOTCHA Fast doesn't mean skipping the spec. Fast means the spec is the work. ASK THE ROOM Which of your team's rituals exist only because building used to be slow? Workshop Floor 2 · BUILD 2 · BUILD Workshop Floor Who does the work — and how do they not trip over each other? One agent is a pair programmer. Many agents are a team — and teams need benches, briefs and rules. Subagents and forks split the thinking; worktrees split the files; the worker loop makes each agent finish what it starts. → Agent · subagent · fork who knows what → Worktrees one bench per agent → The worker loop test first, commit if green Forks decide who thinks; worktrees decide where they work; the loop decides when they're done. Agents map ↗ CONCEPT Agent · Subagent · Fork The difference is what's in its context: everything, only your brief, or a copy of everything. YOUR SESSION the whole conversation SUBAGENT fresh, empty context knows only your brief brief summary FORK copy of everything so far clone report Both run in the background while you keep talking. You only ever see what they send back — so ask for the conclusion, not the file dumps. SO WHAT: subagent = new hire with a brief. Fork = a clone of you. BENCH · SUBAGENT OR FORK? Pick a job. Which would you send? Search 40 files for X Build a map of what we just discussed Independent code review A two-line typo fix Pick one ↑ — answer for your own agent first, then click to compare. Agent · Subagent · Fork USE IT WHEN Any job big enough that you'd rather read the conclusion than watch the work. IN AN AGENT This map: a fork of the planning session built it while the main session kept teaching. GOTCHA A subagent with a vague brief does vague work — and reports it confidently. ASK THE ROOM What's one task you did this week that a fork could have done in the background? GIT Worktrees One repository, many working folders — so parallel agents never edit the same files. .git (one repo) history + objects, shared by all ../app-login branch feat/login agent A ../app-search branch feat/search agent B ../app-billing branch fix/billing agent C git worktree add ../app-search -b feat/search One repo, many working folders, each on its own branch. Agents can't overwrite each other's half-finished files — their work meets again only through a pull request. SO WHAT: one agent, one bench, one branch. Worktrees USE IT WHEN Whenever two agents work on the same repo at the same time. IN AN AGENT Three agents, three worktrees, three branches, three pull requests — merged in order by a release manager. GOTCHA Each worktree needs its own installs, and they still share your database and ports. ASK THE ROOM Which two parts of your project could two agents build without touching the same file? PATTERN The autonomous worker A loop that picks a task, writes the test first, and only commits when it's green. Pick task Write failing test Implement Run tests Commit Mark done fail → fix & retry THE LOOP THE OUTDOOR PET — run it outside the house ▸ its own machine (or container) — not your laptop ▸ its own GitHub account for its commits ▸ its own budget card with a hard limit ▸ secrets from a vault, not your .env ▸ hooks that block bad commits The cautionary tales from class — a deleted database, a kernel panic — both came from an agent with too much access on a machine that mattered. A WORKER'S SYSTEM PROMPT, IN FOUR PARTS 1 Identity & role: 'You are Roy, backend developer for this repo.' 2 Core workflow: 'Pick the top unclaimed task in tasks/, write a failing test, make it pass, commit, mark done.' 3 Capabilities & constraints: 'You may edit src/api only.' 4 Rules & guardrails: 'Never disable a test to make it pass. Never commit with failing tests.' worked example zoom in ⌕ Build › Worker › system prompt SO WHAT: tests first, so 'done' means something the agent can't fake. The autonomous worker USE IT WHEN When you want work to continue while you're away from the keyboard. IN AN AGENT Headless Claude on a schedule: read next task → implement → test → commit if passing → mark complete → repeat. GOTCHA Give it the keys to your real machine and it will eventually use them. Keep the pet outdoors. ASK THE ROOM What's the worst thing your agent could do with the access it has right now? Outdoor pet deck ↗ Inspection Gate 3 · REVIEW 3 · REVIEW Inspection Gate How do you trust code nobody typed? Agents write fast and confidently — including the bugs. Review stops being one person reading diffs and becomes a stack of filters: machines catch what's certain, a review agent catches the patterns, and you catch what only a human knows. → The process stack hooks → scans → agent → you → The silent fallback an anti-pattern, defeated → Escape-Escape don't argue, rewind The stack is the gate; anti-patterns are what it's tuned to catch; Escape-Escape is how you fix a bad run. Git situations deck ↗ PROCESS The process stack Four filters, cheapest and most certain first — so a human only sees what machines can't settle. 1 · Pre-commit hooks BLOCKS tests, types, lint, pattern detectors — any fail = commit rejected 2 · Post-commit analysis FLAGS E2E, security scans, perf, behaviour drift — fail = flagged 3 · Senior review agent QUESTIONS checks the senior-dev checklist and known anti-patterns 4 · Human review DECIDES product sense, architecture, 'is this what we wanted?' Cheap, certain checks first; expensive judgment last. A human should only see what three machines couldn't settle. SO WHAT: you are the last filter, not the only one. BENCH · WHICH LAYER CATCHES IT? Click a problem. Guess the layer first. A type error Login breaks in the browser A silent fallback The feature nobody asked for Pick one ↑ — answer for your own agent first, then click to compare. The process stack USE IT WHEN Setting up any repo agents will commit to. IN AN AGENT A pre-commit hook that runs the tests means no agent, ever, can commit red. GOTCHA A hook with a 'skip just this once' flag is not a hook. ASK THE ROOM Which layer does your project have today? Which one is missing? ANTI-PATTERN The silent fallback An error swallowed and replaced with a default — the program lying to you politely. WHAT THE AGENT WROTE def get_price(item): try: return api.fetch_price(item) except Exception: return 0 # ← looks safe WHAT ACTUALLY HAPPENS The pricing API goes down. Nothing crashes. Every item now costs $0. Tests pass, dashboards are green, and you find out from the bank. THE IMPROVEMENT LOOP Find name the pattern Defeat a test that fails on it Teach add it to the checklist + memory # test_no_silent_fallbacks.py assert no 'except' block returns a default without logging + re-raising → now the hook catches it forever, for every agent SO WHAT: an error you can see is a gift. Agents love to hide them. The silent fallback USE IT WHEN Reading any agent code with try/except, '|| default' or 'if not x: return []'. IN AN AGENT Find → Defeat (a test) → Teach (checklist + memory) — then it never comes back. GOTCHA It passes every test you wrote before you knew about it. ASK THE ROOM Where in your code would a $0 or an empty list hide a failure? HABIT Escape-Escape When a run goes wrong, rewind and fix the prompt — don't argue in the next message. ARGUING (don't) you: No, I said use Postgres. agent: You're right! Switching to SQLite… you: POSTGRES. agent: Apologies — here's the SQLite version… Every correction stays in context. You're now arguing with a transcript that contains the wrong answer four times. ESCAPE-ESCAPE (do) Esc Esc rewind Rephrase fix the prompt Wrong approach Esc-Esc, rephrase Asks what you answered Esc-Esc, clarify Stuck in a loop Esc-Esc Garbage output Esc-Esc Tiny typo just fix it inline “A new error is progress. Every time there's a new error, you have made progress.” Arguing isn't progress. It's noise. SO WHAT: fix the prompt, not the agent's opinion. Escape-Escape USE IT WHEN The moment you start typing 'No, I said…'. IN AN AGENT Agent picks the wrong library: Esc Esc, add 'use Postgres, not SQLite' to the original prompt, rerun. GOTCHA Arguing leaves the wrong answer in context, so it keeps coming back. ASK THE ROOM When did you last argue with an agent? What would the rewritten prompt have said? Shipping Dock 4 · SHIP 4 · SHIP Shipping Dock How does a change get from an agent's branch to real users without breaking them? With one developer, shipping is a push. With ten agents, it's logistics: every change rides a branch and a pull request through automated checks, lands in order, and is tried somewhere cheap before it reaches real users. → Branch → PR → merge the one road into main → Environments preview, staging, production → Release manager what order things land in PRs are the road; environments are the test track; the release manager is the traffic controller. Ship map ↗ GIT Branch → PR → Merge Every change rides a branch, becomes a pull request, passes checks, then merges. main / production feat/search your agent's branch commits Pull request 'please pull my branch in' CI checks ✓ tests ✓ lint ✓ build … review Merge A pull request is a request for the main branch to pull in yours. It's where the checks run and where review happens — the inspection gate lives here. SO WHAT: nothing reaches main except through a PR with green checks. Branch → PR → Merge USE IT WHEN Every change, from every agent — no direct pushes to main. IN AN AGENT 'Open a PR for this branch and tell me when CI is green.' Then read the PR, not the agent's summary of it. GOTCHA If agents can push to main directly, none of your review stack exists. ASK THE ROOM Who — or what — is allowed to press Merge in your project? Git situations deck ↗ INFRA Environments Copies of the app, each more real and more expensive to break than the last. Your machine breaks? only you notice Preview one per PR, throwaway Staging the dress rehearsal Production real users ← cheaper to break more real → TWO WAYS TO SWAP SAFELY blue (live) green (new) router Blue-green: flip all traffic at once; flip back if it breaks. old · 90% new · 10% Canary: a few users first; widen if it holds. SO WHAT: break things where it's cheap. BENCH · WHERE DO YOU TEST THIS? Click a change. Pick the cheapest place that would actually catch the problem. A button colour A database migration New checkout flow A refactor with good tests Pick one ↑ — answer for your own agent first, then click to compare. Environments USE IT WHEN Deciding where a change must be seen before real users see it. IN AN AGENT Every PR gets a preview URL; merging deploys staging; production is a separate, deliberate step. GOTCHA Staging that shares production's database isn't a rehearsal — it's production. ASK THE ROOM What's the most expensive place your project has ever found a bug? DevOps: ship deck ↗ ROLE The release manager When many branches are waiting, someone decides the order — and when to say no. PARALLELIZE WHEN… Feature A Feature B Feature C Ship different files · different systems · clear interfaces · no data dependencies SERIALIZE WHEN… A B C Ship same files · shared database schema · changing API contracts · state dependencies THE RELEASE MANAGER'S MERGE ORDER 1 Infrastructure affects everything 2 Backend APIs the frontend needs 3 Frontend depends on backend 4 Then smaller changes first It blocks a merge when main is red, a pending change has failing tests, two changes conflict, or a change reaches outside its author's scope. SO WHAT: independent work fans out; dependent work queues up. The release manager USE IT WHEN More than two agents producing PRs on the same repo. IN AN AGENT Infra PR merges first, the API PR rebases on it, the UI PR goes last. GOTCHA Parallel agents on the same files don't save time; they manufacture merge conflicts. ASK THE ROOM Which features in your roadmap must be serialized? Why? Library & Garden 5 · EVOLVE 5 · EVOLVE Library & Garden How does the team get better instead of repeating the same mistakes? A fresh agent knows nothing about your project's scars. Evolution is how the lessons stick: memory that keeps what matters and composts the rest, a stack that turns rules into habits, and loops inside loops that each improve something. → Five-layer memory what to keep, what to forget → Discipline stack hook → checklist → memory → habit → Iteration cycles micro, daily, weekly, monthly Cycles decide when you improve; memory stores what you learned; the discipline stack makes it stick. Evolve map ↗ ARCHITECTURE Five-layer memory Layers that forget at different rates — and a nightly pass that turns notes into wisdom. CORE identity, role, voice, relationships never cleared LONG-TERM major insights, milestones never cleared MEDIUM-TERM patterns noticed this week cleared weekly RECENT tasks, learnings, conversations cleared nightly COMPOST failed & rejected ideas cleared monthly ↑ REM sleep: the nightly / weekly pass consolidates notes upward into long-term memory. SO WHAT: a mistake remembered is a mistake not repeated. BENCH · WHERE DOES IT GO? Click a thing your agent learned. 'I'm Roy, backend' Third time citing a fake paper Today's ticket notes We tried event sourcing; too complex Pick one ↑ — answer for your own agent first, then click to compare. Five-layer memory USE IT WHEN Any agent that will run more than once on the same project. IN AN AGENT Ten 'forgot to validate input' notes consolidate into one long-term rule. GOTCHA Memory that only grows becomes noise. Consolidation is the point. ASK THE ROOM What's one mistake you'd want your agent to never make twice? Agent memory deck ↗ PROGRESSION The discipline stack Enforce it, check it, remember it, then it's habit. 1 · Hook external enforcement — the commit is rejected 2 · Checklist the reviewer checks it 3 · Memory the agent remembers failing at it 4 · Habit it just doesn't write it any more the goal is the top step Every discipline starts at the bottom: a hook that refuses the commit. Over time it moves up — reviewers check it, the agent remembers it, then it's simply how the agent writes code. SO WHAT: enforce it with a machine first; habits come later. The discipline stack USE IT WHEN Any rule you've had to say to an agent more than twice. IN AN AGENT Silent fallbacks: a hook rejects them → the reviewer flags them → the agent's memory notes it → it writes explicit errors by default. GOTCHA Skipping straight to 'just tell it in the prompt' is level 4 without levels 1–3. It won't hold. ASK THE ROOM Which rule in your project lives only in your head right now? RHYTHM Iteration cycles Loops inside loops — each one improves something different. MONTHLY WEEKLY DAILY MICRO MICRO task → test → commit DAILY overnight work · morning review · tech-debt pass WEEKLY pattern review · REM sleep · checklist update · defeat tests MONTHLY behaviour audit · agent versioning · compost cleanup · cost review SO WHAT: small loops ship code; big loops improve the team. Iteration cycles USE IT WHEN Setting up the rhythm for a project that will run for a while. IN AN AGENT Weekly: 'What recurred this week? Write a defeat test for it and add it to the checklist.' GOTCHA If you only run the micro loop, you ship faster and get no better. ASK THE ROOM Which of these loops does your project actually run? CTO's Office 0 · YOU 0 · YOU CTO's Office If agents write the code, what's still your job? Vision, judgment and knowing when to stop. You decide what gets built and what 'good' means; agents do the rest. That's a promotion — and like any promotion it comes with a ladder to climb, new vocabulary, and a real risk of overwork. → Maturity ladder where you are, what's next → It's all prompts commands, skills, subagents, tools → Your limits the rate limit is on your side Climb the ladder one step at a time, with words you understand, at a pace you can keep. CTO mindset deck ↗ MODEL The maturity ladder Seven levels from 'I write the code' to 'the team improves itself'. 0 Manual 1 Assisted 2 Automated 3 Orchestrated 4 Autonomous 5 Evolving 6 Self-improving You can't skip a step. Each one is the foundation for the next. SO WHAT: know which step you're on; build the next one. BENCH · WHERE ARE YOU? Click the sentence that's most true. I paste code from chat It edits; I read every diff I run a few agents at once It works overnight Pick one ↑ — answer for your own agent first, then click to compare. The maturity ladder USE IT WHEN Deciding what to set up next — and noticing when you're trying to skip a step. IN AN AGENT Level 2 → 3 needs tests and hooks first, or parallel agents just make parallel mistakes. GOTCHA Level 4 without level 2's tests is an agent shipping untested code overnight. ASK THE ROOM Which level are you on — honestly? What's the one thing that gets you to the next? Complexity ladder deck ↗ VOCABULARY It's all prompts Commands, skills, subagents, tools, plugins — the same thing in different packaging. a shortcut to a prompt a prompt + code that runs Command /review a saved prompt you call with a slash Skill a playbook a detailed, multi-step procedure the agent follows Subagent a brief a prompt that runs in its own context Tool / MCP Read, Bash, GitHub a prompt plus code the agent can execute “They're all just different ways of handling prompts.” Plugins bundle several of these to install together; hooks run your code on agent events. SO WHAT: don't get stuck on the names — ask what context it runs in. It's all prompts USE IT WHEN Whenever the vocabulary is getting in the way of building. IN AN AGENT A /review command, a code-review skill and a reviewer subagent can contain the same words — they differ in where they run. GOTCHA Installing many plugins doesn't make a process. Knowing what each prompt does does. ASK THE ROOM What's a prompt you type often enough that it should be a command? HEALTH Your limits When agents unblock everything, the bottleneck becomes you. Guard it mechanically. THE DIARRHEA PHASE (the course's own term) Agents suddenly unblock years of backlogged ideas. All of them feel buildable right now. Multiple developers in this field have hit manic episodes from exactly that. WARNING SIGNS ▸ skipping meals ▸ coding at 3am ▸ 'one more feature' loops ▸ nobody's heard from you GUARDRAILS THAT WORK one subscription — let the limit stop you merchant-locked card with a cap timers you actually obey tell someone who loves you, now The goal isn't to work 10× longer because you can. It's to work 10× faster in focused bursts — then stop and do something else with your life. SO WHAT: the rate limit is the one part of the stack on your side. Your limits USE IT WHEN Before you start. Seriously. IN AN AGENT One subscription. When it runs out for the day, you're done for the day — that's the feature. GOTCHA Being new at this is no protection. ASK THE ROOM Who will you tell, and what's your stop signal?
←
0 / 0
→
Explore
Click anything to zoom into it · scroll to zoom · drag to panEsc zoom out one level · Home whole atlas1 –4 jump to a quadrant · / search
Tour
→ / space next stop · ← previousTeach
N presenter notes for whatever you're looking at · F fullscreenReading the map
The whole atlas is one safety case. The top goal is “this agent is fit to deploy”;
each quadrant is one leg of the argument; each district is a family of tools for that leg.
Small text appears as you zoom in. Some tiles have controls you can click.
Click anything to zoom in · scroll to zoom · Esc to back out · → for the guided tour