esc
Anthology / Yagnipedia / Pull Request

Pull Request

A Letter You Write to Yourself and Wait Seven Days to Read
Ritual · First observed GitHub (2008) — when the platform decided that merging code should require the same ceremony as a medieval land transfer · Severity: Retired (in some workflows), Sacred (in others)

A formal petition to merge one’s own code into one’s own codebase, submitted to a queue of unknown length, reviewed by parties of unknown availability, and approved — eventually — with seven words that could have been spoken seven days earlier.

Definition

A pull request (PR) is a mechanism by which a developer proposes changes to a codebase and requests that someone — anyone, really — review those changes and grant permission to merge them. The name is instructive: it is a request. Not a notification, not an announcement, not a fait accompli. A request. The developer has written the code, tested the code, believes the code to be correct, and is now asking for permission to use it.

This is the software equivalent of cooking dinner, setting the table, and then waiting for a notarized letter confirming you are allowed to eat.

History

The Before Times: Patches on Mailing Lists

Before GitHub existed, code review happened on mailing lists. A developer who wished to contribute to a project would generate a patch file — a diff in unified format — attach it to an email, and send it to the project’s mailing list with a description of what the patch did and why it was needed. Other developers would reply to the email with comments. The patch might go through several rounds of revision before being accepted or rejected by the maintainer.

This process was, by modern standards, charmingly primitive. It was also, by modern standards, startlingly effective. The Linux kernel — the single most critical piece of software infrastructure on Earth — still uses this process in 2026. Linus Torvalds reviews patches via email. The kernel ships on time. The world runs on it.

Nobody has proposed migrating the Linux kernel to GitHub Pull Requests. This is either because the email process works well enough or because the resulting CODEOWNERS file would require its own postal code.

GitHub and the Democratization of Review (2008)

GitHub launched in 2008 and introduced the pull request as a first-class concept. The insight was genuine and valuable: anyone could fork a repository, make changes, and propose those changes back to the original project. You didn’t need to be on the mailing list. You didn’t need the maintainer’s email address. You didn’t need commit access. You needed a GitHub account and an opinion about how the code should work.

This was, without exaggeration, revolutionary. It lowered the barrier to open-source contribution from “navigate a mailing list archive, figure out the patch format, survive the reply from a senior developer who has Opinions about whitespace” to “click Fork, make changes, click Pull Request.” The number of open-source contributors exploded. The quality of contributions varied. This was expected.

What was not expected — though perhaps should have been — was that the pull request would evolve from a mechanism for proposing changes into a ceremony for approving them. The PR was designed as a door. It became a checkpoint, then a gate, then a customs border with its own bureaucracy, its own officials, and its own inexplicable delays.

The Ceremony Industrial Complex

Required Reviewers and the CODEOWNERS File

At some point — the historical record is unclear on exactly when, though the spiritual date is “the day after the first security breach at a company that didn’t do code review” — organizations began requiring pull request approval before merging. Not suggesting. Requiring. The merge button would be physically greyed out until a sufficient number of humans had examined the code and declared it acceptable.

This gave rise to the CODEOWNERS file: a configuration file that maps directories and file patterns to the GitHub users who must approve changes to those paths. In theory, CODEOWNERS ensures that the person most knowledgeable about a piece of code reviews changes to it. In practice, CODEOWNERS ensures that a specific person receives four hundred review requests per week and becomes the bottleneck for the entire organization without appearing on any critical-path diagram.

Status Checks and the Pipeline

The approval of humans was, of course, insufficient. Machines must also approve. CI pipelines were added as required status checks: the code must compile, the tests must pass, the linter must be satisfied, the security scanner must find nothing alarming, and the coverage report must show a number that management finds psychologically comforting. All checks must pass. The merge button remains grey until every green checkmark appears in a row, like a slot machine that must show all cherries before paying out.

> THE MERGE BUTTON HAS TWO STATES:
> GREY, WHICH MEANS "NOT YET",
> AND GREEN, WHICH MEANS "NOT YET, BUT FOR DIFFERENT REASONS" 🦎

LGTM: The Seven Most Powerful Words

“Looks Good To Me.” Four words. Seven, if you count the ones implied: I have reviewed this code, I believe it to be correct, I accept responsibility for having said so, and I would like to get back to my own work now.

LGTM is, in the taxonomy of software culture, a benediction. It confers legitimacy. It transforms a proposal into an accepted change. It is the difference between code that exists in a branch and code that exists in production.

It is also, in practice, frequently typed by a reviewer who has glanced at the diff, confirmed it is not obviously catastrophic, and has a meeting in four minutes.

The industry knows this. The industry does not discuss it. The LGTM is a social contract, and like all social contracts, it functions only so long as nobody examines it too closely.

PR Templates: The Checklist of the Damned

Many repositories include a pull request template — a markdown document that auto-populates the PR description with a checklist of items the author must confirm:

Every box gets checked. Nobody reads the items. The template exists as a liability shield: we told them to test their changes; it’s not our fault they checked the box without doing it. It is the Terms of Service of code review — universally agreed to, universally unread.

The closest analogy in the physical world is the US Customs declaration form — the document presented at border control that asks, with admirable directness, whether you are entering the United States to engage in terrorist activities, espionage, sabotage, or genocide. The traveler checks “No.” The border agent accepts this. Everyone proceeds as though a person planning genocide would have been deterred by the checkbox, or would have at minimum felt a pang of administrative guilt while checking “No” dishonestly.

The PR checklist operates on the same principle. “I have not introduced any security vulnerabilities” is checked with the same reflexive certainty as “I do not seek to engage in espionage.” Both are accountability theatre — security measures that exist so that when something goes wrong, someone can point to a form and say “but they confirmed.”

Nobody has ever left a security vulnerability in a PR on purpose and checked the box anyway. Nobody has ever committed genocide and checked “Yes” on the customs form. The checkbox catches neither the honest mistake nor the deliberate act. It catches nothing. It exists to be checked.

The Bot Era

AI Review in Two Minutes, Human Review in Seven Days

In 2024, AI code review bots arrived. Services like Greptile, CodeRabbit, and others could analyze a pull request in seconds: reading every changed file, understanding the context, identifying bugs, suggesting improvements, and producing a detailed review that would take a human reviewer thirty minutes to write.

This created a situation that future anthropologists will study as a case of technological irony: a robot reviews the code in two minutes, produces twenty-seven actionable comments, and identifies three genuine bugs. The developer fixes everything within an hour. Then the pull request sits in a queue for seven days, waiting for a human to type “LGTM.”

The AI review is faster than the human review. The AI review is more thorough than the human review. The AI review finds bugs that the human review would miss. And yet: the merge button remains grey until the human speaks. Because the system requires human approval. Because we built the system to require human approval. Because we do not trust machines to approve code.

We trust machines to write code. We trust machines to review code. We do not trust machines to approve code. The distinction is entirely ceremonial.

The Caffeinated Squirrel, upon observing this arrangement, immediately proposed a ReviewOrchestrationPipeline — a system in which AI reviews are automatically escalated to human reviewers based on confidence scores, with an SLA dashboard, a Slack integration, a weekly digest email, and a gamification layer that awards badges to prompt reviewers. “We could call it LGTM-as-a-Service,” the Squirrel suggested, vibrating at a frequency that was technically audible but spiritually exhausting. The proposal included seventeen microservices and a GraphQL API for querying review velocity metrics.

Nobody adopted it. Several companies independently built it anyway.

The Volumio Incident

A Case Study in Bottleneck Identification

On May 29, 2025, riclib submitted a pull request to the raycast/extensions repository. The PR, numbered #19504, added a Raycast extension for controlling Volumio, an open-source music player for audiophiles. The extension was called volumio-control. It was approximately two hours of work.

What followed was an exercise in understanding where bottlenecks actually live.

May 29, 19:59 — PR opened. The extension was complete: browse music, control playback, manage playlists. Eighteen files. A clean implementation by a developer who had built it because he wanted to control his music from Raycast.

May 29, 20:22 — Twenty-three minutes later, Greptile, the AI review bot, posted its review. Twenty-seven comments across eighteen files. The bot found real issues: the shuffle logic had a bug where toggling shuffle would set it to the wrong state. There were console.log statements left in production code. Error handling was missing showFailureToast in several async functions. These were legitimate findings. The kind of findings a senior reviewer would make if they had the time to read eighteen files carefully, which they did not, because they had four hundred other PRs in their queue.

May 29, 21:33 — riclib fixed everything. Every comment addressed. Every bug corrected. He pinged the bot for a re-review.

May 29, 21:39 — Six minutes later, Greptile reviewed again. Four more comments across twelve files. Minor suggestions. The code was, by any reasonable standard, ready.

Then: silence.

Seven days of it. The kind of silence that transforms a notification badge from a number into a reproach.

June 5, 05:54 — A human reviewer appeared. The review, in its entirety: “Hi. Looks good to me, approved.”

Seven words. An emoji of a waving hand. An emoji of fire. The sum total of human intellectual contribution after seven days of waiting.

June 5, 05:59 — Merged. Five minutes after approval.

The Arithmetic

Let us do the math, because the math is instructive:

The bottleneck was never the code. It was never the review. It was never the quality. The bottleneck was a human’s calendar.

> riclib: "Two hours to build it. Seven days to get someone to say 'looks good.' Never again."

riclib considered never contributing a public extension again. The calculus was simple: the PR process cost more time than the code. Not in effort — the effort was trivial on both sides — but in elapsed time, which is the only currency a solo developer cannot manufacture.

He started building just for himself. If the world wanted a Volumio extension for Raycast, the world could build its own.

How riclib Retired the Pull Request

The retirement was not dramatic. There was no manifesto. There was no blog post titled “Why I Stopped Using Pull Requests” with a Hacker News comment thread of eight hundred replies. There was a quiet decision, made on an ordinary day, to stop asking himself for permission.

Four AI agents push to master. No PRs. No reviews. No waiting. No ceremony. The code is written, tested, and pushed in a single motion, the way a carpenter drives a nail without first submitting a Nail Installation Request to a review board.

> riclib: "Four agents. One branch. `git push`. That's the review."

The “review” — insofar as the word still applies — is riclib watching lazygit as commits land. He sees the diffs in real time. He reads them if they look interesting. He doesn’t read them if they don’t. The agents all read CLAUDE.md. They follow the same coding standards. They run the same tests. The quality gate is not a human typing “LGTM” — it is a shared understanding of what the code should look like, encoded in a file that every agent reads before writing a single line.

git push IS the review. The ceremony dissolved because the trust problem dissolved. The trust problem dissolved because the agents are not strangers on the internet — they are extensions of the developer’s intent, running on his machines, reading his instructions, following his standards.

> PULL REQUESTS SOLVED A TRUST PROBLEM.
> REMOVE THE TRUST PROBLEM
> AND THE CEREMONY HAS NO PURPOSE.
> IT PERSISTS ANYWAY, OF COURSE.
> CEREMONIES ALWAYS DO 🦎

The Philosophical Question

A pull request is a request for permission to merge. Permission implies distrust. Not malicious distrust — organizational distrust, the kind that says “I believe you are competent, but I believe more strongly in the value of a second pair of eyes.” This is reasonable. This is healthy. This is how teams of strangers build software together without producing catastrophes more than occasionally.

But consider the solo developer with AI agents.

Who is the pull request addressed to? Yourself. Who reviews it? Yourself, or your agents, who are yourself-by-proxy. Who approves it? Yourself. Who merges it? Yourself.

The pull request, in this context, is a letter you write to yourself, place in an envelope, address to yourself, mail to yourself, wait seven days to receive, open, read, nod approvingly, and file. Every step is real. Every step is performed. No step is necessary.

The PR was a bridge between two minds that disagreed about code. When there is only one mind — distributed across four agents but unified in intent — the bridge connects a place to itself. You can still walk across it. You can admire the engineering. But the river it spans has been filled in, and you are walking across a bridge over solid ground, out of habit, because you have always walked across a bridge here.

Some developers will always need pull requests. Teams of fifty humans with varying skill levels, working across time zones, on a codebase with compliance requirements — yes. Pull requests. Required reviewers. CODEOWNERS. The full ceremony. The ceremony exists for a reason, and the reason is that strangers cannot read each other’s minds.

But if your agents can read your CLAUDE.md, and your CLAUDE.md contains your mind — your standards, your patterns, your preferences, your architectural decisions — then the agents can read your mind. And the pull request becomes what it always secretly was: not a technical mechanism, but a social one. Remove the social problem, and the mechanism has no purpose.

The bottleneck was never the code. It was the calendar.

See Also

See Also