Open source has plenty of code now. It’s maintainer time that’s running out

AI coding tools are adding work to open source projects.

The expected upside was obvious enough. Small projects would get cheaper code generation, more contributions, and maybe some relief. What maintainers are describing looks different. They’re getting a wave of AI-assisted pull requests and bug reports that look polished, sound plausible, and still burn reviewer time.

It’s visible across major projects. VLC overseer Jean-Baptiste Kempf says pull request quality from newcomers is trending "abysmal." Blender’s foundation says LLM-assisted submissions have wasted reviewer time and hurt motivation. cURL temporarily paused its bug bounty program after getting buried under low-signal, AI-written reports. Mitchell Hashimoto went further and built a system to restrict GitHub contributions to vouched users because, in his view, the old friction that filtered out unserious contributors has disappeared.

Daniel Stenberg, cURL’s creator, summed it up well: “The floodgates are open.”

AI has made code cheaper to produce. Review, trust, and maintenance still cost what they cost, and in practice they may cost more now.

Why open source feels this first

Most open source projects were never limited by how fast someone could type. The hard part was everything around the code: understanding old design choices, preserving compatibility, keeping dependencies in check, dealing with security fallout, and deciding whether anyone will want to maintain the change six months from now.

AI assistants help with the typing. Sometimes they help a lot. Experienced contributors can use them to scaffold a module, port logic between platforms, generate tests, or chew through repetitive refactors faster than before.

The benefits don’t land evenly. Strong contributors often get faster. Maintainers get buried.

The reason is simple. The cost of producing a submission has collapsed. One contributor can now generate ten decent-looking PRs in the time it once took to draft one mediocre patch. Even if nine are junk, all ten still have to be reviewed or triaged by someone with context. Most projects don’t have spare reviewer capacity. Plenty are already stretched just keeping up with releases and security fixes.

So the bottleneck moves. Less effort goes into producing code. More human effort goes into filtering it.

Plausible code is expensive code to review

The irritating part is how convincing these changes can look.

A modern coding assistant can index a repo with tools like tree-sitter, ctags, or LSIF, pull in a handful of relevant files, generate a diff, run lint and unit tests in a sandbox, then open a tidy PR with a polished summary. On GitHub, that often passes the first glance.

Maintainers aren’t reviewing for syntax or formatting. CI can handle that. They’re reviewing for all the implicit context the model usually misses:

• old bug history that never made it into docs
• weird invariants buried in a mailing list thread from 2019
• performance assumptions in hot paths
• ABI or API compatibility promises
• security constraints that aren’t obvious from local code context
• licensing and provenance concerns

Large context windows don’t solve much of this. A 200K or 1M token model can read a lot of files. It still won’t reliably understand why a project chose a less fashionable implementation three years ago, or why adding a shiny dependency is a bad deal for a mature library.

That’s why so many AI-assisted changes fail in expensive ways:

• API hallucinations that compile against the wrong version or rely on methods that don’t exist
• security mistakes like weak randomness, unsafe SQL string handling, permissive CORS, or sloppy file path logic
• performance regressions such as hidden O(n²) loops, extra allocations in tight paths, or blocking I/O inside async code
• maintenance debt from adding a package for a trivial feature
• license risk when model output mirrors code from incompatible sources

A shallow test pass doesn’t prove much. Plenty of bad changes are locally correct and globally wrong.

The damage is social too

Open source has always run on a rough trust model. New contributors had to put in enough effort to understand the codebase, produce a patch, and survive review. That process filtered out a lot of noise.

AI removes a lot of that friction.

Sometimes that’s genuinely useful. A capable developer working in an unfamiliar language can get up to speed faster. Someone porting code between platforms can offload repetitive grunt work. Those are real gains.

But effort was also a trust signal. If someone can cheaply spray polished-looking patches across a dozen repos, maintainers lose one of the old heuristics. They have to review more skeptically, which slows things down and makes communities more guarded. Some projects are already moving toward gated contribution models, vouch systems, and tighter write access.

That trade-off matters. Open source gets resilience from being open. It also burns people out when openness turns into a spam channel.

Blender’s complaint about reviewer motivation deserves attention. Review is work, and in a lot of projects it’s volunteer work. If too much of that time gets wasted on LLM sludge, the best reviewers stop doing it. Quality drops with them.

Governance will change with the workflow

Expect more repositories to formalize trust and tighten intake rules over the next year.

Some of that is basic hygiene:

• stronger CODEOWNERS coverage for sensitive directories
• required reviewer approval on core modules
• branch protection and contributor reputation checks
• mandatory repro steps for bug reports
• failing tests required for bug-fix PRs
• auto-closing low-effort submissions that ignore formatting or lint failures

Some of it belongs at the platform level. GitHub and GitLab have every reason to build better reputation systems, triage queues, rate limits, and project-specific quality gates. Right now, too much anti-spam work falls on maintainers stitching together bots and policy files.

Security tooling gets pulled in harder too. If you’re reviewing more code from less trusted sources, then CodeQL, Semgrep, gitleaks, SBOM generation, OpenSSF Scorecards, and SLSA-style provenance checks stop looking optional. They’re imperfect, and they won’t catch architecture mistakes, but they do raise the floor.

There’s a cost problem too. More incoming PRs means more CI runs. If your repo builds across multiple architectures or runs expensive integration suites, AI-assisted drive-by contributions can turn into a real infra bill. Teams will respond with path-based CI triggers, incremental builds, build caches, and stricter limits on what runs for first-time contributors.

None of this is glamorous. It’s maintenance work.

What maintainers should do

Projects don’t need an outright ban on AI use. That would miss the point, and it probably wouldn’t work. They do need clearer boundaries.

Put more weight on tests

Require a failing test or a minimal repro for bug fixes. For parser, protocol, and input-heavy code, add fuzzing where it matters. Property-based testing helps too, especially with the edge-case regressions that neat-looking AI patches often introduce.

Coverage numbers matter less than test sharpness. A 90% badge won’t catch a subtle resource leak.

Add AI disclosure to CONTRIBUTING.md

Don’t ask contributors to swear off tools. Ask for accountability. They should disclose AI assistance, confirm they understand every line, and explain how they checked docs, specs, and provenance. That won’t stop bad submissions, but it makes expectations explicit and gives maintainers a clear basis for pushing back.

Tighten dependency policy

Model-generated patches have a bad habit of solving small problems by importing another package. In mature projects, that’s often a lousy trade. New dependency, new supply-chain surface, new update burden. Say so in the contribution guidelines and reject convenience imports aggressively.

Use automation to block obvious junk early

Formatting, lint, type checks, SAST, secret scanning, changelog enforcement, benchmark requirements for hot-path changes. Automate the basics so human review starts later in the funnel.

Use AI where it actually helps

Documentation updates, test scaffolding, repetitive refactors, codemod-style changes with strong test backing, porting boring glue code. That’s where assistants can be useful without dumping too much risk on reviewers.

For larger migrations, deterministic tooling still has an edge. OpenRewrite, jscodeshift, ts-morph, and language-specific refactoring tools produce changes that are easier to audit than a freeform model prompt.

If your team contributes upstream

If your company depends on open source and sends fixes back upstream, the bar is going up.

Maintainers will ask for cleaner repros, better tests, fewer vague bug reports, and contributors who can explain their patches under scrutiny. Using AI internally is fine. Shipping the review burden upstream isn’t.

That means doing the boring work before you open the PR:

• run static analysis locally
• trim unnecessary dependencies
• benchmark hot-path changes
• verify compatibility claims
• make sure the author can defend the patch without saying “the model suggested it”

A lot of teams still treat upstream contribution as a side effect of internal development. That approach will get ignored faster now.

Open source isn’t running short on code. It’s running short on trusted attention. That’s the scarce resource, and AI is chewing through it.