SDLC Workflow

For the past five or six months, every code change I ship has gone through one of two pipelines, and a routing heuristic picks which. Small, single-file changes take an eight-step fast path. Anything complex or high-stakes takes the full eleven-step version. Both are overkill for a one-person homelab on paper, and I keep reaching for one most days I write code. This is why.

flowchart TD
    C[Code change] --> R{Routing heuristic}
    R -->|small, single-file, single-repo| F[Fast path — 8 steps]
    R -->|complex / high-stakes| U[Full pipeline — 11 steps]
    F -.->|upshift on prompt / paid-API / security keyword| U
    U -.->|downshift when architect says trivial| F

The allow-list is strict: one repo, one file or one cohesive subsystem, and no prompt, paid-API, Home Assistant blueprint, or security keyword anywhere in scope. Anything ambiguous falls through to the full path, so eleven steps is the de facto default. Last month I ran 53 full sessions against 12 fast ones, and the median full run spawns 29 agents to the fast run’s 10.

Both pipelines are multi-agent orchestrations inside Claude Code. The orchestrator — the agent I’m actually talking to — never writes the code. It spawns specialist subagents, each scoped to one job, each handing the next a structured document to read. By the time a change commits, a dozen of them have touched it — a small software organization running in my terminal.

What the pipeline actually does

A full run, at its largest:

• 1. Architecture review — an Opus-tier architect judges whether the change fits the system and returns APPROVE / APPROVE WITH CONDITIONS / REQUEST CHANGES / REJECT.
• 1b. Design validation — a validate agent stress-tests the approved design before any code exists.
• 2. RED tests first — a test engineer writes failing tests for the not-yet-implemented behavior.
• 3. GREEN implementation — a Python, Home Assistant, web, Godot, or sysadmin engineer makes them pass.
• 4. Parallel verification — up to nine reviewers run at once against a shared context blob, gated by what the change touches. A Python-only change wakes four; the other language reviewers stay asleep.
• 5. Fix findings — every finding goes back to the engineer. No severity tiers, no “later.” If a reviewer wrote it down, it gets fixed.
• 6. Mutation testing — the test engineer mutates the source one statement at a time; surviving mutations expose test-suite gaps and loop back to GREEN.
• 6b. Documentation — once mutations converge, a docs engineer writes against the shipped code and a docs reviewer checks parity.
• 7. DevOps review — runs the plan’s validation against live hardware, HA, or external APIs, then proposes the commit structure.
• 8. Readiness gate — every agent confirms what it verified. I read the summary and approve before anything commits.
• 9. Commit and deploy — DevOps makes atomic commits on a worktree branch, then fast-forwards the canonical tree.
• 10. Retrospective — a retro agent interviews me, compares against prior retros, and proposes changes to the agent definitions themselves.
• 11. Plan closure — the plan note is ticked off, the driving Todoist task gets a closing comment, the worktree is torn down.

Every run works inside its own git worktree. The canonical tree is never written directly — only fast-forwarded into, at Steps 9, 10, and 11. If it advanced mid-run, the fast-forward fails and I resolve it by hand. No rebases, no force-pushes.

The pieces that make it work

Three structural choices do most of the work. The eleven-step ceremony is their consequence, not the point.

Specialist agents, narrow scope. No agent owns two jobs. The Python reviewer never runs tests, the test engineer never runs ruff, DevOps reads other agents’ verdicts but doesn’t re-verify them. That is how I keep each prompt short enough to be effective — a 200-line agent that does one thing well beats a 1,000-line one trying to be every reviewer at once.

Handoff documents on disk. Agents talk through Markdown files, not the orchestrator’s context window. Each one writes a short summary section that downstream agents read by default, consulting the full body only to verify a specific claim. A shared context blob written before parallel review means nine reviewers don’t each re-read the plan and every upstream handoff. This is the biggest token lever in the system.

The user gate, late and explicit. I’m the last reviewer, not the first. The agents catch the mechanical issues — missing tests, broken types, unhandled errors, drifted docs, exposed secrets. By the time I get the readiness summary, what’s left is the small set of questions that genuinely need judgment. That’s a higher-leverage use of my attention than reading the diff cold.

The costs

A full run for a non-trivial Python feature takes somewhere between thirty minutes and two hours of wall time. The token cost is hard to pin down — the orchestrator, up to nine parallel reviewer contexts, repeated handoff reads — but it sits comfortably an order of magnitude above asking a single agent to “implement this and commit it.” On a Pro plan or a personal API budget, you notice.

The cognitive cost is real too. The orchestrator has to honor wave-scoping, worktree isolation, foreground spawns, handoff durability — a dozen contracts, each born from a session that failed without it. Writing plan notes the pipeline can consume takes practice; writing agent definitions that don’t drift into each other’s jobs takes more.

It also produces a lot of process artifacts — plan notes, handoffs, retros, validation plans, deployment docs. Some gets read again; some is pure ceremony, and for a while I couldn’t tell which was which. Then I measured it.

Why I keep using it anyway

I classified 142 sessions of retros, catch by catch, and the numbers came out lopsided in a way I didn’t expect. The highest-value step is the design validation at 1b: 72 blocking-or-high catches nothing downstream would have found, one in 41% of all sessions — features dead on arrival, truth tables wired backwards, plan steps that couldn’t run, all caught before a line of code existed. The security reviewer earns its slot with 37 unique catches the language reviewers never produce: path-traversal bypasses, secrets leaking into logs, injection vectors. The best yield per invocation is live execution at Step 7, which fired in only 7 sessions but returned 5 catches, including one shipping-blocking hardware bug that four rounds of review and a 98% mutation-kill rate both sailed straight past.

Not everything pays. The test engineer’s Step 4 review produced exactly one unique high-value catch across all 142 sessions, and its catch class overlaps almost entirely with mutation testing, which finds the same gaps cheaper. You only learn that by counting.

The ceremony is real, and it sits on its own line. 132 of those 142 sessions paid a machinery tax — 325 process failures that were pure cost of running the pipeline: worktree snags, commit mechanics, missed handoffs, permission-prompt storms, none of it work the change itself generated. The verification core earns its keep; the machinery around it is a tax I’m still trying to cut.

There’s a less obvious payoff. The pipeline is the part of my workflow that runs the same every time. When I’m tired, working between a kid’s bedtime and my own, it isn’t — it runs the same steps in the same order and won’t let me skip the parts I’d skip on my own. The alternative isn’t “fast and good,” it’s “fast and full of the mistakes I make when I’m worn out.”

When I skip it

Neither pipeline runs at full size every time. The fast/full split is the top-level fork; under the full path, a flow table scopes each run further to what the change actually needs:

• The eight-step fast path for a single-file change that clears the allow-list — one language reviewer, no architect, no separate RED step, no retro.
• Full pipeline for new features, new integrations, significant refactors.
• Phase-1-only for small bug fixes following established patterns.
• Test-only when I just need to backfill coverage.
• DevOps-only when I say “just commit” and mean it.
• Doc-only for typo fixes and frontmatter cleanup.

The escape hatches are deliberate. The point isn’t to perform the full ceremony on every change — it’s that the ceremony is available, in a known shape with known costs, the moment a change crosses the threshold where I’d otherwise wing it.

The shape underneath

The pipeline is doing for code what the ambient AI layer in the post before this one does for everything else: it converts a thing I’d do unreliably, sometimes, into a thing that gets done the same way every time, by a deterministic skeleton with focused LLM judgment in the middle. The trigger is me writing a plan note; the landing place is a commit, with a retro and a closed plan attached.

It’s more elaborate than the ambient pipelines, and it produces software, which has a different cost of being wrong. More ceremony where errors are expensive, less where they aren’t. I’d rather pay the tokens and wait the hour than ship the wrong thing fast.