When patches get cheap, who pays for the review?

Two of free software's longest-running institutions are deciding, in the same season, whether machine-written contributions are a copyright footnote or a threat to the people who keep the projects alive. On emacs-devel, a group of developers wants the temporary ban on LLM-generated code made permanent, on the grounds that legality was never the real question. On LLVM's Discourse, maintainers are splitting the problem: leave AI-assisted code legal under a human-in-the-loop rule, forbid AI-written prose in pull requests and RFCs, and cap how many open pull requests a non-committer may hold. The through-line is the same. Generating a patch has become almost free. Reviewing one has not. The fight is over who absorbs that asymmetry.

Phil Hagelberg opened the Emacs thread on behalf of developers and users who like the current prohibition and fear it will not last. The policy, as they read it, exists to wait out uncertainty about whether LLM output can be copyrighted in a way the GNU project can defend. That, Hagelberg wrote, "overlooks the harm posed to users and communities by acceptance of LLM-generated code." The sharper line followed: "It would be a mistake to say that because something is legally allowable it must be acceptable." Free software, in this telling, "is more than just code. It's built on a foundation of trust and solidarity." Watching other projects admit the tools, the group sees trust corrode as soon as machine text is allowed in, and wants Emacs to learn from that rather than repeat it.

The maintainers answering them do not deny that patches will multiply. They deny that multiplication is, by itself, a reason to refuse a class of work unread. Kai Ma, who co-maintains a project that requires only "responsible use," reported more pull requests and "very mixed feelings": some make sense, many do not. The mechanism is simple. "I'm simply predicting that there will be more patches, (because they become very cheap)." A coding agent, given a bug description, can study the tree, edit it, and check that the symptom is gone, which is not the same as fixing the cause. Eli Zaretskii's reply was procedural rather than philosophical. If a patch does not make sense, reject it. The scarce resource on the Emacs bug list, he argued, has long been attention, not proposed fixes: the list "is routinely read only by the Emacs maintainers and not many other people." When Sean Whitton answered the automatic-responder scenario with "They definitely might!", Zaretskii's response was two words: "Bring them on!" People worried about burnout, he added, should consider coming aboard to review. Refusing a class of proposals unread, merely to lighten the queue, does not sit with him as a maintenance strategy.

Richard Stallman, in the same thread, pushed the ethical objection onto a different track. If the complaint is that model output rests on wrongful labor, punish the people who forced that labor, including by boycott where profit was the point. Do not, he argued, punish the public by rejecting a beneficial result the public did not commission: "A campaign to reject that beneficial thing would hurt only the innocent public." That is a steelman of openness that does not depend on believing the tools are harmless. It treats a ban as collective punishment for a production method, and it leaves the review-capacity question to the people who would actually read the patches.

LLVM has already lived with the liberal rule Hagelberg's group wants Emacs to avoid. Nikita Popov (nikic) described that policy as allowing essentially all AI use so long as a human stays in the loop and takes responsibility. Experience, he wrote, now justifies a narrower cut. The RFC does not touch allowable uses of AI for code. It proposes to "ban the use of AI-generated or substantially AI-assisted textual communication," including pull request descriptions and RFC texts. The motivation is concrete and unromantic. New contributors in particular are filing descriptions that are "extremely verbose," padded with routine testing notes and gratuitous formatting. Those texts "are a drain on our limited reviewer bandwidth," both because they take longer to read and because they need "substantial massaging" before they can be merged. There is a second, sharper claim: an AI-written description "deprive[s] the contributor of the opportunity to understand what a PR does by themselves, and express it in their own words." Under a human-in-the-loop model, that sentence is the sanity check. If the author cannot say what the change does, the loop was theater.

The project council has already read that RFC as having rough consensus. Alex Zinenko (ftynse), writing for the council after its November meeting, said the body "see[s] support for the intent of the policy which is to decrease the burden on maintainers," while admitting complex cases will need later adjustment. That is further along than Emacs, and it is also narrower: code may still be machine-assisted; the words around the code may not.

Reid Kleckner (rnk) wants a second, blunter instrument, and he is explicit that AI is why. After Nikita's RFC, a contributor-policy refresh, and hallway argument at the US LLVM developer meeting, "contributors, and especially maintainers, are tired of dealing with the overload of PRs." His proposal is pull request limits for people without write access. He started at the meeting ready to close every non-contributor pull request, slept on it, and landed on two open pull requests at a time. "This is a drastic action, but I think that's what the situation calls for." The door stays open for a few small fixes. What it closes is the pattern of a new account opening twenty pull requests at once, hunting for a reviewer willing to rubber-stamp small, functionally correct changes. Those fixes can be useful. They also clog the open-pull-request dashboard and, in his account, burn maintainers out. He hoped for a one-week consensus and a switch flipped before the 2 December project council meeting, with the number revisited next year.

The objections are about what "open" still means once the cap exists. Jessica Clarke (jrtc27) suggested counting only completely untriaged pull requests, with a committer label meaning "I believe that this is a well-intentioned non-extractive PR," so people playing by the rules are not throttled by their own patience. She doubted the label could be enforced as easily as a hard count. Others noted that GitHub's stacked-pull-request workflow already requires write access, so newcomers were never in that lane. The harder critique is cultural. A comment Kleckner and others were answering put it bluntly: with modern tools and GitHub, LLVM may not need more newcomers or lower barriers. "What we need is more people who stick around, become actual experts in an area of the code, and can then review other people's code." Andy Kaylor's version of that idea is a mentor who will put a name on the pull request and take responsibility for guiding the newcomer, with an explicit policy that maintainers may ignore the rest.

That cure recreates the disease. One contributor who has tried to work in unfamiliar parts of LLVM called mentorship "a great idea" in theory and then "just a different version of the same problem." Reviewers already lack bandwidth. Asking them to mentor instead of review "feels a bit counterintuitive." Opening a pull request, ironically, "often feels like a less demanding ask" than asking for ongoing guidance. A hard cap, or a mentor gate, can look from the outside like a project that has decided new people are the problem.

Quentin Colombet's dissent is the embrace position, stated and then deliberately not re-argued: "we seem to be stuck in a pre-AI world and whether we like it or not, this is the new reality." He would deploy the tools carefully and use them more, including automated review, an idea the community has already declined once in a separate RFC. Renato Golin's answer to the pile of overlapping proposals (communication bans, newcomer workflow, AGENTS.md, contributor-policy refresh, rate limits on bot-filed issues, the pull-request cap itself) is that community health "right now, is not great," that any ruling will be imperfect, and that the project council should start making harder decisions anyway. Decisions, he noted, can move later. Nothing here is set in stone.

Where it stands is uneven, and unresolved in the way that matters. Emacs still has a temporary, copyright-shaped ban, a public demand to make the ban permanent for reasons of trust, and a lead maintainer who would rather review the flood than define a class of patches as unreadably illegitimate. LLVM's council has signaled support for banning AI-generated communication while leaving code policy liberal, and a separate, not-yet-adopted proposal would ration the queue by contributor status rather than by content. Neither project has settled whether a functionally correct patch from someone who will not stick around is a gift or a tax. The tools that made the patches cheap are not waiting on that answer.