--- title: "Our v2 Prototype Had Branch Protection and No Reviewer" canonical: https://dxdev.com/blog/why-i-killed-the-pr-model/ datePublished: 2026-06-01 --- On June 1, we deleted a pull request trigger from a repository where no human reviewer was ever going to use it. A few weeks earlier we had built the full ceremony because it looked like the responsible default. Branch protection. A pull request size budget. An LLM diff review workflow. A request for reviewers. The repository was a fresh v2 prototype, and we wanted the guardrails in place before the first serious change landed. Then a production setup ticket required runtime proof of those workflows. The acceptance check was precise: push an oversized pull request and confirm that `pr-size-budget.yml` and `llm-diff-review.yml` fired and annotated it. ## The review that did not exist This repository is touched by our agents and us. That is not how every repository in our partnership works. We maintain other production systems with shared ownership, staff, and real human review. Here, a pull request was not a handoff between an author and a reviewer. It was an event we would have to manufacture so a workflow could leave a comment on an object nobody needed. The conventional sequence is useful when it is real: work happens on a branch, a pull request opens, checks run, another person reviews, and a merge moves the change forward. Our actual sequence in this repo was different. We assigned work to an agent, inspected the change and its evidence, then accepted and committed it. No separate reviewer waited at the end of a queue. There was no second stream of human work that needed a merge boundary. An oversized pull request could have proven that GitHub Actions responds to a pull request event. It could not have proven that the repository had a review process. The setup ticket made that mismatch impossible to ignore. The maintenance surface was larger than one workflow. The pieces that no longer meant anything included pull request branch protection, gate workflows, and their triggers. The follow-up commit was small but deliberate: ```text .github/workflows/codeql.yml docs/adr/0001-repo-topology.md 10 insertions, 6 deletions ``` Static analysis still mattered. The pull request branch of the trigger did not. The ADR amendment mattered more. Removing an event from configuration changes behavior. Recording why the event no longer belongs in the operating model makes the decision reviewable later. ## We kept it, and it cost us The easy choice was to leave the PR machinery in place, and we did, for those weeks. The workflows were already written, and their presence looked disciplined. The price was that every meaningful change would need a synthetic pull request, a synthetic review event, and a fresh argument over whether an agent annotation was a gate or merely a note. We also kept branch protection and sent every agent change the long route. That preserved a familiar shape, but it added no independent set of eyes. Process weight is not free just because an agent performs most of the clicks. Someone still owns exceptions, stale branches, failed required checks, and the decision to override a gate. The opposite option was worse: declare direct work safe because agents touched it. That lost immediately. Removing a pull request model does not remove scrutiny. It puts scrutiny where it actually occurs. In this repository, we review the agent output and its evidence before accepting it. The checks that matter run on the direct delivery path, not only when a made-up pull request appears. So we adopted a no pull request model, recorded it in ADR 0001, removed the protections and dead gates, and updated the shared reference material. We stopped treating a pull request as proof that a review had happened. ## Match the boundary to the reviewer A pull request is a coordination primitive, not a review process by itself. It becomes valuable when it marks a real boundary: another person needs to inspect the change, several people need a durable discussion, a release manager needs an approval trail, or a protected branch needs a controlled merge. None of those boundaries existed in this repo. Keeping the PR machinery made the history look more formal while making the actual workflow harder to see. The ADR amendment is deliberately narrow. It does not say pull requests are obsolete, or that agents remove the need for human judgment. It says this repository has no human reviewer on the other side of a pull request. Pretending otherwise creates ritual instead of a control. For each repository, ask who actually reviews a change, when they see it, and what evidence they use to accept it. If the answer includes another person, a pull request may be the right boundary. If the answer is an agent workflow and our own acceptance decision, make the direct path explicit and keep the checks on that path. The useful guardrail was admitting that the trigger had become dead code.