Parallel agents and quality gates
Wednesday, 11:00, week 7. Every engineer now runs two or three Claude Code sessions. Pull requests went from 31 to 96 a week. Twenty-three are waiting for review, main broke twice, and Atlantica just emailed Karim: a £200 London room shows as €274.
Several agents at once can write a lot of code. But people still review it, and changes that are fine alone can break together. Here's how to run them in parallel safely.
- Problem
Week 7 of StayHub for Chains. Each of 8 engineers runs 2–3 Claude Code sessions in parallel. Pull requests opened went from 31 to 96 a week; 23 are waiting for review, the oldest for 6 days, and main broke twice this week.
- Why the simple system fails
More sessions produce more code, but review capacity stays at about 80 careful reviews a week, so the queue grows forever. Sessions working on the same concern in different files merge cleanly and break together; each PR was green alone, and main wasn't.
- Engineering concept
Parallelism needs isolation (one task, one branch, one worktree, one area), automated gates that every merge must pass, review treated as the real bottleneck (WIP limits, smaller PRs, gates that remove mechanical review), and merge discipline (test changes together, main always green, revert first).
- Technology
Git branches and worktrees, Claude Code sessions and sub-agents, CI with required status checks, branch protection, CODEOWNERS, merge queues, WIP limits.
- Trade-offs
More parallel sessions raise output until review saturates, then only raise waiting time and risk. Strict gates slow each merge a little but keep main trustworthy; loose gates feel fast until the day main breaks under everyone.
The problem
2 min- You · Engineer at StayHubPull requests opened went from 31 a week to 96.
- Omar · On-call SRE23 are waiting for review, the oldest for 6 days. Main was red twice this week.
- Karim · CTOThen give everyone five sessions. We need the speed.
The big idea
4 minReview capacity, not agents, sets your speed. Isolate sessions, let machines guard main, and keep work in progress below what people can review.
Five more cooks make dishes faster, but every plate still goes through one pass where the head chef checks it. Plates pile up and go cold, or get waved through. The pass is your review.
How it works
5 minThe sum first. A careful review takes ~30 minutes; eight engineers at ~1 hour a day: 8 × 5 × 1 h = 40 h ≈ 80 reviews a week. Then five rules.
- 1Isolate by folder and concern
A is a separate folder on its own branch of the same repository: one task card, one worktree, one session. And one owner per concern (currency, timestamps) each week, in any file.
- 2Research freely
A researches with its own context and reports back. Read-only sessions create no PRs: run as many as you like.
- 3Cap work in progress
A caps work in progress: at most 2 open PRs per engineer. A third editing session waits until one merges.
- 4Gate with machines
Required CI, CODEOWNERS approval, branch protection. Mechanical checks leave reviewers: ~20 minutes per review, ~120 a week.
- 5Merge together, keep main green
A tests each PR with those ahead of it before it lands. Staging deploys only from green main. Main red: stop merging, revert first.
Watch a decision being made
4 minYou turn 23 waiting PRs into a flowing pipeline
Make parallel agent work safe and fast before the pilot.
- 1Measure the bottleneck
Arrivals 96/week; capacity ~80/week; queue +16/week; 23 waiting, oldest 6 days.
Why: Without the sum, "more sessions" sounds like more output. With it, it's obviously more waiting.
- 2Isolate sessions
One task card → one branch → one worktree → one session. Each concern has one owning session this week.
Why: Worktrees stop file clashes; owners per concern stop meaning clashes.
- 3Move mechanical review to gates
Required CI on
pull_requestandmerge_group: types, lint, boundaries, tests, migrations, log-PII. CODEOWNERS for src/rates, src/payments, db/migrations.Why: A review drops to ~20 minutes; capacity rises to ~120/week.
- 4Cap WIP and drain the queue
2 open PRs per engineer; research unlimited. This week, reviews before new sessions; the two oldest PRs closed and re-cut smaller. Lina's only check: "And the 23 waiting now?"
Why: Arrivals must stay below capacity, or nothing else matters.
In real life
3 minLinux kernel: maintainers
- Maintainers per subsystem
- Patches reviewed by people
- Passed up a chain of trust
Human judgment is the main gate.
Google: checks + owners
- One huge repository
- Automated checks on every change
- Code owners must approve
Machines first, then owners.
What goes wrong
3 minNo conflict, combined bug.
One owner per concern each week.
Green alone, red together.
A merge queue, or up-to-date branches required.
Partners test a broken build; the cause gets buried.
Deploy only from green main; stop and revert first.
Trade-offs
3 min| Parallelism | Fits when | You pay |
|---|---|---|
| Maximum sessions | Read-only research, or idle reviewers | Queue explodes; collisions |
| Matched to review capacity | Almost always for code that ships | Some idle agent time |
| One session each | Very risky areas, teams new to agents | Leverage unused |
- Karim · CTOTwo open PRs per person? Five weeks left. Five sessions each, let CI sort it out.
- Omar · On-call SREAfter Tuesday? One session each and no merges without me watching.
- Karim · CTOThat's a freeze five weeks before the pilot.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- How many editing sessions run at once, set by review capacity (2 open PRs per engineer).
- Which session owns each concern this week, so no two change the same meaning in different files.
- Which checks are required, merge queue on, staging only from green main, and who reverts when main goes red.
You're in worktree ../stayhub-ari-14 on branch chains/ari-14, task card ARI-14.md. You own only src/chains/ari; currency conversion belongs to another session this week, so don't add or change any conversion; tell me instead. First, a sub-agent lists where src/chains parses CRS timestamps. Then plan, implement, run pnpm check and pnpm test:chains. Open a PR only when both pass, listing every changed file.
- Each session has its own worktree, branch and task card naming one area.
- The PR touches only its card's area; anything in another concern is reverted or flagged.
- Fridays: PRs waiting, oldest age, arrivals vs reviews. Over capacity? Lower WIP before adding sessions.
- A session "helpfully" fixing something in another session's concern.
- PRs merged while main is red, or staging deploying before CI finishes.
- Open PRs and wait times rising while more sessions start.
Check yourself
2 minNext: rewind to week 5, when chain invoicing ran into StayHub's oldest code, written years ago by people who have left. First, understand it with an agent.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Visual diagram, Analogy, Why it matters, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
From 23 waiting PRs to a flowing pipeline
Make parallel agent work safe and fast for the chains squads before the pilot: isolate sessions, gate merges, and fit work to review capacity.
- 1Measure the bottleneck
Arrivals 96/week; careful review ~30 min; ~1 h/day per engineer → ~80/week. Queue grows ~16/week; 23 waiting, oldest 6 days.
Why: Without the sum, "more sessions" sounds like more output. With it, it's obviously more waiting.
- 2Isolate sessions by folder and concern
One task card → one branch → one worktree → one session. Each week, every concern (currency, timestamps, hotel mapping) has one owning session. Task cards already name one area.
Why: Worktrees stop file clashes; owners per concern stop meaning clashes like Tuesday's double conversion.
- 3Move mechanical review to gates
Required CI on
pull_requestandmerge_group: check (types, lint, boundaries), full tests, migrations:verify, log-PII. CODEOWNERS for src/rates, src/payments, db/migrations. Branch protection on main.Why: Reviewers stop checking what machines can; a careful review drops to ~20 min, capacity rises to ~120/week.
- 4Cap work in progress
Max 2 open PRs per engineer; research sessions and sub-agents unlimited. This week: reviews before new sessions; the two oldest PRs closed and re-cut smaller.
Why: Arrivals must stay below capacity, or nothing else matters.
- 5Set merge discipline
Merge queue on. Staging deploys only from green main. Main red → stop merging, revert, then fix on the branch with a test for the failure.
Why: Tuesday's cascade came from staging before CI and three merges on a red main.
| Tuesday's failure | Gate or rule that stops it |
|---|---|
| Two sessions on the same concern | One owner per concern each week |
| Each PR tested against old main | Merge queue (merge_group CI) |
| Staging deployed before CI finished | Staging deploys only from green main |
| Three merges on a red main | Red main → stop merging, revert first |
| Long queue, rushed reviews | WIP limit of 2 open PRs per engineer |
Visual diagram
Parallel sessions, isolated, flowing through gates into a main that stays green.
Analogy
- Restaurant with one passMore cooksParallel agentsMore agent sessions
- Restaurant with one passOwn station eachParallel agentsOwn worktree and branch
- Restaurant with one passThermometer and scalesParallel agentsAutomatic checks
- Restaurant with one passHead chef at the passParallel agentsHuman review
- Restaurant with one passTaste dishes togetherParallel agentsMerge queue
Where it breaks: a cold plate is obvious. A broken combination of code changes can look perfectly fine until a guest sees the wrong price.
Why it matters
Waiting code isn't progress. Twenty-three changes waiting six days lose their context and start conflicting with each other.
Fine alone isn't fine together. Two sessions each added a currency conversion in different files. No warning from Git. A £200 London room showed as €274 to Atlantica.
A broken main stops everyone. Every new branch starts broken, and people learn to ignore red.
Rushed reviews let bugs through. When the queue is long, people skim. That's when incidents slip in.
Check your understanding
Practice ladder
Which sessions collide?
Debugging Warm-upTomorrow's sessions, each in its own worktree:
- A: in
src/chains/ari/mapper.ts, parse CRS timestamps as the hotel's local time (Atlantica sends local times). - B: in
src/chains/ari/mapper.ts, normalise room codes to upper case. - C: in
src/chains/applier/batch.ts, drop an update if it's older than the stored one, comparing timestamps as UTC. - D: a read-only sub-agent listing every place src/chains parses or compares timestamps.
- E: a new monthly report in
src/chains/reports.
Trace each pair that could clash: textual (Git conflict), semantic (merges cleanly, breaks together), or safe. What do you change in the plan?
Complete the gates
Design PracticeFill the blanks in the rules for main.
| Rule | Setting |
|---|---|
| No direct pushes | ___ |
| CI on every PR and on the combined changes | CI triggers: ___ and ___ |
| CI jobs | pnpm check, ___, ___, ___ |
| Payments, rates and migrations reviewed by their experts | ___ + required review |
| Changes tested together before landing | ___ |
| Partners never see a broken build | Staging deploys only ___ |
| Main red | ___, then ___, then fix on the branch |
| Arrivals below review capacity | ___ open PRs per engineer |
Capacity after the pilot
Estimation StretchAfter the pilot, two engineers join: 10 in total. Each runs agent sessions; PRs arriving are forecast at 140 a week for the rollout to 420 hotels. A careful review takes ~30 minutes today; each engineer can spare ~1 hour a day for reviews.
Without help: (1) compute review capacity and the gap; (2) propose at least three changes and estimate their effect; (3) say what you'd tell Karim about adding more sessions.
Turn off reviews for the last week?
Decision StretchWeek 11, pilot next Thursday. 31 PRs are waiting. Karim: "Turn off required review for src/chains until the pilot. CI is green on all of them, and the gates you built catch the mechanical stuff."
The 31 PRs: 12 are needed for the pilot (S5 bookings back, S6 hardening), 19 are improvements for later (reports, refactors, M2 prep). Options: (1) Karim's: disable required review for src/chains for a week; (2) keep reviews, freeze non-pilot PRs, review the 12 first, borrow two reviewers from the Search team for the week; (3) delay the pilot by a week.
Write your decision: "We chose X over Y because…, accepting the risk of…".
Explain it yourself
Karim asks: "Agents are cheap. Why not give every engineer ten sessions?" Answer with the numbers from week 7.