The pull request has always been the place where every concern about a change converges. Tests run. Linters run. A reviewer reads it. Someone clicks merge. For most of the history of this practice, the PR was treated as a light, conversational artifact: a place to talk about a change before it lands.

That was fine when the throughput of changes was set by humans. With agents in the contributor pool, the PR has to do more work. It is no longer the casual handoff between author and reviewer; it is the last point before a change enters the system where every quality concern can still be enforced. It is, in the strict sense, a checkpoint.

Most teams have not updated their PR practice to match.

What "load-bearing" means here

A PR is load-bearing when the system trusts it to be the place where standards are enforced. The required checks have to actually represent the standards. The template has to actually surface the questions a reviewer needs to answer. The merge rules have to actually prevent the bad cases.

In a human-throughput team, the PR could afford to be lightly specified because the cost of a bad merge was bounded by how many bad merges humans could produce in a day. In an agent-throughput team, the PR is the gate between a high-volume change source and production. The cost of a vague PR practice is a steady stream of changes that pass the checks without passing the bar.

The fix is not to make review harder. The fix is to make the PR itself encode more of the bar, so that what reaches a reviewer is already pre-filtered.

The template

A good PR template is a forcing function for the author (human or agent) to answer the questions a reviewer would otherwise have to ask. A bad template is a wall of headers that everyone fills with "N/A" because nobody has the energy to enforce it.

The difference is in what the template asks for. Headers like "Description" and "Changes" are weak: the diff already says what changed. Headers that earn their place ask the questions the diff does not answer:

What problem does this solve, in one sentence, written before the change? Catches the case where the solution drifted from the original problem during implementation. Especially useful for agent-authored PRs, where the implementation can wander.

What is the scope of this change? What files or modules did you intend to touch? The author commits to a scope before the diff is reviewed. A diff that exceeds the stated scope is a signal, not an automatic block.

What did you not test, and why? Forces an explicit gap rather than implicit silence. A blank answer is fine; "I tested the happy path; failure modes are out of scope for this PR" is much better than the absence of the question.

How would someone verify this works in production? Often catches changes that pass tests but produce nothing observable when they break in the wild.

These questions are not bureaucratic. They are the questions a senior reviewer would ask if they had the time, made cheap by being asked once in the template instead of separately on every PR.

Required checks

The set of automated checks that run on every PR has to actually represent the standards the team cares about. This is harder than it sounds because the natural drift is for checks to accumulate, become slow or flaky, get marked optional one by one to keep the pipeline green, and eventually stop blocking anything.

A few principles for keeping the check list load-bearing:

Every required check must reliably fail when it should. A check that flakes one in twenty runs trains the team to ignore it, which means it is no longer a check. Either fix the flake or remove the check; do not leave it as a known-bad gate.

Fast checks run on every PR. Slow checks run, but not as blockers; instead, they post a status that surfaces in review. The reviewer can decide whether to wait for the slow check before merging based on the risk of the change.

Checks that catch entire categories of bugs are worth more than checks that catch one. A type checker catches a class of error on every change forever. A test that pins down one specific regression catches one specific regression. Both are useful; the type checker is the better investment of harness budget.

When a new failure mode is discovered, the question to ask is "what check would have caught this?" If the answer is "a check we do not run," that is a candidate check to add. The pipeline gets smarter through deliberate investment.

Merge rules

Who can merge, when, and with what override authority is a policy decision that most teams inherit from defaults and never revisit.

The defaults are not adequate for agent-authored work. "One approval, all checks green, anyone can merge" is fine when every PR is hand-crafted by a teammate who is going to be on call when it breaks. It is less fine when the PR was generated overnight by an agent and the human author has not yet looked at the diff carefully.

A few rules that hold up under agent throughput:

The human who is going to be responsible for the change has to approve it. Not just the agent that produced it, not just any reviewer who happened to be available. Someone whose name will appear in the post-mortem if this breaks.

Override authority is real, but rare, and logged. There are genuine reasons to merge without a green check, such as a hotfix, a flake that has been investigated, or a pre-arranged exception. None of those reasons should be invocable silently. If the system allows overriding a check, the override should produce an artifact the team can see.

Merging is the final action, not a default. "Auto-merge when checks pass" is a useful feature for low-risk changes and a dangerous one for everything else. Reserve it explicitly; do not make it the path of least resistance.

The PR as audit trail

The last property worth naming: a load-bearing PR is also an audit trail. When something breaks in production six months from now, the PR is the place an investigator goes to understand what changed and why. The template answers, the review comments, the check results, the merge decision; all of it is the record.

This matters more, not less, with agents. The human memory that used to compensate for thin PRs ("oh yeah, I remember writing that, I knew about the edge case") does not exist for an agent-authored change. The PR is the only record of intent. Whatever future-you would want to find there has to be there now.

The PR is no longer just where you talk about a change. It is where you commit to it, in writing, in front of the system. Treat it that way.