AI-assisted pull requests need a maintainer capacity budget

What the survey adds

Linux Foundation Research surveyed 234 open-source contributors and maintainers about generative AI. Respondents estimated average time savings from 19% for proposal discussions to 52% for code authoring. They also reported reinvesting saved time in technical debt, features and learning. Express Computer independently covered the report and its implications for enterprises that depend on open-source software.

The benefits did not remove review work. Maintainers of large projects estimated that 31% of incoming contributions were low-quality AI-assisted submissions, while 64% of maintainers in that group reported that review periods had increased; 64% is a share of maintainers, not the size of a time increase. In question Q35, 53% of 118 maintainers disagreed that generative AI had improved community trust. In Q30, 35% of 119 project responses reported a formal policy permitting its use. These are question-specific survey descriptions, not direct telemetry from all repositories.

Where the productivity moves

A contributor can save time while the project loses time. Code generation happens before submission; verification, explanation, integration and mentoring happen after it. If the contributor’s gain increases submission volume or reduces the work completed before review, the scarce resource becomes maintainer attention. An enterprise productivity dashboard can therefore improve while a dependency’s queue deteriorates.

The report also contains counterevidence to a simple “AI slop” story. Many respondents said they reviewed generated code line by line and tested it, and maintainers reported useful time savings in technical discussion and proposal review. The decision is not whether to ban the tool. It is how to keep generation rate, verification quality and community capacity inside one operating envelope.

The capacity budget

A project policy should state what a contributor must supply: disclosure where required, a problem statement, tests, provenance for generated material, and evidence that the author understands the change. It should also state admission rules for duplicate, oversized or poorly scoped submissions. Returning incomplete work before detailed review moves the verification cost back toward the person creating the contribution.

The missing complement is a capacity budget. Track incoming volume, first-response time, review hours, rework loops, mentorship load and the share of submissions closed without deep review. Set a threshold that pauses automated or bulk submissions when the queue exceeds available reviewers. For enterprise-backed projects, fund maintainer time and mentorship rather than treating the commons as a free review service.

Calibrate the rule by contribution risk. A documentation correction and a change to authentication code should not consume the same gate, but both need an accountable human submitter. Sample accepted AI-assisted changes after merge for defects and reversions, and compare them with other contributions without claiming that a difference proves the cause. If the policy reduces access for legitimate newcomers, adjust the evidence route and add mentoring capacity rather than quietly lowering the quality threshold.

Decision rule

Do not approve an AI contribution policy that contains only disclosure language. Require a queue-capacity owner, contributor evidence checklist, admission threshold, return route and monthly review of trust and burnout signals. If a team cannot say who absorbs the extra review demand, the productivity claim is incomplete. This builds on the earlier Skills Intelligence call to make developer verification work inspectable by adding a community-level capacity constraint.