LF Research is the Linux Foundation’s research arm. It was set up in 2021 and publishes studies on how open source is built and used, drawing on surveys and project data.
Its latest report, Navigating Open Source Software Development in the Generative AI Era, surveyed 234 contributors and maintainers on how generative AI is affecting the way open source gets made.
The survey estimates that about 25% of incoming pull requests are low-quality AI slop, with the estimate climbing to 31% on larger projects.
Red Hat sponsored the report, with additional contributions from OpenSSF, LF AI & Data, and Futurewei.
The findings
Large projects, the ones with more than 50 contributors, are affected the most.
Among their maintainers, 69% report more incoming contributions, against 59% across all maintainers, and 64% say reviews now take longer. Burnout is their top concern at 63%, narrowly ahead of contribution quality at 60%.
You will also find that policies have not caught up to the AI-assisted coding and vulnerability reporting trend.
Of the 119 respondents who answered the question, 35% said their project has a formal policy permitting AI use. Another 32% have none and no plans for one, 23% plan to write one, and 10% ban AI contributions outright.
You might remember that some projects, like LLVM, allow AI-generated code with conditions. Separately, 26% of projects have no way of verifying AI-assisted contributions at all.
The report calls on contributors to give effort to written policies, disclosure of AI use, and testing and documentation.
Interestingly, AI does seem to save developers’ time. Respondents estimate that code authoring takes 52% less time on average, while on more complex tasks, 21% said the work took longer with AI.
Most maintainers (71%) say AI makes it easier for newcomers to start contributing. Just over half (53%) say it has not improved community trust, while only 13% say it has.
Some caveats do apply.
Respondents were recruited through Linux Foundation newsletters and social channels, plus partner channels that include Red Hat. As for the 25% slop figure, it is an estimate from 111 respondents, not a measured count.
That sounds fair, but disclosure is mostly left to individual choice right now, and a quarter of projects have no way to check anything. It only works if the people sending slop make an effort to do it.
And as we have already seen time and again, the ones sending slop rarely bother.
They aren’t specific about how the question was posed, no, but page 9’s wording does state that it is maintainer-estimated, and specifies the terms “low-quality” and “slop” as the qualifier for the 25% figure, so unless they’ve made a huge logical leap, I think it is reasonable to conclude that maintainers were specifically asked about low-quality AI-generated PRs (or “AI slop”). I think people are sensible enough these days to not deny that AIs sometimes produce acceptable code.
I’m not seeing it. This is the sole relevant statement on pg 9 where they simply define AI slop in a general way that avoids tying it in with their measurements:
In addition to the explicit ‘and/or general AI use’ statement, there are several red flags here that make me think this is a low quality study to be taken with salt. Or maybe I’m cynical and using the term ‘slop’ to push a research study is both unusual and suspect.
New to the forum?
There are plenty of people who call all ai generated code “slop”.
It’s a shorthand. It doesn’t mean that AI is categorically incapable of producing code that is acceptable. If you ask an LLM to write a hello world program I’m sure everyone here can agree it would most likely produce a correct program.
But that’s the problem - there is no ‘definition’ for slop. Some people call ALL ai code slop, some just call bad code slop. It’s a messy term that’s up to the user to define.
And also, according to Alex
What are we even talking about anymore? Has language always evolved this fast?