The Merge Button Is a Decision Point

An agent opens a pull request. Tests pass, the diff looks clean, and the only thing standing between that code and production is a human clicking merge. Teams that would never call this an autonomy decision treat it as a formality, a green checkmark away from done. It is a decision point with the same structure as anything else in a friction audit, and it is worth applying the checklist to directly rather than assuming code review is a special case.

Tool call depth, applied to review

The audit framework asks how many steps a decision requires before it resolves. Merging is one click. Actually evaluating the change, reading the diff line by line, pulling the branch and running it locally, asking the agent to explain a specific piece of logic, is several steps more expensive, every time, regardless of what the change actually does. A one-line config tweak and a change to authentication logic cost the same to approve and wildly different amounts to actually verify. The friction is not attached to risk. It is attached to whichever path is shorter, and the shorter path wins by default.

Context pressure, on the human side

The audit piece named context window pressure as a real, measurable load on an agent making a judgement call late in a long context. The same mechanism runs on the human reviewer. Someone looking at the fifteenth PR of the day, most of them agent-generated, is operating with less scrutiny available than someone looking at the first, and the fifteenth is not statistically less likely to be the one that matters. This audience tends to treat friction as something that lives in the agent's architecture. It also lives in the reviewer, and a friction audit that only looks at the system misses half the picture.

Escalation cost asymmetry, at the merge button

This is the clearest transfer from the audit piece. Approving is one click. Requesting changes is a written comment, a context switch, a wait for a re-push, and often a small social cost of being the person who slowed things down. When escalating costs more than approving, the default drifts toward approval independent of the diff's actual risk, exactly the mechanism the refund example demonstrated. Nobody decided that merge should be biased toward yes. The friction sitting on top of the two choices decided it for them.

A worked example

A dependency-bump agent opens PRs automatically whenever a package has a new patch version. CI is green, the diff is small, and these merge on a fast path with a single approving glance, because they always have. One of these bumps changes a default timeout deep in a library the team barely thinks about, ships past review at the same speed as every other bump, and causes a production incident three weeks later when traffic patterns hit the new default under load. The postmortem calls this a gap in oversight. It was not a gap. It was friction correctly allocated to look identical across two decisions that were never actually the same size.

What this means for the scoring layer

This is precisely the decision Checkpoint Copilot is built to classify: reversibility, consequence magnitude, confidence, precedent, and regulatory exposure, scored per decision point rather than assumed uniform because every PR arrives through the same interface. A merge button that treats a documentation fix and a dependency bump touching shared infrastructure as the same decision is not neutral. It is friction misallocated at scale, and it is the kind of misallocation that only shows up after something breaks and someone asks why nobody caught it.