--- title: "Why I Dropped Pull Requests on a Repo Only My Agents and I Touch" canonical: https://dxdev.com/blog/2026-08-22_why-i-killed-the-pr-model/ datePublished: 2026-06-01 --- On June 1, I deleted a pull request trigger from a repository where no human reviewer was ever going to use it. A few weeks earlier, I 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 I 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 test uncovered a dead event, not a broken workflow. ## The review that did not exist This repository is touched by my agents and me. That is not how every repository in our partnership works. We maintain other production systems with shared ownership, staff, and real human review. But here, a pull request was not a handoff between an author and a reviewer. It was an event I 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. I assigned work to an agent, inspected the change and its evidence, then accepted and committed it. There was no separate reviewer waiting 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 no longer meaningful pieces 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. ## I considered keeping it The easy choice was to leave the PR machinery in place. The workflows were already written, and their presence looked disciplined. The hidden cost 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. I also could have retained branch protection and made every agent change take the long route. That would have preserved a familiar shape, but it would not have added an 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 is not removing scrutiny. It means putting scrutiny where it actually occurs. In this repository, I 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 I adopted a no pull request model, recorded it in ADR 0001, removed the protections and dead gates, and updated the shared reference material. I 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 would have 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 does not have a human reviewer on the other side of a pull request. Pretending otherwise creates ritual, not a control. I now treat the question as architecture: who actually reviews this change, when do they see it, and what evidence do 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 my own acceptance decision, make the direct path explicit and keep the checks on that path. The useful guardrail was not the PR trigger. It was admitting that it had become dead code.