Open-source maintainers report more review pressure as AI speeds coding

AI coding tools are accelerating the production of changes while giving maintainers more to review, according to a Linux Foundation survey published on 20 October. Respondents reported spending 52% less time authoring code. At the receiving end, 59% of maintainers said contribution volume had increased, and maintainers estimated that a quarter of incoming pull requests were low quality.[1]

Large projects reported the strongest pressure: 69% of their maintainers saw more contributions, and the estimated low-quality share reached 31%. These are respondents’ assessments of their projects. They do not establish that one in four submissions across all open-source repositories was AI-generated or defective.[1]

Time saved by authors can move into review

The reported gains differed by task. Alongside faster code authoring, respondents reported a 19% reduction in time spent discussing proposals, while 21% said AI increased the time they spent on highly complex tasks. A self-contained function and a change involving obscure dependencies place different demands on the developer. The survey therefore offers several task-level observations, rather than one measured improvement in end-to-end delivery.[1]

In ordinary software economics, the author of a patch often gets the credit for shipping it while the review and long-term maintenance costs are borne elsewhere. AI can intensify that imbalance. An individual who previously submitted two carefully researched changes may now submit ten plausible-looking ones. The maintainer still has to check whether a proposal duplicates existing functionality, introduces a security flaw or misunderstands a convention documented only in an old discussion thread.[1]

A bad patch is not necessarily one that fails a syntax check. It may pass tests while silently changing behavior that users depend on. An AI-generated explanatory note can make the code sound more considered than it is. The reviewer then faces a credibility problem: does the accompanying rationale reflect genuine understanding, or is it another fluent guess? Volume matters because a modest increase in false confidence, multiplied across thousands of contributions, can overwhelm volunteers.[1]

Participation grows without an equivalent rise in trust

Some 71% of maintainers agreed that generative AI lowered barriers to participation. Yet 53% disagreed that it had improved community trust. That second result establishes a lack of perceived improvement, not a measured fall in trust. It suggests that making contributions easier has not automatically made them easier to accept.[1]

The research also found that only 35% of projects had a formal policy that permits generative-AI use and sets expectations; about 32% had no policy and no plans to introduce one. Most surveyed contributors, 61%, said they performed detailed review and full functional testing of AI-generated code before submitting it, but their own reported practice does not establish that every contributor in an actual public repository does so. A clear policy can insist on tests, disclosure where material, a reproducible explanation and human accountability for the submitted changes without forbidding assistance outright.[1]

Respondents also described productive uses of time saved: 66% reported addressing technical debt, 63% shipping features and 58% learning. Those benefits belong in the same account as review pressure. A project can gain useful contributions from people using AI while still requiring explanations, tests and willingness to respond to review.[1]

Measuring the work after submission

The Linux Foundation's research was supported by sponsors including Red Hat, Futurewei, OpenSSF and LF AI & Data. It should be read as survey evidence with respondent and sampling limits, not as an independent longitudinal experiment comparing actual code quality before and after the arrival of AI tools. It does, however, raise a practical measurement question: when an organisation claims that coding assistance doubles output, whose time has been counted?[1]

For a project assessing these tools, accepted changes and reviewer time would provide a fuller picture than submission volume alone. Reopened bugs and follow-up maintenance would show whether a faster first draft remained useful. The survey identifies why those measures matter: the person who saves time creating a patch is not always the person who spends time establishing that it belongs in the codebase.[1]

Report an error or suggest a correction