On October 20, 2026, the Linux Foundation released a report examining how generative AI is affecting open-source software (OSS) development. According to the survey, using generative AI cut the time needed to write code by an average of 52%. At the same time, respondents estimated that low-quality or AI-generated submissions account for an average of 25% of the change proposals they receive. All of these figures are self-reported by respondents, but they show that while AI is speeding up the writing of code, it is also creating a new burden for the people who review that work. Respondents on large OSS projects in particular were more likely to say review time had increased, and one open question is how much verification contributors should complete before submitting an AI-assisted change proposal.
Coding time down 52%: what the number does and doesn't mean
The survey ran from April to June 2026 and targeted contributors to OSS development, as well as maintainers who review change proposals and look after projects. The Linux Foundation and partner organizations recruited participants through email, social media and other channels, and 234 people completed a 45-question web survey. The report was written by Sam Boysel and Anni Lai of LF Research. Red Hat sponsored it, and Futurewei, OpenSSF and LF AI & Data supported the survey. Note that the report summarizes a questionnaire survey; it is not a peer-reviewed experimental study.
The finding that coding time nearly halved is based on estimates from 96 respondents of their typical working time before and after adopting generative AI. According to Figure 19 of the report, average time spent writing code fell from 4 hours 18 minutes to 2 hours 6 minutes. Time spent on code review and feedback also fell, from 2 hours 30 minutes to 1 hour 24 minutes. The report puts these reductions at 52% and 44%, respectively.
However, these figures do not come from giving the same task to developers who use AI and developers who don't, then measuring actual time taken. They are times that respondents estimated by looking back on their own experience, and they do not mean the overall development process became twice as fast. To estimate the effect of adopting AI in a real development environment, you need to check where the tasks covered by the survey fall within your own workflow.
The time savings from generative AI also vary widely by type of work. Average time dropped for all six task types surveyed, but technical discussions saw only a 20% reduction and discussions about change proposals only 19%. This suggests that AI improves efficiency to different degrees for writing code and for explaining intent to others and building consensus. For difficult tasks, 64% said they saved time, while 21% said it actually took longer. The results do not show that generative AI uniformly speeds up hard work.
Timing and respondent recruitment also matter when interpreting the findings. The report was published in October, but responses were collected between April and June of the same year, so the effects of AI models and tools released since then are not reflected. And because participants were recruited through the networks of the Linux Foundation and its partners, respondents may not be representative of OSS developers as a whole. These figures are best read as reflecting the experiences of the developers and maintainers who took part.
Larger OSS projects see a heavier code review burden
Even as generative AI improves efficiency, concern is spreading among maintainers about a rise in low-quality change proposals. The Linux Foundation report uses the term "AI slop" for low-quality AI-generated submissions whose value is unlikely to justify the time spent reviewing them. The pull requests (PRs) examined in the survey are proposals asking a project to accept changes such as new code. According to Figure 2 of the report, respondents estimated that such low-quality submissions make up an average of 25% of PRs.
That 25%, however, is not the result of a comprehensive analysis of PRs submitted to public repositories; it is the average of the shares estimated by 111 respondents. In addition, while the report's text describes these as low-quality AI-generated submissions, the metric in the figure uses a broader definition: "low-quality, AI-generated, or both." It therefore cannot be concluded that a quarter of all PRs submitted to OSS projects worldwide are low-quality AI-generated code.
Of particular note is that review burden differs by project size. Figures 1 and 2 on pages 9–10 of the report compare, by project size, the estimated share of low-quality AI submissions and changes in review time.
| Project size | Average estimated share of "AI slop" (Fig. 2) | Share saying review time increased (Fig. 1) |
|---|---|---|
| Small | 23% | 46% |
| Medium | 20% | 55% |
| Large | 31% | 64% |
Note: Based on the Linux Foundation survey report. Figure 2 aggregates responses from 111 people and Figure 1 from 174; the questions and respondent counts differ. The report classifies projects with fewer than 10 contributors as small and those with more than 50 as large.
Among large projects, 64% of respondents said review time had increased, 18 percentage points higher than the 46% for small projects. This does not mean that the review process itself became 18% longer. Nor does the report show respondent counts or margins of error by size, so it is impossible to say whether the gap is statistically significant or whether generative AI use is its direct cause. Even so, the trend is clear: the larger the project, the more respondents complain of a heavier review burden.
Among large projects, 69% also said the volume of submitted change proposals had grown since generative AI became widespread. The most frequently cited concern about AI-assisted submissions was maintainer burnout, which 63% regarded as a problem. This 63% is not the share of people who have actually experienced burnout, but the share of respondents who worry about the issue.
At first glance, it seems contradictory that generative AI shortens individual code review time while the overall review burden on projects grows. But making your own assigned work more efficient is a different job from understanding a steady stream of externally submitted change proposals and deciding whether to accept them. Even if each review gets faster, a rise in the number of submissions can increase the total amount of work maintainers must handle. This survey alone cannot determine whether OSS development as a whole has become more productive once the work time AI saved is netted against the new review burden. At the very least, individual working speed alone is not enough to evaluate the efficiency of collaborative development.
Who should be responsible for verifying AI-generated code?
As generative AI use spreads, formal operating rules in OSS projects have not kept pace. In Figure 5 of the report, 35% of 119 respondents said their project has a policy that formally permits AI use. Meanwhile, 32% said there is no policy and no plan to create one, 23% said they plan to create one, and 10% said AI use is explicitly prohibited. The key question is no longer just whether to allow or ban AI use, but what conditions to attach when it is allowed.
Awareness is also growing among contributors that AI-generated code needs to be verified. In Figure 16, answered by 137 people, 61% said they review AI-generated code line by line and run full functional tests before submitting it. This too is self-reported, however, and does not guarantee the quality of the code actually submitted. Among 54 respondents asked about existing AI usage policies, 76% said the policies require transparency or disclosure about AI use, and the same share said they make the contributor responsible for review.
Hilary Carter, senior vice president of research at LF Research, said in the Linux Foundation announcement that responsibility for testing and disclosure needs to rest with contributors. The idea is that even when a change proposal is produced with generative AI, the contributor is responsible for understanding its contents and testing it appropriately before submitting it. This is expected to reduce the burden on receiving maintainers of working out from scratch what a change means or redoing basic checks of its behavior.
One example of turning this thinking into concrete rules is the Linux kernel's guidelines on tool-generated content. They require contributors to understand the entire change and be able to answer questions during review. Contributors must also disclose which tools they used and which parts of the change those tools were involved in, and explain what testing they performed. The guidelines state that if a contributor does not understand the change and cannot explain it adequately, maintainers may reject the proposal without conducting a detailed review.
The Linux kernel's document on AI coding assistants lays out even more specific steps for work from finding a bug to fixing it. For non-trivial bugs, it asks contributors to try to reproduce the problem, write a fix, and then build and verify its behavior. If there are tests that could not be run or reproduction steps that could not be prepared, that fact must be stated explicitly. The guiding principle is that even when AI generates the code, it is humans who verify the content and take responsibility for the change proposal.
That said, these are the Linux kernel's own guidelines, not common rules applying to all OSS projects. Still, the direction they point in is instructive: beyond deciding whether to permit AI use at all, require contributors to supply upfront the information maintainers need to decide whether to accept a change. The Linux Foundation survey does not demonstrate a causal link showing that adopting such rules actually reduces review burden. Going forward, it will be necessary to test how much requiring disclosure of AI use and pre-submission testing reduces review rework and maintainers' working time. Whether the time individuals save with generative AI can be turned into productivity gains for OSS development as a whole will depend not only on the efficiency of generating code, but on operating rules that determine who guarantees its quality, and at which stage.