Last week at @HelloUntangle we completed the largest and riskiest engineering program in our history.
- 834 files
- Prod data mutation
- DB schema update
- 31 PRs
- Started Friday -> completed Monday
- Zero prod incidents
All with one Fable parent orchestrator session.
One parent @DevinAI session planned the work, spawned forty child sessions to execute it, enforced regression gates and backup checks between phases, and surfaced only the decisions that genuinely required an owner: scope rulings and go/no-go on irreversible steps.
What made this work is a set of program-management patterns that would improve any large migration.
Here's how we did it ...
The architecture: one orchestrator, many workers
- One parent session owned the program end to end. Its only job was to plan, spawn child sessions, review their output, sequence the phases, and escalate to me when a decision needed a human. It wrote zero code.
- ~40 child sessions did every piece of actual work: eleven parallel audit sessions in Phase 0, execution sessions for each wave, and dedicated gate-runner sessions whose only job was to run regression suites.
The split matters because the failure mode of long-running projects — AI or human — is context collapse: the thing doing the work gradually loses the plot of the overall program.
Keeping the parent a pure orchestrator keeps its context clean; it holds the plan, the scope decisions, and the state of every wave. Each child gets a fresh, focused context with exactly one job.
The seven patterns that made it work
1. Audit first, and freeze the findings in a single manifest
Phase 0 was eleven parallel audit sessions, each covering one slice of the codebase: app routes, API routes and crons, the database schema, shared libraries and workflows, scripts and docs. Their findings were synthesized into one file and committed to the repo.
The manifest assigns every unit of code a verdict and a wave number. Two rules made it powerful:
- No worker re-litigates scope. Every execution prompt said, in effect: the manifest is the source of truth. Without this, each of forty sessions would derive its own opinion about what is in scope — and they would disagree.
- UNKNOWN means stop and ask. Anything the audits were silent on was explicitly marked unknown, with an instruction: do not guess; get a ruling. Owner rulings were recorded directly into the manifest, so later sessions inherited them.
2. Order the work by risk, not by convenience
The waves were sequenced from safest to most irreversible.
Wave
What
Risk
0
Audit + manifest + restore-point git tag
none
1
Changes verified to have no live dependents
near zero
2
Entanglement surgery on shared infrastructure
medium
3–4
The bulk of the code changes
medium
5
Production data changes (with dry-run inventory + snapshot)
high
6
Schema migrations
high
7
Dependency pruning, agents.md rewrite, agent knowledge-base audit
low
Production data changes (Wave 5) come before schema changes (Wave 6), and both come only after every code path that touched the affected tables was verifiably updated. By the time the migrations ran, nothing could still be depending on the old state.
3. File-disjoint boundaries make parallelism safe
Within a wave, child sessions ran in parallel — one wave had four sessions working different parts of the tree simultaneously. The discipline: every prompt included an explicit file boundary, and the boundaries were disjoint. No merge conflicts, no two agents editing the same file, no coordination needed between children at all.
This is classic task decomposition — the same thing you'd do splitting work across engineers — but agents need it stated explicitly, in the prompt, every time.
4. Safety gates between waves
No wave started until the previous one passed a gate. The gates were themselves child sessions:
- A browser-driven, end-to-end regression suite covering the platform's core customer workflow ran after Wave 2 and again after Waves 3–4, on a fresh isolated database branch.
- Before any production data changes: a dedicated session audited our database backup inventory (count, date range, retention), and we took a fresh point-in-time snapshot.
- The production step itself ran dry-run first, produced row counts for owner approval, and re-verified counts after execution.
- A git tag marks the restore point for every changed line.
When a gate failed, it produced a scoped fix session. The regression suite caught, for example, a customer-facing flow that had been broken by an over-eager change; one fix session restored it within hours. That's the system working — the gate turned what would have been a customer-reported bug into a same-day fix.
5. Humans approve; agents propose
I never wrote code, ran a migration, or executed a production script in this project. But every irreversible step required my explicit go-ahead: each merge to main, the production data changes, the schema migrations, and each ruling on UNKNOWN scope items.
The pattern for destructive work: the agent proposes an inventory, the human approves the inventory, then the agent executes exactly that inventory. The production session produced the precise list of rows it would touch before touching anything. I approved a specific list, not a vague intention.
6. An escalation protocol for surprises
Children were told what to do when reality disagreed with the manifest: stop, report to the parent, don't improvise. Real examples:
- A module the audit called safe turned out to have a live dependent elsewhere → the child flagged it, and the unit was demoted to a later wave with the entanglement noted.
- A second audit round reversed first-round verdicts on five whole areas → the reversals were written into the manifest as explicit overrides rather than resolved ad hoc by whichever session hit them.
The parent absorbed these surprises into the plan. Individual workers never made scope decisions.
7. Leave the campsite cleaner: teach the system what changed
Wave 7 may be the most underrated phase. After the change shipped, sessions rewrote our AGENTS.md, repo skills, and agent knowledge base to describe the new architecture — so every future agent session starts from the truth, not from stale instructions. If your engineering is agent-driven, your documentation is load-bearing infrastructure.
What it cost
Every session in the program was tagged, so the ledger is complete: one parent and thirty-nine children, all on Devin's Ultra Agent, Friday afternoon through Monday morning. These are the actual metered costs from our usage dashboard.
Phase
Sessions
Cost
Parent orchestrator (multi-day)
1
$115.26
Phase 0 audits (two rounds) + manifest synthesis
12
$85.56
Wave 1
4
$37.55
Wave 2 (entanglement surgery)
4
$299.34
Waves 2–4 regression gates + fixes
4
$244.69
Waves 3–4
5
$130.84
Wave 5 (production) + backup audit
2
$15.20
Wave 6 (schema migrations)
3
$118.83
Wave 7 (dependencies, docs, knowledge) + final gate
4
$96.64
Infrastructure fix
1
$11.47
Total
40
$1,155.38
Three things stand out in the breakdown.
- The entire twelve-session audit phase that produced the manifest cost under $90 — the cheapest insurance we have ever bought.
- The most expensive line items sit exactly where the hard thinking was: the entanglement surgery ($299) and the regression gates ($245) that kept everything honest.
- The step with the highest stakes — the production data change — cost $15, because by the time it ran, all the risk had already been engineered out of it.
Note: This whole project could've been much more affordable if Devin allowed me to choose a different model for the sub-agents. The majority of the coding work could've been completed successfully with gpt 5.5 or opus 4.8. It would be simple to instruct Fable to choose the appropriate model to match the sub-agent task.
Even without that though: $1K is unbelievably cheap for the work we completed - and the speed at which is was done and verified - wow.
https://x.com/ryancarson/status/2072694425365426344
The takeaway
The headline isn't that AI wrote a lot of code — agents executing well-specified changes is table stakes now.
The headline is that the program management itself was delegated: decomposition, sequencing, parallelization, gating, and escalation all ran inside the orchestrator, and the human role compressed to exactly the decisions that require an owner.
If you're going to try this, steal the patterns, not the tooling:
- Audit first; freeze findings in a manifest that no worker may re-litigate.
- Sequence waves by risk; irreversible steps last.
- Give parallel workers explicitly disjoint file boundaries.
- Gate every wave with a real regression suite and real backups.
- Require proposed inventories before destructive changes; approve the list, not the idea.
- Define the escalation path before the surprises arrive.
- Update your docs and agent knowledge as part of the project, not after it.
Here's to happy orchestrating! :)
