Pull Requests Are for Humans - CourtneyR.dev's 2nd Brain

Pull Requests Are for Humans ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article4.6bc1851654a0.png) 🔗 **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't show — not a robot summary of the diff a reviewer could generate themselves. And piping a reviewer's comments straight into an agent? That treats a question ("did you consider…?") as a command, and quietly kills the engineering discussion that makes reviews a teaching tool, not just a gate. For WordPress folks living in open-source review queues, the closing line stings: making a volunteer reviewer babysit your AI's back-and-forth is "outright rude." Good prompt for a team norms conversation, a contributor-guide note, or a WordCamp hallway debate. ## ✅ Action Items #### DevRel - Developer advocacy: turn this into a talk or blog on "AI-assisted contribution etiquette" for WordPress and OSS audiences; measure via engagement and contributor-guide adoption. - Education: run a workshop on writing PR descriptions that capture decisions and context, not diff summaries. - Developer experience: add a PR template field prompting "Why this approach? Broader context? User impact?" to nudge human context. - Developer marketing: seed the "pull requests are for humans" framing in newsletters and social as a discussion hook. - Community management: draft guidance for handling unfiltered AI-to-PR submissions without discouraging good-faith AI-assisted contributors. - Internal/external/cross-project: align maintainer expectations on acceptable AI use across repos. #### OSPO - Policy & Governance: publish a contribution policy clause on disclosing and bounding AI use in PRs and reviews. - License Compliance: not applicable to this source — the essay concerns review culture, not licensing. - Security Management: flag that unfiltered prompt-to-PR pipelines can smuggle in unreviewed, unvetted code; require human sign-off. - Software Inventory: not applicable to this source — no SBOM/inventory angle. - Developer Support: offer maintainer consultation hours on triaging AI-generated contribution floods. - Community Engagement: fund or recognize reviewer labor explicitly, since the essay centers volunteer reviewer burden. - Strategic Alignment: add "review quality and knowledge transfer" as a KPI, not just merge throughput. #### Community - Maintainers: add a CONTRIBUTING note distinguishing acceptable AI-assisted PRs from unfiltered dumps. - Contributors: onboarding path teaching that a review comment may be a discussion prompt, not a change order. - Sponsors: fund reviewer time as first-class labor; report on review load in impact updates. - Ecosystem: coordinate cross-project norms so contributors meet consistent expectations. #### WordPress - Core: revisit contributor review norms in light of rising AI-generated PRs; set expectations in the handbook. - Core Performance: not applicable to this source — no performance content. - Core AI: define responsible-AI guardrails for AI use in the contribution/review workflow. - **Core Program Team:** add a retrospective item on AI's effect on review throughput vs. review quality. - Mobile: not applicable to this source. - Playground: build a teaching module reproducing a "good vs. bad AI PR description." - Community: run a WordCamp session on AI contribution etiquette. - Training: add a Learn WordPress lesson on writing decision-focused PR descriptions. - Marketing: amplify the human-in-the-loop framing. - Support: not applicable to this source. - Design: not applicable to this source. - Documentation: update the contributor handbook with PR-description and AI-use guidance. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: consider the accessibility angle — AI can help non-native English contributors write clear descriptions; balance against the essay's critique. - Accessibility: not applicable to this source — no WCAG content. - Meta: consider tooling signals (labels) for disclosed AI-assisted PRs on Trac/GitHub. - CLI: not applicable to this source. - Hosting: not applicable to this source. - Tide: not applicable to this source. - Openverse: not applicable to this source. - Themes: apply review-etiquette guidance to the theme review queue, a known volunteer bottleneck. - Plugins: apply the same to the plugin review team facing AI-generated submissions. #### The WPCC - Programs: fund maintainer stipends that explicitly value review and mentorship labor. - Projects: run a governance clinic on AI-contribution policy. - Funding experiments: pilot paying for review time to offset volunteer burden the essay describes. ### FAIR - Technical independence: not applicable to this source — no metadata/provenance content. - Policies and covenants: a contributor covenant could encode "disclose AI use, keep a human in the review loop." - Productized governance artifacts: a reusable "AI-assisted contribution" charter clause other projects can adopt. ## 🧪 Hypotheses - Teams that require decision-and-context PR descriptions (not diff summaries) show higher reviewer satisfaction and faster knowledge transfer than teams that allow AI diff-summary descriptions. - Open-source projects that receive unfiltered prompt-to-PR submissions see measurable increases in maintainer time-per-PR and higher reviewer burnout/attrition. - Feeding review comments directly into agents increases the rate of "over-correction" — changes made to comments the author intended as discussion, not directives. - Reviewers reduce review depth (fewer substantive comments) once they perceive the counterparty is an agent rather than a person. - Explicit AI-use disclosure norms increase reviewer trust and willingness to invest time, compared with projects with no disclosure norm. ### 📊 Methodology - Instrument PR platforms (GitHub/Trac) for time-to-review, comment counts, comment resolution type (actioned vs. explained/dismissed), and revision churn. - Survey reviewers pre/post a norm change on perceived counterparty (human vs. agent) and willingness to invest. - Controlled comparison: repos with a "decisions/context" template field vs. repos without; measure description quality via rubric scoring. - Longitudinal tracking of maintainer retention in projects with high vs. low volumes of unfiltered AI PRs. - Tag a sample of PRs by disclosed AI use and compare over-correction rates on discussion-type comments. ### ❓ Questions - Where exactly is the line between acceptable AI-assisted authoring (human edits the draft) and the "unfiltered pipeline" McCue condemns? - Can a PR description be AI-drafted yet still carry genuine human decisions and context if the human curates it? - How should projects treat good-faith contributors who use AI for language accessibility rather than to avoid engagement? - Does the "rude" framing scale to paid internal teams, or is the ethical weight specific to volunteer reviewer labor? - What tooling would let reviewers detect agent-in-the-loop back-and-forth without false accusations? ### 🔮 Future Research - Study knowledge-transfer outcomes of code review empirically — the essay asserts the benefit but it's under-measured. - Investigate "false certainty" as a failure mode: how agents map probing comments to change requests, and how to prompt them not to. - Explore disclosure-norm designs and their effect on trust and review quality. - Examine the equity angle: AI as an accessibility aid for non-native English contributors vs. its use to dodge engagement. ### 💡 Implications - **Practice.** PR descriptions should foreground decisions, trade-offs, and user impact — content the diff can't show. Review comments should be read as discussion, not directives, and authors should explain-or-dismiss, not blindly action. - **Policy.** Projects should codify AI-use expectations: disclose it, keep a human accountable for the review conversation, and reject unfiltered prompt-to-PR dumps. - **Security.** Unfiltered pipelines can merge unvetted code; human review sign-off remains a control, not a formality. - **Education.** Teach contributors that review is a learning channel; teach maintainers to triage AI floods without alienating legitimate AI-assisted contributors. - **Funding models.** Reviewer time is real labor, sharpest in open source; sponsors and OSPOs should fund and recognize it, especially as AI lowers the cost of *producing* PRs while raising the cost of *reviewing* them. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade ~11–13 (professional/general-technical prose, moderately long sentences, low jargon). Flesch Reading Ease roughly 45–55. #### 👀 Visual learners - Present: none — plain prose essay, no diagrams or code. - Improve: a simple diagram of the escalation ladder (description → pipeline → back-and-forth → OSS rudeness); a before/after PR-description example. #### 🔊 Aural learners - Present: the source is tagged "Pre-Thought Listen," suggesting an audio companion may exist. - Improve: a 2–3 minute narrated summary. #### 🗣️ Verbal learners - Present: strong — clear definitions by example (three manifestations), the "false certainty" coinage, plain analogies ("code factories"). - Improve: a short glossary (unfiltered pipeline, false certainty, feedback loop). #### 🧩 Kinesthetic learners - Present: none — no exercises. - Improve: a checklist for writing human PR descriptions; a "spot the AI diff summary" exercise. #### 🧠 Logical learners - Present: clear argument structure with an escalating list. - Improve: a decision tree for "is this an acceptable AI-assisted PR?" #### 🧑‍🤝‍🧑 Social learners - Present: implicit — the whole piece is about team interaction. - Improve: discussion prompts for a team retro. #### 🧘‍♀️ Solitary learners - Present: reflective first-person framing invites self-examination. - Improve: a journaling prompt — "when did I last pipe a review straight into an agent?" #### 🌿 Naturalistic learners - Present: none. - Improve: frame review as an ecosystem where reviewer attention is a scarce, renewable resource. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: single H1, a bulleted list, standard blog markup (assumed). - Improve: ensure list semantics and heading hierarchy are real HTML, not styled text. #### Keyboard navigation - Present: static article — minimal interactive surface. - Improve: ensure visible focus on nav/links. #### Contrast and readability - Present: unknown from text alone. - Improve: verify 4.5:1 body-text contrast on the journal theme. #### Text resizing and reflow - Present: unknown. - Improve: confirm reflow at 200% zoom. #### Media and captions - Present: a "Listen" affordance is implied; captions/transcript status unknown. - Improve: if audio exists, provide a transcript. #### Forms and interactions - Not applicable to this source — the article has no forms. #### Standards reference - Map any real gaps to WCAG 2.2 AA (1.4.3 contrast, 1.4.10 reflow, 1.2.x for any audio). ### 🌍 DEIB Assessment #### Cultural breadth - Present: none specific — general Western engineering-culture framing. - Improve: acknowledge global contributors for whom AI aids English-language participation. #### Inclusive language - Present: clear, jargon-light, gender-neutral. - Improve: define "unfiltered pipeline" and "false certainty" for newer contributors. #### Neurodiversity support - Present: short paragraphs, chunked list. - Improve: none major; structure is already predictable. #### Representation - Present: single author's perspective. - Improve: engage counter-perspectives, including contributors who rely on AI for accessibility. #### Psychological safety - Present: the "rude" charge risks shaming good-faith AI-assisted contributors. - Improve: pair the norm with a welcoming path for disclosed, human-curated AI use so the message deters the behavior, not the people. ## ✅ Logical Validity #### Strong reasoning - **Inductive (experience-based) — para. "In quite a few pull requests recently…":** McCue generalizes from repeated recent experiences of reviewing agent-driven PRs. Reasonable as a pattern claim; strengthen by quantifying frequency. - **Causal — reviews build shared knowledge:** the claim that automating the human side removes the knowledge-transfer benefit is a sound causal chain (no human exchange → no learning). Strengthen with study data. - **Analogical — "code factories":** apt analogy that isolates what AI does well (mechanical production) from what it doesn't (human discussion), reinforcing the thesis. Clarify by naming what specifically is lost beyond throughput. - **Definitional/distinction — code vs. communication:** cleanly separates AI-written code (accepted) from AI-written communication (criticized), which pre-empts the "you're just anti-AI" rebuttal. #### Fallacies - **Appeal to emotion / loaded language — "outright rude," "feels terrible":** persuasive but substitutes moral labeling for argument in the closing line. Fix: pair the ethics claim with the concrete harm (uncompensated volunteer time, eroded trust) so it rests on more than feeling. - **Hasty generalization (mild) — "In almost every case, these have had no human involvement":** a strong empirical claim offered without data. Fix: qualify or cite the observation base. - **False-dilemma tendency (implicit):** frames AI-in-review largely as abdication, under-weighting a middle path (human-curated AI drafts). Fix: explicitly carve out acceptable AI-assisted authoring. #### Tone of voice - Measured, first-person, professional, appealing to shared craft norms; escalates to moral seriousness only in the final sentence ("outright rude"). Reads as a colleague's earnest plea rather than a rant. ### 🛡️ DARVO Analysis - Not applicable to this source. The essay is a first-person opinion piece with no accuser/accused dynamic. McCue critiques a *practice*, not a person, and doesn't deny wrongdoing, attack a critic, or recast himself as victim. The only near-adjacent element is that he positions reviewers (including himself) as bearing a cost — but this is a straightforward burden claim, not victim/offender reversal. ## 🎯 Conclusion - **Bottom line.** Pull requests are a human communication medium. Automating the code is fine; automating the descriptions, reviews, and back-and-forth hollows out review's real purpose — quality *and* shared engineering knowledge — and in open source, dumping that on volunteer reviewers is rude. - **Next steps for readers.** Write PR descriptions that carry decisions and context, not diff summaries. Read review comments as discussion, and explain-or-dismiss rather than piping them into an agent. If you maintain a project, codify AI-use expectations and protect reviewer time as real labor. ## 🔄 Refactor Appendix — Pull requests are for humans > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. ### 📚 Literature Atoms (H3) #### [H1] Code review is a primary knowledge-sharing channel > [!quote] ID:rw_h1 > it is one of the primary ways we build and share our engineering knowledge across the team **Context & use**: - Para. beginning "Reviews have always been a multi-pronged tool…" - The essay's strongest, least-obvious claim: review value isn't only quality, it's team learning — so automating the human side removes a benefit AI can't replace. **Tags**: #xref **Highlight**: [view highlight](readwise://)  #### [H2] Feeding review comments to an agent fabricates false certainty > [!quote] ID:rw_h2 > Feeding those comments directly into an agent introduces a false certainty that isn't intended in the feedback. **Context & use**: - Para. on "The back-and-forth of a review." - Review comments are often probes or invitations to discuss; an agent reads every one as a directive, flattening nuance and forcing over-correction. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://)  #### [H3] Making volunteers handle your AI back-and-forth is rude > [!quote] ID:rw_h3 > using AI to create pull requests and handle this back and forth goes beyond degrading this process – it's outright rude. **Context & use**: - Closing paragraph, open-source specific. - Reframes the critique from efficiency to ethics: volunteer reviewer time is unpaid labor, and offloading engagement onto it is a moral, not just practical, problem. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://)  ### 🧠 Permanent Candidates (H4) #### [P1] Automating both ends of a review collapses its value **Claim** (one sentence, Courtney's voice): A code review only creates knowledge when at least one human is genuinely present on each side. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds where review is meant to transfer knowledge and build trust; weakens for purely mechanical lint/format checks that were always automatable. **Links**: - [[Human-in-the-loop review]] — because extends - [[Code factory antipattern]] — because contrasts on what-AI-does-well - [[Open-source maintainer burden]] — because applies-in volunteer contexts  ### ✏️ Fleeting Queue - [F1] Draft a PR-description template field: "Why this approach? Broader context? User impact?" — for WordPress/OSS contributor guides #fleeting #inbox - [F2] Open question: where's the line between human-curated AI drafts and the "unfiltered pipeline" McCue condemns? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a short "AI-assisted contribution etiquette" note for a WordPress contributor guide — DevRel #things - [ ] Add a decisions/context field to a PR template and pilot it on one repo — DevEx #things ``` Processed: Pull requests are for humans - Literature atoms: 3 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 2 - Things 3 actions: 2 / 2 cap - Konik tags used: [#xref, #articleseed, #aphorisms] - Triage callouts populated: [Cross Reference, Article Ideas] - Quality gates: [✓ verbatim quotes, ✓ atomicity, ✓ link annotations, ✓ YAML hygiene, ✓ Konik triage, ✓ diff readiness] - Override conditions triggered: none ```  📄 **Full text:** [[Full Document Contents/Articles/Pull Requests Are for Humans.md|Pull Requests Are for Humans by journal.rmccue.io]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01kwf0vhrtfgw1nsx2pfpc5h6d)) - Note: Review's hidden purpose: sharing engineering knowledge across the team, not just code quality - Tags: atom/literature/h1 - 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? ([View Highlight](https://read.readwise.io/read/01kwf10nq0j2x663msp9xc8x4d)) - - 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. ([View Highlight](https://read.readwise.io/read/01kwf0vm6rb1fxrqznfexm4qkq)) - Note: Piping review comments into an agent fabricates a false certainty the feedback never intended - Tags: atom/literature/h2 - 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. ([View Highlight](https://read.readwise.io/read/01kwf0vn5j15qawgat15wweh19)) - Note: Using AI on volunteer OSS reviewers is outright rude — the sharpest line in the piece - Tags: atom/zettel/z1