The swinging door

Day 28: The Swinging Door — When a Reversible Decision Stops Being Reversible at Scale

Most of us approve agent PRs with one rule: if it's reversible, ship it. That rule was built for one person making one decision. A coding agent makes the same decision in every repo it can reach. A change you can undo once in four minutes can be very expensive to undo two hundred times, and you won't find out until you have to.

The Monday message: "412 PRs, all green"

One Monday I opened a message that said "412 PRs, all green." Over the weekend our agents had rolled one small refactor out across most of our repos. Every PR passed CI. Every reviewer approved, and every reviewer was right to. On its own, each change was a textbook two-way door. If any single PR caused trouble, you could revert it in about four minutes.

Getting rid of the pattern took eleven days. By the time we noticed the problem, other agents had read the merged code as "how we do things here" and built on top of it. So had the humans. New code depended on the new shape. Reverting a PR was trivial. Pulling the pattern back out of the codebase was a migration.

Here's what stung: nobody misjudged anything. We called it a two-way door, and for any one PR that was true. We were using the wrong model for the situation.

Quick recap: why leaders love the door model

Earlier in this series we used Bezos's split between one-way doors (hard to reverse, so decide slowly and carefully) and two-way doors (easy to reverse, so decide fast and close to the work). Few tools keep a team's decisions moving as well as this one. Most decisions turn out to be two-way doors, so you can push them down to the people doing the work. But the model quietly assumes one decider making one decision, one time. It treats reversibility as a property of the decision itself. When the same decision gets copied many times, that assumption breaks.

The founder-era contrast: humans had a built-in brake

When I was CTO of a six-engineer team, a bad two-way-door call spread at human speed. Someone introduced a questionable pattern. A week later a second person copied it. Around the third copy, someone in code review asked "wait, why are we doing it this way?" and that was the end of it. Nobody designed that brake. It came from people copying slowly and a few people seeing every PR.

Agents removed the brake. They don't get tired or space their work out over weeks, and they read merged code as precedent. A pattern that used to take a month to reach three repos can now reach hundreds overnight. Each copy is reviewed on its own, by a different reviewer, and every one of those reviewers correctly sees a small, reversible change.

Name the third door: the swinging door

A swinging door is a decision that's cheap to undo once and very expensive to undo at scale. What it really costs to reverse isn't the price of one revert. It's closer to this:

swinging-door cost  ≈  undo cost per instance
                     ×  number of copies
                     ×  coupling that builds up over time

(coupling = code, configs, prompts and other agents that start depending
 on the pattern after it lands)

Treat this as a way of thinking about the cost. You can't compute it precisely. The term that matters is the last one. Copies alone scale linearly, and a script can revert 400 identical PRs. Coupling is what turns four minutes into eleven days, because each day the pattern stays in place, more things grow around it.

| Door      | Who decides                                    | How fast                                | What triggers escalation                                                       |
|-----------|------------------------------------------------|-----------------------------------------|--------------------------------------------------------------------------------|
| One-way   | Senior human / leader                          | Slow, deliberate                        | Always, before acting                                                          |
| Two-way   | Individual engineer or agent                   | Fast, no ceremony                       | Rarely, only when something breaks                                             |
| Swinging  | Agent for the first instance, human before it spreads | Fast once, then pauses at repetition | Repetition threshold, a precedent flag, or touching a shared interface |

How to spot a swinging door before it swings

You don't need any ML background here. If you've ever approved a "small, reversible" change, you can run these four tests:

• ▹It's a pattern, not a one-off. The change reads as "do X this way", not "fix this bug here". Patterns exist to be copied.
• ▹It touches shared interfaces: internal libraries, API contracts, config schemas, logging formats, error-handling conventions. If other code calls it or parses it, coupling builds fast.
• ▹Agents will treat it as precedent. Picture an agent in another repo finding this merged PR and copying it. If that's likely, the decision has already left the repo it was made in.
• ▹Nobody owns removing it. Ask whose job it would be to get rid of this a month from now. If the answer is "whoever notices", nobody owns the undo cost, and it will keep growing.

One of these signs means you should look closer. Two or more usually means it's a swinging door.

The rule we run at PhoenixDX: the first instance is free, the Nth needs a human

We didn't want to slow down the first decision, because trying something once is exactly what a two-way door is for. So the rule doesn't target the change. It targets repetition, and it has three parts.

• ▹Repetition threshold. An agent can apply a new pattern in its first repo with no extra review. Before the same pattern goes into N repos, a named human approves it as a pattern rather than as a PR. Our N is small. Tune yours.
• ▹Precedent flag. A reviewer who approves a PR answers one more question: "Is this OK to copy?" The default answer is no, and agents may only use flagged PRs as examples. Approving a change is one decision. Endorsing it as precedent is another.
• ▹Weekly pattern diff. Once a week we group merged agent PRs by a normalised change signature and list every pattern that showed up in more than one repo. A human reads the list. That takes about fifteen minutes and gives us back the code-review brake we lost.

# agent-policy.yaml (simplified)
swinging_door:
  repetition_threshold: 3        # Nth copy across repos needs pattern approval
  scope: cross_repo              # count copies across the org, not per repo
  always_escalate_if_touches:
    - shared-libs/**
    - api-contracts/**
    - config-schemas/**
  precedent:
    default: not_copyable        # agents may only imitate flagged PRs
    label: precedent:approved
  exempt:                        # independent copies, no coupling
    - dependency_patch_bump
    - formatter_autofix
weekly_pattern_diff:
  group_by: change_signature
  report_if_repos_gte: 2
  owner: eng-manager-on-rotation

# Sketch of the weekly pattern diff: same normalised change in many repos = a door swinging
from collections import defaultdict

def signature(pr):
    # strip repo-specific names and line numbers so the same change matches across repos
    return normalise(pr.diff, drop=["paths", "identifiers", "line_numbers"])

def spreading_patterns(merged_agent_prs, min_repos=2):
    seen = defaultdict(set)
    for pr in merged_agent_prs:
        seen[signature(pr)].add(pr.repo)
    return {sig: repos for sig, repos in seen.items() if len(repos) >= min_repos}

The leadership part, not the tooling part

Writing the YAML is the easy bit. The hard decision is where your limited human attention goes. Your reviewers can't read all 412 PRs, and they shouldn't try. The swinging-door rule takes their attention off individual PRs and puts it on patterns, which is where the risk is now. That's a manager's decision, because it also decides what the team stops looking at.

A team that has absorbed "it's a two-way door, just ship it" will hear any new rule as bureaucracy creeping back. So I explain it in terms they already use:

• ▹"Two-way doors still mean ship it. One-off decisions don't change."
• ▹"A swinging door means ship it once, then get a human to sign off before the copy machine starts."
• ▹"You're not asking permission to make the change. You're deciding whether it becomes a standard."
• ▹"The pause comes at the third copy, not the first. If you're just experimenting, you won't hit it."

Say it plainly: this isn't about distrusting agents. A human who could open 400 PRs in a night would need the same rule. What you're governing is how fast things get copied.

What it costs, honestly

• ▹Later copies lose a bit of speed. The Nth instance waits for a human to approve the pattern. Usually that's a few hours. Sometimes it's a day.
• ▹False alarms. The pattern diff flags things that spread but never couple.
• ▹We over-escalated in the first month. Dependency patch bumps and formatter autofixes went to humans because they appeared everywhere. But those copies are independent: nothing builds on a formatting change, and a script reverts them cleanly. Repetition without coupling isn't a swinging door, so we added the exempt list.
• ▹Precedent-flag fatigue. Reviewers started ticking "OK to copy" by reflex. We put the question explicitly into the review template, and we rotate ownership of the weekly diff so people don't stop seeing it.

For us the trade is worth it. We pay a small, predictable cost on the second and third copies, and in exchange we avoid the occasional eleven-day cleanup.

Your exercise for tomorrow

Write down the last three "obvious two-way doors" your agents acted on. For each one, count how many repos it was repeated in. If any count is above one, that door has already started to swing.

Tomorrow, Day 29: you've found a swinging door. Who actually has the authority to revoke it across every repo, and how do you make sure that person exists before you need them?

Extend your knowledge

• ▹Re-read Jeff Bezos's 2015 Amazon shareholder letter (Type 1 vs Type 2 decisions). Mark every place where it assumes a single decision-maker.
• ▹Read the "Large-Scale Changes" chapter of Software Engineering at Google (Winters, Manshreck, Wright). It covers how Google plans, reviews and lands changes that touch huge numbers of files across its monorepo, which is the closest pre-agent analogue to a swinging door.
• ▹Look up Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." It's the clearest explanation of why coupling grows once a pattern lands.
• ▹Run the weekly pattern diff once by hand on the last 30 days of agent PRs in your org. A rough signature is enough to start, such as the files touched plus the PR title template.