One in Four Pull Requests Is AI Slop: Reading the Linux Foundation's New Survey Properly

The Linux Foundation published a research report on October 20, 2026 that lands on a number most maintainers already suspect: 25% of incoming pull requests are estimated to be low-quality AI slop, rising to 31% on large projects. The same report also says generative AI cuts code authoring time by 52% and lets 71% of maintainers agree it lowers the barrier to contribution. Both things are true at once, and that is the interesting part. What follows is not a summary of the press release. It is a walk through what each figure actually measures, where the measurement is fragile, and what a project can do with it on Monday morning.

One in Four Pull Requests Is AI Slop: Reading the Linux

1. What the Survey Actually Measured

The report is titled Navigating Open Source Software Development in the Generative AI Era, published by LF Research with sponsorship from Red Hat and support from Futurewei, OpenSSF and LF AI & Data. It was presented at All Things Open in Raleigh on October 19-20, 2026. The population matters more than the headline: respondents are open source contributors and maintainers describing their own behavior and their own projects, not a crawl of GitHub activity. So every number here is a perception with a denominator, not a measurement of code. That distinction decides how you should use the 25%: it is a maintainer-reported estimate of how much incoming work is low quality, which is exactly the number that should drive triage policy, and not a number you can quote as an objective defect rate.

# Triage filter: which incoming PRs cannot show their own evidence?
# Requires: gh (authenticated), jq. Run against the queue, not the whole repo.
gh pr list --state open --limit 100 \
  --json number,title,additions,deletions,changedFiles,body,files \
  > /tmp/prs.json

jq -r '.[] |
  (.files | map(.path) | map(select(test("(^|/)(test|tests|spec|__tests__)/|\\.(test|spec)\\."))) | length) as $tests |
  (.body // "" | length) as $blen |
  [ .number, .additions, $tests, $blen,
    (if $tests == 0 and .additions > 50 then "NO-TEST-EVIDENCE" else "ok" end)
  ] | @tsv' /tmp/prs.json \
  | awk -F'\t' '$5=="NO-TEST-EVIDENCE" {print}' | sort -k2 -nr | head -20

# A pull request that changes behavior and touches no test is not necessarily
# slop. But it is the cheapest first pass, and it never needs a judgement call.

2. The 25% Number and the Projects Where It Doubles

The specific findings: 59% of maintainers report growing contribution volume since GenAI became common, and that climbs to 69% among large projects. Meanwhile 25% of incoming PRs are estimated to be low-quality, and 31% on large projects. Notice the shape of that, because it is not uniform pain. Large projects see more volume and a higher share of junk, which is what you would expect if the cheap path is to point an agent at the biggest, most visible repository in a category. The practical consequence is that triage capacity, not review quality, is the binding constraint on big projects. A reviewer who can handle 30 PRs a week cannot handle 90, and no amount of careful reading fixes arithmetic.

<!-- Put this in .github/pull_request_template.md, above the description box. -->
## What this changes


## Evidence
- [ ] I ran the affected tests locally: `________`
- [ ] This PR includes a test that fails before the change and passes after
- [ ] If no test was added, here is why: `________`

## If AI assistance was used
- [ ] Disclosed below (tool + how much of the change it produced)
- [ ] I read every line and can explain it
- Tool and scope: `________`

<!-- Maintainers: a blank section is a valid reason to close, not a reason to ask again. -->

3. The Productivity Numbers, Including the Ones That Went Backwards

Respondents estimate average time reductions across all six measured open source activities, and the spread is the useful detail: code authoring is down 52%, proposal and design discussion down 19%. The report frames overall gains as up to 50%. But 21% of respondents say high-complexity tasks take them longer with GenAI, which is not a rounding error, it is a fifth of your senior contributors. Anyone who has watched an agent confidently restructure a module it did not understand will recognize that number. The lesson is not that AI is slower on hard problems, it is that the time saved on shovel work is being partly paid back on the tasks where a wrong assumption costs a day of debugging. That is an argument for routing, not for abstaining.

# Measure review LOAD, not review virtue. Weekly, from the API.
python3 - <<'PY'
import json, subprocess, datetime as dt

raw = subprocess.run(
    ["gh", "pr", "list", "--state", "all", "--limit", "300",
     "--json", "number,createdAt,mergedAt,closedAt,additions,author"],
    capture_output=True, text=True, check=True).stdout

prs = json.loads(raw)
now = dt.datetime.now(dt.timezone.utc)

open_days, merged_days, vols = [], [], 0
for p in prs:
    c = dt.datetime.fromisoformat(p["createdAt"].replace("Z", "+00:00"))
    end = p["mergedAt"] or p["closedAt"]
    e = dt.datetime.fromisoformat(end.replace("Z", "+00:00")) if end else now
    (merged_days if p["mergedAt"] else open_days).append((e - c).days)
    vols += p["additions"]

def pct(xs, q):
    xs = sorted(xs)
    return xs[min(len(xs) - 1, int(len(xs) * q))] if xs else 0

print(f"sample={len(prs)}  median_time_to_merge={pct(merged_days, .5)}d")
print(f"median_age_of_open={pct(open_days, .5)}d  total_additions={vols}")
# When median age of open PRs climbs while merges stay flat, the queue is
# growing faster than you can triage. That is a capacity number, not a mood.
PY

4. The Trust Gap Is a Policy Gap

71% of maintainers agree GenAI lowers the barrier to entry for open source, and 53% disagree that it has improved community trust in contributions. Those two sentences together describe the actual problem better than any slogan: more people can participate, and fewer maintainers believe what arrives. Then comes the number that should worry you most. Only 35% of projects have a formal policy permitting GenAI use, and 32% have no policy and no plans for one. On the contributor side, 61% say they do detailed reviews and full functional testing of AI-generated code before submitting, but disclosure of AI assistance is inconsistent. So the majority of people are doing the right work and not saying so, and a third of projects have decided not to decide.

# CI gate: behavior change without a test delta fails the build.
# This is the single rule that makes "AI slop" cheap to reject.
name: change-evidence
on: pull_request

jobs:
  evidence:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Require test delta for source changes
        run: |
          git fetch origin ${{ github.base_ref }} --depth=1
          SRC=$(git diff --name-only origin/${{ github.base_ref }}...HEAD \
                | grep -E '^(src|lib|app)/' | grep -vE '(test|spec)' | wc -l)
          TST=$(git diff --name-only origin/${{ github.base_ref }}...HEAD \
                | grep -E '(test|spec)' | wc -l)
          echo "source_files=$SRC test_files=$TST"
          if [ "$SRC" -gt 0 ] && [ "$TST" -eq 0 ]; then
            echo "::error::Source changed with no test delta. Add a test or explain in the PR body."
            exit 1
          fi

5. Four Things a Project Can Do This Week

First, write the policy. The report's own recommendation is explicit: clear written policies for AI-assisted contributions, standardized attribution, and a demand that contributors test and document AI-assisted changes before submission. Second, make the contribution cheap to triage: require a test delta, a reproducer or a stated failure mode in the PR body, because slop usually cannot produce one. Third, measure review load rather than review quality, since the constraint is capacity. Fourth, publish the policy where contributors actually look, which is CONTRIBUTING.md and the PR template, not a wiki page nobody opens. The code blocks below are the smallest versions of those four moves that still work in a real repository.

# Disclosure check: read the trailer, do not guess from style.
# Standardize on a git trailer so it survives rebases and squash merges.
python3 - <<'PY'
import subprocess, sys

TRAILER = "AI-Assisted:"

def commits(base="origin/main"):
    out = subprocess.run(
        ["git", "log", f"{base}..HEAD", "--format=%H%x1f%B%x1e"],
        capture_output=True, text=True, check=True).stdout
    for chunk in out.split("\x1e"):
        if not chunk.strip():
            continue
        sha, body = chunk.split("\x1f", 1)
        yield sha.strip(), body

missing, disclosed = [], 0
for sha, body in commits():
    lines = [l.strip() for l in body.splitlines() if l.strip()]
    hit = next((l for l in lines if l.startswith(TRAILER)), None)
    if hit:
        disclosed += 1
        print(f"{sha[:8]} {hit}")
    else:
        missing.append(sha[:8])

print(f"disclosed={disclosed} no_trailer={len(missing)}")
# Fail soft by default: report, do not block. A gate that misfires on
# honest contributors teaches them to write the trailer without meaning it.
PY

6. Where the Saved Time Is Going

One finding deserves more attention than it got: 66% of respondents say they reinvest the time GenAI saves into technical debt, 63% into new features, 58% into learning and upskilling. That is the argument for the whole exercise. If a project spends its AI dividend on more pull requests, it will drown in review. If it spends the dividend on the debt it has been carrying for three years, the same tool that generated the queue also buys the capacity to clear it. The mentorship data points the same direction: 46% of maintainers say GenAI increases the need to mentor new contributors, against 32% who say it decreases it. Faster code does not reduce the need for someone who knows why the code exists.