Back to news

Why are projects disabling pull requests for AI-generated code?

Short answer: two different reasons are closing that door, and they need opposite responses from you. The first is review cost: the denoland/celld repository disabled pull requests entirely, and its README says coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves. The second is legal provenance: the QEMU project declines contributions believed to include or derive from AI generated content, because the copyright status of that output is unsettled. You fix the first by sending a smaller, focused patch. You cannot fix the second by writing better code.

What did the celld repository actually disable?

The celld repository, published under the denoland organization on GitHub, had 3,166 stars and 101 forks when we read it on August 12, 2026. Its README carries a section called Contributions with this text, quoted verbatim:

Pull requests are disabled. Coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves. Thoughtful contributions are welcome; please understand the code, keep the patch focused, and respect the review time you are asking for.

Two things make this more than a rant in a text file. First, the behaviour matches the declaration: the GitHub REST API reports pull requests as unavailable for that repository and returns 404 on its pull requests endpoint, while a repository with the feature on answers normally. Second, the text is not a reaction to a bad week. It was already in the README of the first published version, on August 2, 2026, and it was still there on August 12, 2026.

Read the wording closely, because it is narrower than the headline suggests. The celld README does not ban AI, and it does not ban you. It says thoughtful contributions are welcome, and it asks for a different delivery format: a git format-patch attachment sent to the project's contact address. What was rejected is the economics of the pull request button, where sending costs one click and reviewing costs an afternoon.

Is the QEMU ban the same thing?

QEMU closed a different door, and confusing the two will send you looking for the wrong fix. The QEMU developer documentation page on code provenance, read on August 12, 2026, states its policy in capital letters:

Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.

The reason QEMU gives has nothing to do with patch size. It is the Developer's Certificate of Origin: a contributor has to certify that they understand the copyright and license status of what they are submitting, and with AI content generators that status is, in the project's own words, "ill-defined with no generally accepted, settled legal foundation". The same page carves out an exception that is easy to miss, and it is worth quoting rather than summarising: "This policy does not apply to other uses of AI, such as researching APIs or algorithms, static analysis, or debugging, provided their output is not included in contributions."

So the practical difference for you is total. At celld, a smaller and better explained patch is welcome. At QEMU, no amount of patch discipline helps, because the objection is to where the text came from, not to how much of it there is. Checking which of the two you are facing takes one minute of reading the project's own documents, and it decides whether you should improve the patch or not send it at all.

How large is a change that AI coding agents actually produce?

We measured our own repository, which is a useful sample precisely because it is an extreme one: this website is written by AI coding agents working in parallel git worktrees. Reading the full history on August 12, 2026, there are 251 non-merge commits made between July 18 and August 10, 2026. The median commit changes 86 lines. The 90th percentile changes 987. The largest changes 17,718 lines.

That largest commit is not agent work, and neither is the second largest. "Set up a fresh Laravel app" (17,718 lines) and "Install Laravel Boost" (6,275 lines) were made 45 seconds apart on the first day, and both are a package installer writing files, not anyone solving a problem. We can separate the two categories with more than a guess, because every commit made inside an agent session in this repository carries a Claude-Session trailer in its message. 214 of the 251 commits, 85%, carry it, and neither of the two largest does. Counted by line rather than by commit the share is lower, 70%, and most of the gap comes from those two setup commits.

Restricting the measurement to those 214 agent-session commits moves the numbers less than you would expect, and that is the finding. The median becomes 91 lines, the 90th percentile 920, and the largest single agent delivery in this project's history is 4,007 lines. The share of oversized deliveries barely moves: 21.1% of all commits change more than 500 lines (53 of 251), against 21.0% of the agent ones (45 of 214). Those are two close fractions rather than one number, but they are close enough to say that filtering the human bootstrap out does not rescue the tail, because the tail is not the bootstrap.

Across the full history the concentration is severe: the ten largest commits carry 43% of every line ever changed in the project, while the smaller half of all commits carries 3%. In other words, the typical delivery from an AI coding agent is perfectly reviewable, and the tail is where the maintainer's afternoon goes. A policy written against that tail will also hit your reasonable patches, which is exactly what happened at celld.

Run the same measurement on your repository with one command:

git log --no-merges --pretty=tformat:'@' --numstat \
| awk '/^@/{if(n)print s; s=0; n=1; next} {s+=$1+$2} END{if(n)print s}' \
| sort -n \
| awk '{v[NR]=$1; t+=$1; if($1>500) big++} END{
    for(i=1;i<=int(NR/2);i++) half+=v[i]
    for(i=NR-9;i<=NR;i++) top+=v[i]
    printf "commits: %d\nmedian: %d\np90: %d\nlargest: %d\nover 500 lines: %d (%d%%)\ntop 10 = %d%% of all lines\nsmaller half = %d%% of all lines\n", NR, v[int(NR/2)], v[int(NR*0.9)], v[NR], big, big*100/NR, top*100/t, half*100/t}'

The numbers above are the exact output of that command on our repository, and the agent-only slice is the same pipeline with --grep='Claude-Session' added to the git log. It counts added plus deleted lines per commit, ignores merge commits, and treats binary files as zero, so a repository full of images will read smaller than it feels. On a repository with exactly one commit the median and the p90 both print as zero, because the index the script uses has no second position to point at and awk reads an uninitialised value as zero; from two commits on it prints real numbers, and it stops being a coarse guess somewhere in the dozens.

How do you send a patch when pull requests are disabled?

git format-patch is the answer, and it is older than the pull request. It turns each commit on your branch into a file that carries the diff, the commit message, the author and the date, which is everything a maintainer needs to apply your work with attribution intact. The sequence, tested on a throwaway repository before publishing:

git switch -c my-change
# work, then commit normally
git format-patch main

That writes one file per commit, named 0001-your-commit-subject.patch, in the current directory. Attach them to the address the project asks for, in order. If the project uses a mailing list, git send-email 0001-*.patch does the sending without your mail client mangling whitespace, which is the classic way a patch arrives unusable. On the other side, the maintainer runs git am 0001-your-commit-subject.patch and your commits land in their history with your name on them.

One habit worth taking from this even when pull requests are open: before you ask anyone to review anything, run git diff --stat main...HEAD. That prints the size of the favour you are about to ask for. Seeing "47 files changed" before the maintainer does is the cheapest review you will ever get.

How do you keep an agent's change small enough that someone will review it?

The phrase to take from the celld README is low-context change, not large change. A 900 line patch that does one thing and explains itself is easier to review than a 200 line patch that touches nine unrelated files, and AI coding agents are very good at producing the second one by accident. Four habits that keep the delivery reviewable:

  • Say what not to touch. Naming the files and directories that are out of scope in the prompt removes most of the accidental bulk, because the agent will otherwise tidy what it passes by.
  • Split mechanical from meaningful. A rename or a reformat goes in its own patch, so the reviewer can skim it and spend their attention on the commit that changes behaviour.
  • Ask for one front at a time. A large task produces a large delivery that is slow to check and hard to reject, which leaves the reviewer choosing between accepting a block they did not read and asking for everything again.
  • Write the message yourself, or check it line by line. The commit message is the context the maintainer is missing, and it is the part an agent has the least evidence to write, because it never saw the discussion that motivated the work.

We wrote separately about the other side of this table, how to review code written by AI agents when you are the one receiving, and about merging work from multiple AI coding agents inside your own repository. This article is about the third case, which is delivering into someone else's.

Should you disclose that an AI coding agent wrote the patch?

Where the project states a policy, the answer is decided for you, and QEMU is the clear case: submitting agent-written code there without saying so means certifying something under the Developer's Certificate of Origin that you are not in a position to certify. Where no policy exists, disclosure is still the cheaper mistake. A maintainer who finds out later reads it as a contributor who wasted their review time on purpose, and that judgement attaches to your name, not to the tool.

There is a practical argument on top of the ethical one. Telling a maintainer that an agent produced the patch and that you verified specific parts of it tells them where to look, which makes the review faster and your patch more likely to land. The disclosure that helps is specific: which parts you tested, which you read closely, and which you are least sure about.

What this article does not settle

Two projects are two projects, not a trend. We found celld and QEMU by following a Hacker News discussion and then reading each project's own documents, which is enough to prove the practice exists and to show that the same closed door has two unrelated causes, but it is not a survey, and we have no count of how many repositories have done the same.

Our own numbers carry a limitation worth stating precisely. The Claude-Session trailer marks the session a commit was made in, not the authorship of each line, and a person can type inside an agent session. So the 214 commits are agent-session output rather than proof that an agent wrote every line in them, and no measurement of ours takes it further than that. The line count is also a proxy for review effort rather than review effort itself. A 40 line change to a payment path deserves more attention than a 900 line change to a translation catalogue, and no percentile knows that.