How to deal with fully LLM-generated merge requests

[Daniel Ramos]

Hello all,

First, a word on walls of text, since this thread started with them.
I am an electrical engineer, and I learned it from walls of text: standards, datasheets, textbooks, specifications.
How would anyone learn engineering without them, or become a lawyer without a life of reading them?
Long is not the problem; empty is.
A long text full of facts you can check is a reference, and a short one with none is noise, whoever or whatever wrote it.
This message is long because it carries numbers, and every one of them has a source.

I read this thread, the two Discuss topics and Nate's post, and I went looking for the numbers behind the fear of an AI flood.
First in KDE, then in the projects usually cited, then in our own history.
Every claim below has a link or a query anyone can repeat.

In short:
1. KDE's record shows no flood: more merge requests every year, merged at the same rate or better.
2. The cases cited elsewhere come from older models, money prizes or too few reviewers, and curl's maintainer now says the slop is practically gone.
3. The largest slop event in open source had no AI in it, and neither did the worst attacks on it.
4. A rule against the tool binds only the people who disclose it.

KDE's record

invent.kde.org API, all projects, counted on 23 October 2026 (GET /api/v4/merge_requests?scope=all with created_after, created_before and state, reading the X-Total header).
Merge requests opened per month, first half of each year: 1,828 in 2024, 2,031 in 2025, 2,258 in 2026.
Closed without merge, same periods: 9.7%, 8.7%, 8.9%.
This summer the volume did rise: 7,845 opened from July to September 2026, against 5,516 a year before.
KDE also merged more of them: 6,346 already merged, against 4,781 a year before, and the share closed without merge fell from 9.8% to 7.0%.
12% of this summer's merge requests are still open, so the final split is not known yet.
KWin, first half of each year: 1,185 opened in 2024, 892 in 2025, 908 in 2026, closed without merge 9.6%, 8.2%, 7.4%.
If generated merge requests were pouring in and being closed, the closed share would be rising; it is falling.
Of the 4,504 merge requests open across KDE today, 65 disclose AI help, about 1.4% (an Assisted-by trailer, an AI co-author, a "generated with" footer or a plain statement, each candidate checked by hand).
82 that disclose it were merged this year, two of them in KWin, judged on their merits:
https://invent.kde.org/plasma/kwin/-/merge_requests/9026
https://invent.kde.org/plasma/kwin/-/merge_requests/8602
Only disclosed use can be counted, and that limit is the point of the last part below.

KDE's own timeline has a number for volume too.
The first 500,000 commits took nine years, to January 2006; the next 250,000 took 23 months; the last 250,000 of the first million took 19 months, and the timeline credits that surge to "the launch of innovative KDE 4".
https://timeline.kde.org/
Nobody counted how many were slop, and nobody asked which editor wrote them.

The cases usually cited, in their own words

curl ended its bug bounty in January 2026, and Daniel Stenberg gave the reason: "We suspect the idea of getting money for it is a big part of the explanation."
https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/
On 22 October 2026 he wrote: "Since spring 2026 the slop reports are practically gone."
And: "Our current challenge is much harder: high volume, high quality", with AI-assisted reports that "point out actual problems, and sometimes vulnerabilities".
https://daniel.haxx.se/blog/2026/10/22/ignore-the-slop/
One audit by engineers "pointing their AI powered tooling at the curl source code" gave curl "no less than thirty-five published curl vulnerabilities and CVE Ids."
https://daniel.haxx.se/blog/2026/10/14/a-curl-audit-by-aisle/
His answer to the volume was to open the process to more people, not to ban the tool: from 26 October, low and medium reports become public issues.
https://daniel.haxx.se/blog/2026/10/20/do-minor-curl-vulnerabilities-in-the-open/
Python's warning (Seth Larson, December 2024) was about the models of 2024, and it gives no counts.
https://sethmlarson.dev/slop-security-reports
The early warnings were fair for their time; the maintainer who received the most of them says they no longer describe it.
tldraw closed outside pull requests in January 2026 as "a temporary policy until GitHub provides better tools for managing contributions", with no numbers.
https://github.com/tldraw/tldraw/issues/7695
Godot (30 June 2026) names its main cause itself: "a large part of the backlog comes from the fact that the number of qualified reviewers is small".
AI "compounded" it, the post gives no numbers, and disclosed help with menial tasks and machine translation stay allowed.
https://godotengine.org/article/contribution-policy-2026/
The Linux Foundation's 25% (20 October 2026) is an estimate by maintainers, "estimated to be low-quality", not a count.
Its advice is written policies, changes tested and documented before submission, and standard attribution.
https://www.linuxfoundation.org/press/new-lf-research-survey-shows-generative-ai-cuts-open-source-coding-time-in-half-but-25-of-incoming-pull-requests-are-considered-ai-slop
The Linux kernel's Maintainers Summit agreed to drop the mandatory Assisted-by tag, and Linus wrote: "We're not going to make stupid rules that say 'you can't use tools for X'".
https://www.theregister.com/a/5303140
In July he had already written: "Linux is not one of those anti-AI projects".
https://lore.kernel.org/linux-media/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/
systemd and NetworkManager, cited at the start of this thread, both accept AI-assisted code the author can explain and has tested; their canaries catch agents working alone.
systemd: "You may use generative AI and LLM tools ("AI") to help create contributions, as long as you review and edit what they produce".
NetworkManager: "Authors are responsible for 100% of the code they submit. Do not send a patch you cannot explain, and do not send one you have not built and tested yourself."
https://github.com/systemd/systemd/blob/main/docs/CONTRIBUTING.md
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/CONTRIBUTING.md
Both also ask people to write their own messages; why I use the tool for my English is further down.

The largest slop event in open source had no AI in it

Hacktoberfest, October 2020: a T-shirt for four pull requests.
DigitalOcean's own recap counts 34,595 pull requests not accepted by a maintainer, 9,598 labelled spam or invalid, and 172,599 sent to repositories that had not opted in.
https://www.digitalocean.com/blog/hacktoberfest-recap2020
No language model was involved; the cause was a prize, the same cause Stenberg names for curl's bounty.

Bad actors do not care which tool a rule names

The xz backdoor (CVE-2024-3094) took a person more than two years of patient trust building, while fake accounts pressed a tired maintainer: "Progress will not happen until there is new maintainer."
https://research.swtch.com/xz-timeline
Andres Freund found it on 29 March 2024 because SSH logins on Debian sid were slow.
https://www.openwall.com/lists/oss-security/2024/03/29/4
In 2020 a university group sent the kernel deliberately flawed patches to study its review, and in 2021 the kernel banned the university.
https://www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/
Neither used AI, and neither would have read a policy about it.
curl suspected the same with AI: reports that did not look like slop were "presumably because they too were actually misled by AI but with that fact just hidden better."
A rule against the tool stops the 65 who disclosed it above, and none of the people it is written for.

The word hacker went through this before

The Jargon File: "A person who enjoys exploring the details of programmable systems and how to stretch their capabilities", and for the criminal sense: "[deprecated] ... The correct term for this sense is cracker."
http://www.catb.org/jargon/html/H/hacker.html
RFC 1392 (1993): "The term is often misused in a pejorative context, where "cracker" would be the correct term."
https://www.rfc-editor.org/rfc/rfc1392
In September 1983 Newsweek put a teenager from the 414s on its cover under "Beware: Hackers at play", and the word for skill became the word for crime in the press.
https://en.wikipedia.org/wiki/The_414s
Our community kept the word anyway: KDE's own documentary opens with "a group of geeks coming together and trying to hack some cool stuff together".
"AI" is on the same road, from the name of a tool to the name of other people's bad conduct.
That conduct already has names, spam, slop and careless work, and they fit whatever the tool.

KDE has been here before

In 1997 and 1998 KDE itself was judged by its tool, Qt, before anyone judged the desktop.
In the documentary for KDE's thirty years, Matthias says: "I can understand the reasoning, but I cannot understand why nobody talked to us or to Trolltech."
Eirik Chambe-Eng, who co-founded Trolltech, sums up the time in the film: "A lot of it boiled down to Qt is evil, KDE is evil, GNOME is good, without people really knowing the details."
The answer was not to drop the tool; it was a rule about the work's freedom, the KDE Free Qt Foundation, signed in 1998, and thirty years later KDE still runs on Qt.
Matthias again: "if we had worked together against the commercial big world, it would have been much better."
https://www.youtube.com/watch?v=1Vyzla9mx4g (21:03, 21:25 and 22:33)

Why I use AI

I am Brazilian, and I think and speak Portuguese.
I value proper communication, and AI lets me write to you in clear English, at the level this list deserves.
My English level is not the point here; being understood is.
The ideas, the design, the measurements and the decisions are mine; I direct the work, run the tests and check everything before it is sent, this message included.
The tool never signs. The engineer does.
AI also finds what people miss: Linus credited an AI for "much of the grunt-work" in "a debug session from hell" that ended in a one-line drm/xe fix.
https://github.com/torvalds/linux/commit/818bebeb63dd6bf5f4e07e145f6cdbace520a34c
AI reviews too: FFmpeg runs an AI reviewer on its own forge, and it reviewed three of my pull requests this week.
KDE is written by people from everywhere and translated into many languages, and a rule against AI-written text would fall hardest on those of us for whom English is a second language.

My question to this list

As an engineer, I make rules from measurements, and these are the measurements I found.
Where in engineering is a rule made from fear valued over one made from a measurement?
If one of these numbers supports a rule against the tool, rather than against careless work, I would like to see it.
If none does, the rule KDE already has fits: the contributor owns and understands what they submit, whatever tool helped.
https://community.kde.org/Guidelines_and_HOWTOs/Maintainers_and_Contributions

Thank you for reading,
Daniel Campos Ramos
Sparky Stereo OS