# 15.10 After the merge (/building-ai-workers/code-review/after-the-merge) --- type: Document title: "15.10 After the merge" description: "A merge queue, feature flags, staged rollouts and a rehearsed revert make mistakes small after the merge, and the person who lands a change owns it." status: stable order: 315.1 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-02T18:33:52Z chapter: "15" part: III expert_status: builder-only concepts: [ "15.10" ] last_verified: 2026-10-31 sources: - id: anthropic-team-review title: "How the Claude Code team does code review (Anthropic, October 15, 2026, accessed 2026-10-31)" resource: https://claude.dev/blog/solving-code-review-at-anthropic/ - id: github-merge-queue title: "Managing a merge queue (GitHub, accessed 2026-10-31)" resource: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue - id: github-reverting-pr title: "Reverting a pull request (GitHub, accessed 2026-10-31)" resource: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request generated: at: 2026-11-02T18:33:52Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85 dirty: true ksor_version: 0.0.60 --- **In everyday life.** A restaurant adds a new dish to the kitchen's recipe book on Monday, but puts it on the menu only on Thursday. It offers it first to one table of regular customers, and keeps the old dish ready in case the new one fails. Adding the recipe, offering it, and serving it to everyone are three separate decisions. **What you will learn.** How to get a merged change to its users safely, and how to undo it. **Why it matters.** A merged change is not yet delivered, and a mistake after the merge reaches real users and real money. ### What is left after the merge? Delivery. Review decides whether a change may join `main`. Getting it into production is the last part of the bottleneck from the chapter's opening, and often the slowest. Four practices make that step safe without making it slow. ### What is a merge queue for? A **merge queue** stops pull requests from breaking `main` together. Two pull requests can each pass their checks and still break it, because each was tested against an older `main`. For example, one renames a function, and the other still calls the old name. The queue lines up approved pull requests and tests each one on top of the latest `main` plus the changes ahead of it. Only a change that passes there is merged. It matters most on a busy repository, where many changes merge each hour. On GitHub, the required workflows must also run on the queue's own event, `merge_group`. Any check that compares with the base branch must read the base from that event, or the queue tests nothing.[^github-merge-queue] ### What does a feature flag do, and what does it not do? A **feature flag** is a setting that turns new behavior on or off without changing the code. Merging a change behind a flag that is off puts the code on `main`, where it is reviewed, tested and kept up to date. It reduces the risk of the merge when the new code is isolated and a test shows the old behavior unchanged with the flag off. It does not remove the risk: imports, new packages, changes to shared code and data migrations, which change stored data, all take effect when the merged code runs, whatever the flag says. Turning the flag on is a separate decision, by the person who owns the policy. Two warnings come with flags. Every flag doubles the cases to test, on and off. And a flag that stays forever becomes clutter, unused code that gets in the way, so give each one an owner and a date to remove it. ### What is a staged rollout? A **staged rollout** turns new behavior on for a few users first, watches what happens, then turns it on for more users. Software that others install can do the same with release channels: a `latest` channel that gets changes first, and a `stable` channel that gets them later. ### How do I get back? With a **rollback** you have rehearsed, or practiced. A rollback is a return to the last good state. For a flag, it is turning the flag off. For code, it is a **revert**. That is a new commit, or a new pull request, that undoes the merged one and keeps the history ([15.2](git-through-the-agent.md)).[^github-reverting-pr] Rehearse it before you need it, on a branch, and check that the branch gives the old answer afterward. Some things cannot be rolled back this way. A payment already sent stays sent, and a message already delivered stays delivered. That is why turning on a flag that sends money is its own high-tier decision. ### Who watches it after the merge? You land it, you own it. To land a change means to merge it. The person who merges a change, or who directed the agent that wrote it, watches it after the merge and is the first to fix it if it breaks. Review shares understanding. It does not hand the responsibility to someone else. **In the case study.** The team's merge queue reruns every check against `main` with the change applied. New behavior ships behind flags, to Anthropic's own staff first, and flags turn off without a new release. Public releases go to the `latest` channel before `stable`. When something breaks, whoever landed it usually fixes it.[^anthropic-team-review] **At work.** The weekend rule merges with `PAY_WEEKEND_RULE` off. On `main`, `npm run due -- 2027-03-05` still prints 8 invoices, $19,229.53, the Chapter 12 answer. The test "with the rule off, the answer is unchanged" checks exactly that on every change. With the flag on, it prints 10 invoices, $33,109.53. Ana rehearses a revert of the merge on a scratch branch. The weekend code disappears, every check still passes, and the answer is still 8 invoices. Dave Kowalski, the controller, will decide in April whether to turn the rule on. The person who turns it on owns the first Friday run with it. **The operating rule:** merge risky behavior behind a flag that is off, turn it on as a separate decision, and rehearse the way back before you need it. ![Four stages: merged, with the code in main but not yet released, deployed with the flag off, on for a small group, and on for everyone. From the last two stages an arrow returns to the flag being off if rollout checks fail. A panel says recovery has two parts: stop the behavior by turning the flag off, and handle effects such as data writes and external actions, which may need separate repair.](img/merge-to-rollout.png) *Figure 15.16. From merge to everyone. Merged is not deployed, and deployed, which means running in production, is not turned on. Each stage is a separate decision, with a way back.* **Practice it.** [Practice: after the merge](both-ai-vendors.md#practice-after-the-merge), in your own tool, ten minutes. [^github-merge-queue]: Managing a merge queue, GitHub. [^github-reverting-pr]: Reverting a pull request, GitHub. [^anthropic-team-review]: How the Claude Code team does code review, Anthropic.