Linux Foundation says 25% of pull requests are AI slop; the figure is a mean of banded answers from 111 maintainers

A quarter of pull requests, from 112 banded answers

The Linux Foundation's research report on generative AI and open source, announced on 20 October 2026, says an average of 25 percent of incoming pull requests are "AI slop", and 31 percent on large projects. Both numbers answer one survey question. The Linux Foundation's own published survey frequencies show that 135 maintainers answered it. Twenty three of them said they did not know. The other 112 picked a band between 0 and 100 percent, and 68 of those 112 (derived) picked 0 percent or the 1 to 20 percent band. The report's 25 percent is the mean of those banded answers, from 111 maintainers.

That makes the number a statement of belief, not a count. Nobody counted a pull request, the report does not say how bands became a mean, and the question's wording differs from the wording on the report's own chart. The report also tells projects to adopt the Linux kernel's Assisted-by commit tag for disclosure. A kernel commit authored on 13 October and committed on 14 October removed that requirement from the kernel's documentation, one day before the PDF's own creation date and six days before the press release. The report does not mention it.

Read from about 09:40 GMT on Monday 26 October 2026 and read again to 10:05 GMT: the 37 page report PDF, the press release, the survey instrument and frequencies the Linux Foundation published on Zenodo, the kernel's commits and documents, the curl project lead's blog, and the policies of QEMU, curl and the Apache Software Foundation. Help Net Security's article of the same morning was used only as a pointer to the primaries. Every figure marked derived is arithmetic by this site, shown in the table cells or the text beside it.

Who answered, who paid, and how wide the margin is

The report is a survey of people who chose to answer, recruited through the Linux Foundation's own channels and its partners'. Its methodology page prints the dates, the recruitment and a margin of error of plus or minus 6.41 percent at 95 percent confidence.

Interests, one sentence each. Red Hat sponsored the report, describes itself in it as offering cloud, developer, Linux, automation and application platform technologies, and wrote a foreword arguing that the future of AI should be open. The Linux Foundation hosts open source projects and sells training, and its survey offered respondents a discount on that training. Neither interest shows that a figure is wrong; both say who asked, whom, and why.

The printed margin is the textbook figure for a proportion in a simple random sample of 234 (derived: 1.96 times the square root of 0.25 over 234 is 6.4 points). It does not correct for who chose to answer, and it does not apply to a mean of banded answers. The slop question was answered by far fewer people, and the same formula gives wider ranges as the base shrinks:

What the 25 percent is, and what it is called in five places

The funnel below is the whole path from the sample to the headline, using the counts the Linux Foundation published. Nothing here is a count of pull requests.

Zoom

Five documents word the same quantity five ways. The survey asked for proposals that are weak or unchecked and likely made or helped by AI. The report's text says AI generated and low quality. Its chart says low quality and/or AI generated. The press release says low quality, and Help Net Security says low quality or AI generated.

Which reading respondents applied is not in the record. It matters: under the broader readings a sound pull request written with AI help is slop by definition, and under the narrower one it is not. Question 38 did not ask for a count or a percentage. It offered seven bands and a "don't know", and 23 of the 135 who answered chose the last.

To turn bands into a mean, each band has to be given a number, and the report does not say how it did. Using the lower edge of each band the mean is 16.2 percent, using the upper edge 32.6 percent, and using midpoints about 24 percent (all derived). The printed 25 percent sits inside that range and cannot be reproduced from the published tables alone. The middle respondent chose the 1 to 20 percent band: 68 of 112 (61 percent) chose 0 percent or that band, while 24 (21 percent) chose more than 40 percent, and those 24 pull the mean above the typical answer.

The report says the burden "scales with size". Its own numbers say it is highest in the large class and lower in medium than in small. The 31 percent rests on at most 35 maintainers, and the report does not print how many of them answered the slop question. The 20 and 31 percent gap (11 points, derived) is a comparison of two small groups of self reported guesses.

The other headline figures, and what they rest on

The press release's headline says generative AI "Cuts Open Source Coding Time in Half". Figure 19 prints average task times before and after, and the report's text prints percentage cuts beside them. Computing the cut from the printed averages gives the same answer for two tasks, a different one for two, and the text prints no figure for the other two:

The method for the percentages is not stated. Averaging each respondent's own percentage change would give figures that differ from the change in the averages, which fits the two mismatches; that is inference, not a statement in the report. The times are respondents' recalled best guesses for a typical task, picked from menus, not measured. The report prints 96 respondents under Figures 19 and 20, the same number it prints for non adopters in Figure 18, while the published frequencies show question 23 answered by 139. The report does not explain the difference.

The kernel tag the report recommends was removed on 14 October

The report's recommendations include that projects adopt and require the Linux kernel's Assisted-by format in commit messages (page 28). On page 21 it says the kernel requires a tag with an agent name and a model version, and gives an example naming a Claude model and two analysis tools. Help Net Security repeats that the kernel "already asks" for the line. The kernel's own commits and documents, read from the mainline source, say the requirement has gone.

The format the report prints, an agent name and model version with the example claude-4.5-sonnet, matches neither the January wording (whose example names claude-3-opus) nor the July one. It describes a rule that had been simplified 73 days before the PDF was created (derived, from the 3 August commit). The removal was authored two days before the PDF's creation date and committed one day before it. The record does not establish whether the report's authors knew. The fieldwork ended in June, before the July and October changes; the PDF and the press release came after the October one and mention neither change.

What the kernel measured matters more than the date. Its commit message says roughly 10 percent of 18,533 non merge commits carry the tag "while actual LLM use is far more widespread", that some contributors do not know the rule and others leave the tag off on purpose, and that as a result "the tag does not provide the signal it was kept for". The survey's own disclosure figure comes from a different place and a different unit: contributors say, about themselves, how often they attribute AI help. A tag that 10 percent of commits carry and a survey in which about 19 percent say they never attribute cannot be set side by side; they measure different things. What they share is that both rest on contributors volunteering the information.

What the kernel kept is a duty to say, in words a person reads. Its mainline guidance on tool generated content asks contributors to "be transparent about the origin of content in cover letters and changelogs", to say which tools were used and how the change was tested, and it states that AI agents must not add a Signed-off-by line, because only a human can certify the Developer Certificate of Origin. The commit message says the view at the Summit was that how a patch was made belongs in the cover letter. The wording is in Technical details.

The curl example shows what changed, not why

The report uses curl to say slop can fall. It says the project lead reported in 2025 that curl was overwhelmed by AI slop in vulnerability reports, and that by April 2026 the project had "stopped getting AI slop security reports". It concludes that as models improve and projects push back, slop can be reduced. The April quotation is from a LinkedIn post the report cites; this site did not open it, because LinkedIn's robots.txt prohibits automated access. The project lead's own blog says the same in plainer terms and adds what the report leaves out.

Three limits on what this shows. First, curl's figures are about security reports, and the survey asks about pull requests. Second, the sequence includes ending the money, changing the channel twice and the arrival of AI assisted reports that the project lead calls accurate; the posts do not name one cause, so both the report's explanation (models improve, projects push back) and any single alternative are inference. Third, the slop did not turn into AI free work. Almost every report now involves AI, and the project lead writes that the reports are "typically accurate and correct, even if much too wordy". Under a label that counts anything "assisted by AI", those reports would be slop. That is the clearest case in the record for why AI use and slop are different things. The Google bug bounty pause covered earlier is the same pressure seen from a vendor's programme.

What named projects actually require, and the friendly name problem

The report counts policies and prints only two commit tag formats from them. Four public ones, two of which the report names (the kernel and the Apache Software Foundation), read in their own words on 26 October 2026, ask for four different things.

Stated and not stated

A ranked checklist for maintainers, wherever they are

Technical details

The report prints no configuration, query, detection rule or indicator, and nothing a reader could run. It prints one artefact, the commit tag format, and its sources print the rest. Everything in the code blocks below is copied from the primary named in each caption, read on 26 October 2026 (GMT), and nothing is retyped from memory. The two blocks marked derived were written by this site from documented settings and are not published by any primary.

The format the report prints for the kernel tag, page 21 of the PDF. It is the report's wording; it matches neither the January nor the July kernel text below.

Assisted-by: <agent>:<model_version> [tool1] [tool2]
Assisted-by: Claude:claude-4.5-sonnet coccinelle sparse

The kernel text as first committed on 6 January 2026. It names the agent and the model version, and the example names a Claude model.

Attribution
===========

When AI tools contribute to kernel development, proper attribution
helps track the evolving role of AI in the development process.
Contributions should include an Assisted-by tag in the following format::

  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Where:

* ``AGENT_NAME`` is the name of the AI tool or framework
* ``MODEL_VERSION`` is the specific model version used
* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
  (e.g., coccinelle, sparse, smatch, clang-tidy)

Basic development tools (git, gcc, make, editors) should not be listed.

Example::

  Assisted-by: Claude:claude-3-opus coccinelle sparse

The July change, authored 1 July and committed 3 August 2026, with the reason its commit message gives. The tag then named no model at all; since 14 October the current kernel text has no attribution rule.

-  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
+  Assisted-by: LLM [TOOL1] [TOOL2]
...
-  Assisted-by: Claude:claude-3-opus coccinelle sparse
+  Assisted-by: LLM coccinelle sparse

Commit message:

The requirement to identify specific models used in the Assisted-by tag
provides free advertising to proprietary software companies while adding
little or no useful information.  Change the requirement to simply:

  Assisted-by: LLM

The removal, authored 13 October and committed 14 October 2026. These are the paragraphs that give the reasons and the count; the commit also deletes a section of the patch submission guide and the tag handling in the checkpatch script.

A proposal to drop the tag was turned down in July [1]. The main argument for
keeping it was that maintainers wanted a signal that a patch was LLM-assisted,
so that they could review it accordingly.

The tag came up again at the 2026 Maintainers Summit [2]. Roughly 10% of the
18,533 non-merge commits in 7.3 through -rc7 carry an Assisted-by tag, while
actual LLM use is far more widespread. Some contributors do not know about the
rule, others leave the tag off on purpose, and few maintainers ask about it. As
a result, the tag does not provide the signal it was kept for: its absence says
nothing about how a patch was made, and for developers who use these tools for
almost everything, its presence says little more.

[...]

Maintainers do still want to know how a patch was created, but the view at the
Summit was that this belongs in the cover letter, where it can describe how the
tools were used, rather than in the changelog.
Documentation/process/generated-content.rst already asks contributors to be
transparent about tool use and is not changed here. The rules on the DCO and on
the submitter's responsibility for the patch stay as they are.

What the mainline kernel asks for now. The first block is from the tool generated content guidelines; the second from the coding assistants page, which keeps the Signed-off-by rule and no longer has an attribution section.

Second, when making a contribution, be transparent about the origin of
content in cover letters and changelogs. You can be more transparent
by adding information like this:

 - What tools were used?
 - The input to the tools you used, like the Coccinelle source script.
 - If code was largely generated from a single or short set of
   prompts, include those prompts. For longer sessions, include a
   summary of the prompts and the nature of resulting assistance.
 - Which portions of the content were affected by that tool?
 - How is the submission tested and what tools were used to test the
   fix?

AI agents MUST NOT add Signed-off-by tags. Only humans can legally
certify the Developer Certificate of Origin (DCO).

The survey question behind the 25 percent, exactly as the Linux Foundation published it, with the answer counts it published for it. A maintainer reading this should note that it asks for a band, defines slop with the word AI in it, and offers an exit.

38. In your estimation, what percentage of new contribution proposals
(e.g., pull requests) to your project would you characterize as "AI slop"?
(select one) By "AI slop", we mean low-effort, low-quality, or unverified
contribution proposals that are likely generated or assisted by AI.
0%
1% to 20%
21% to 40%
41% to 60%
61% to 80%
81% to 99%
100%
Don't know or not sure

Answered: 135  Skipped: 99

Four project texts, copied from their own pages. Read them for what each asks of a contributor, not for a template to paste.

If you asked an AI tool to find problems in curl, you must make sure to reveal this fact in your report.
We ban users immediately who submit made up fake reports to the project.
A basic rule of thumb is that if someone can spot that the contribution was made with the help of AI, you have more work to do.
There is no bug bounty and the curl project never offers rewards for reported vulnerabilities.

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 QEMU project thus requires that contributors refrain from using AI content
generators on patches intended to be submitted to the project, and will
decline any contribution if use of AI is either known or suspected.

When providing contributions authored using generative AI tooling, a recommended practice is for contributors to indicate the tooling used to create the contribution. This should be included as a token in the source control commit message, for example including the phrase “Generated-by: <Name of Tool> <Version>” or "Co-authored-by: <Name of Tool> <Version>".

GitHub's documented controls for a flooded queue, copied from GitHub Docs. They only apply to repositories you administer, and a pull request limit applies to users without write access.

Limiting interactions in your repository
  In the sidebar, select Moderation options, then click Interaction limits.
  When you enable an interaction limit, you can choose a duration for the limit: 24 hours, 3 days, 1 week, 1 month, or 6 months.
  Limit to existing users: Limits activity for users with accounts that are less than 24 hours old who do not have prior contributions and are not collaborators.
  Limit to prior contributors: Limits activity for users who have not previously contributed to the default branch of the repository and are not collaborators.
  Limit to repository collaborators: Limits activity for users who do not have write access to the repository.

Limiting concurrent open pull requests for users without write access
  In a public repository, you can set a maximum number of pull requests that a user without write access can have open at the same time.
  The bypass list supports up to 100 users.

Disabling pull requests
  To disable pull requests entirely, under "Features", deselect Pull requests.
  To restrict pull requests to collaborators only, in the dropdown under "Pull requests" select Collaborators only.

PATCH /repos/{owner}/{repo}      (Update a repository)

has_pull_requests              boolean   Either true to allow pull requests for this repository or false to prevent pull requests. Default: true
pull_request_creation_policy   string    The policy that controls who can create pull requests for this repository: all or collaborators_only.

Fine-grained token permission: "Administration" repository permissions (write)

pull_request_template.md
docs/pull_request_template.md
.github/pull_request_template.md
.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

Templates are available to collaborators when they are merged into the repository's default branch.

Two blocks written by this site, marked derived: search strings built only from qualifiers GitHub documents, and a short template that asks the questions the sources above ask. Change the repository name and the dates. Nothing here is published by any primary.

repo:OWNER/REPO is:pr created:2026-09-28..2026-10-25
repo:OWNER/REPO is:pr is:closed is:unmerged created:2026-09-28..2026-10-25
repo:OWNER/REPO is:pr is:open review:none

## What this changes
(one or two sentences)

## Linked issue
(required, or write none and say why)

## How it was tested
(commands run and results)

## Tools used
(name any AI tool or code generator used, or write none)

## Responsibility
- [ ] I have read every line of this change and can answer questions about it

How this was read, and what was not

The question the figure does not answer

A survey asked maintainers how much of their queue is slop, offered bands, defined slop with the word AI inside it, and reported the mean. The one disclosure standard it points to was dropped by the project that wrote it, for the plainest reason: nobody could tell what its absence meant. The curl project's lead says slop went away while AI use became nearly universal, which means AI use and slop are not the same thing.

When your project says a quarter of its queue is slop, which pull requests did you count, who counted them, and could a stranger repeat the count?

Key facts