Pull Requests Are for Humans  🔗 **Source:** [Pull Requests Are for Humans](https://journal.rmccue.io/498/pull-requests-are-for-humans/) > [!note]+ Document Notes > --- > tags: [code-review, pull-requests, ai-assisted-development, open-source, engineering-culture, developer-experience] > author: Ryan McCue (rmccue) > source: journal.rmccue.io > reference: https://journal.rmccue.io/498/pull-requests-are-for-humans/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > --- > # 🏷️ Title: Pull requests are for humans > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Pull requests are for humans — Ryan McCue](https://journal.rmccue.io/498/pull-requests-are-for-humans/) > - [WordPress REST API](https://developer.wordpress.org/rest-api/) — McCue's core project context > - [Human Made / Altis](https://altis-dxp.com/) — where the post was originally written internally > ## 📝 Summary > - **What happened.** Ryan McCue, a longtime WordPress core contributor and Human Made engineer, published an internal essay arguing that pull requests and code reviews are fundamentally human-to-human interactions, and that offloading the description, review, and back-and-forth to AI degrades what reviews are actually for. > - **Why it matters.** Code review isn't only a quality gate; it's a primary channel for building and sharing engineering knowledge across a team. Automating the human parts strips that value and reduces engineering to a "code factory" — the one part AI already does well. > - **Key stakeholders.** Reviewers (whose time gets wasted), authors (who lose the growth benefit), open-source maintainers (who volunteer their time), and engineering teams whose shared knowledge depends on real discussion. > - **Risks and tradeoffs.** Delegating review to AI frees time in the short term but erodes trust, feedback loops, and the reviewer's willingness to invest. In open source, it shifts unpaid burden onto volunteers. > - **Bottom line.** Use AI to write code if you like, but keep humans in the loop for the descriptions, the reviews, and the discussion. Feeding a volunteer reviewer's comments straight into an agent isn't just inefficient — it's rude. > ## 📖 Main Content > - **Core distinction: code vs. communication.** McCue separates AI writing *code* (which he does himself and doesn't object to) from AI writing the *descriptions, comments, and reviews* around that code. The former is a tool; the latter replaces a human conversation with an automated one. > - **Reviews are multi-purpose.** The obvious goal is code quality. The important secondary goal is knowledge transfer — reviews are one of the primary ways a team builds and shares engineering knowledge. Feedback loops drive improvement, and PRs are where feedback gets integrated directly into work. > - **The "interacting with someone's agent" problem.** McCue reports a growing experience of reviewing PRs where he feels he's talking to a person's agent indirectly, not the person. This wastes everyone's time and feels demoralizing: "why bother investing into properly reviewing if no one's really listening?" > - **Three pernicious manifestations:** > - *AI-generated PR descriptions* — they summarize what's already visible in the diff. A reviewer can get that from their own agent. What a description should carry is the *decisions* and *context* not in the code: why this approach, how it fits the broader project, how it affects user behavior. > - *The unfiltered AI-to-PR pipeline* — features go straight from prompt to PR with no human involvement, creating pure burden on the reviewer. Far more common in open source than internal projects. > - *Feeding review comments into an agent* — much of review is engineering discussion: checking trade-off assumptions, questioning approaches, probing edges. McCue expects feedback to be *explained or dismissed*, not necessarily actioned. Piping comments to an agent introduces a "false certainty" the feedback never intended. > - **The systemic cost.** These behaviors degrade the review process, undermine the engineering itself, and push teams toward being "code factories." > - **The open-source escalation.** When a volunteer donates time to review your PR, using AI to generate the PR and handle the back-and-forth is "outright rude." This is the essay's sharpest normative claim — a move from efficiency argument to ethical argument. > - **Contested / uncertain points.** The piece is an experience-based opinion, not a study. "Feels terrible," "waste of time," and "rude" are asserted from the author's vantage, not measured. Reasonable counterpoints (AI-drafted descriptions a human then edits; accessibility benefits for non-native English contributors) aren't engaged. > ### 🗒️ Notes > - The framing "pull requests are for humans" is the load-bearing thesis: PRs are a communication medium, and their value collapses when both ends are automated. > - McCue explicitly excludes AI-written code from criticism — this keeps the argument narrow and harder to dismiss as anti-AI. > - The knowledge-sharing point is the strongest and least obvious: quality can theoretically be automated, but *team learning* only happens through real human exchange. > - "False certainty" is a precise idea — review comments are often probes or invitations to discuss, not directives. An agent treats every comment as a change request, flattening nuance. > - The escalation ladder is deliberate: descriptions (mild) → unfiltered pipeline (egregious) → feeding back the review (subtle but corrosive) → open-source volunteer abuse (rude). > - Distinction between internal repos and open source recurs twice — the unfiltered pipeline and the "rude" charge both land harder in OSS where reviewer labor is unpaid. > - Tone is measured, first-person, and appeals to shared professional norms rather than rules or policy. > ## 📚 References > - [Pull requests are for humans — Ryan McCue](https://journal.rmccue.io/498/pull-requests-are-for-humans/) > - [WordPress REST API Handbook](https://developer.wordpress.org/rest-api/) > - [Altis DXP (Human Made)](https://altis-dxp.com/) > - [The WordPress contributor handbook — code review norms](https://make.wordpress.org/core/handbook/) > ## 🗣️ Paraphrase > - AI use has surged, and with it a wave of PRs whose descriptions, comments, and reviews — not just the code — are machine-written; but writing PRs and comments is humans interacting with each other, and engineering work ultimately comes back to being human. > - Reviewing lately can feel like dealing with someone's agent by proxy instead of a person, which wastes time and feels awful, because a reviewer who suspects no one is listening has no reason to invest. > - Reviews serve two goals: ensuring code quality, and — importantly — building and sharing engineering knowledge across the team through feedback loops; a reviewer will happily spend time on that when it grows the team, but not when the counterparty is an agent. > - Three failure modes recur: AI descriptions that just restate the diff instead of the decisions and context; unfiltered prompt-to-PR pipelines with no human involvement that burden reviewers; and piping review comments into an agent, which imposes a false certainty the feedback never meant. > - Together these degrade review, undermine real engineering, and turn teams into code factories — the very thing AI is good at — and in open source, making a volunteer reviewer handle your AI's back-and-forth is outright rude. > ## 📰 Newsletter > Ryan McCue (WordPress REST API lead, Human Made) has a short, sharp essay worth passing to any team debating "how much AI in our PRs?" His line: write code with AI if you want, but pull requests are for humans. The description should carry the *why* — the decisions and context the diff can This is a post I originally wrote internally at [Human Made](https://humanmade.com/), but I think is worth sharing publicly. Both in private repositories and in open source repositories, there’s been a huge rise in the use of AI as LLMs have become more powerful. While many of us are using AI constantly to write code (myself included), there’s also been a large rise in pull requests generated partially or entirely with AI – that is, the descriptions, comments, and reviews, rather than the code. When we’re writing pull requests and comments, we are humans interacting with each other. Although we might be working on automating chunks of what we do, our engineering work still comes back to being human. In quite a few pull requests recently, I’ve had an experience of feeling like I’m just interacting with someone else’s agent indirectly, rather than with a person. Not only is this a waste of time for everyone involved, it also *feels* terrible to be on the receiving end of – why bother investing into properly reviewing if no one’s really listening? Reviews have always been a multi-pronged tool, with a few related but separate goals. The obvious one here is to ensure the quality of the code we’re shipping. However, an important secondary benefit is that it is one of the primary ways we build and share our engineering knowledge across the team. Feedback loops are vital for any sort of improvement, and pull requests are a way in which we *directly* integrate feedback into our work. As a reviewer, I don’t mind investing a lot of time into writing code reviews, because it’s a way for us to grow as a team. When I’m just interacting with someone else’s agent though, that’s clearly not worth it. This creeping pervasiveness of delegating to AI manifests in a few pernicious ways: * AI-generated pull request descriptions – These descriptions regurgitate and summarise what’s already in the code tab of the pull request. If I needed a summary of the changes, I can *already* ask my own agent to do that for me – what I want to see in a pull request is the decisions made in the pull request and other context not included in it. *Why* did you pick a certain approach? What does it look like in the broader project context? How does this affect user behaviour? * The unfiltered AI-to-PR pipeline – The most egregious case of this is the unfiltered pipeline where features go directly from a prompt into a pull request. In almost every case, these have had no human involvement, and act to just create a burden on the reviewer or project. (This is much more the case in the open source world than our internal projects.) * The back-and-forth of a review – Aside from the most obvious cases, much of review comes down to *engineering* discussion – checking trade-off assumptions, questioning approaches, and probing the edges. I *expect* a bunch of feedback to be explained or dismissed rather than necessarily causing a change, as we collaborate towards a shared understanding. Feeding those comments directly into an agent introduces a false certainty that isn’t intended in the feedback. These aspects all contribute to a degradation of the review process and drastically diminish the point of doing pull request reviews at all. They also undermine the actual engineering that we’re doing, moving us closer towards being code factories – which is exactly the part that AI *can* do well. Abdicating our review process to AI is tempting to free up our time, but ultimately harms the overall process and the value we’re bringing as engineers to our projects. In the open source space in particular, when someone is volunteering their time to review your pull requests, using AI to create pull requests and handle this back and forth goes beyond degrading this process – it’s outright rude., Pull Requests Are for Humans, journal.rmccue.io, 01kwf0m3gr6s92zrgvf4pxxejf.