Keith Haring-style illustration of figures running toward a laptop with code, carrying laptops with AI logos, under an open source logo, while a reviewer gives a cross and a check and a crowd watches

LLMs Are Changing Open Source Too

·7 min readopen sourcellmaipull request

In January 2026, tldraw announced it would automatically close pull requests from external contributors "until GitHub provides better tools for managing contributions", and curl announced the end of its bug bounty. In June, GitHub shipped a setting that caps open PRs from users without write access, and two weeks later Godot banned autonomous AI agents and substantial AI-generated code. In September, Apache Airflow set that cap to five. This month, Google suspended its open source bug bounty.

These look like separate decisions, but they share a cause: contributions are growing faster than anyone can review them.

More code, same reviewers

The clearest numbers come from GitHub. In an April availability update, CTO Vlad Fedorov wrote that GitHub began planning for 10x capacity in October 2025, and by February concluded it needed 30x. He attributes the surge to agentic workflows, with merged pull requests peaking at 90 million and commits at 1.4 billion. In a June Latent Space interview, COO Kyle Daigle said of commits and PRs: "we're doing more in a month than we did in a year last year."

Maintainers see the same shape. According to tldraw's founder, Excalidraw received more than twice as many PRs in Q4 2025 as in Q3. Review capacity hasn't kept up. Automated code review exists, but many projects still want a person to review every change. Godot requires every PR to be "reviewed and approved by a human before merging", and Envoy treats its AI review agent as "an aid to the reviewer, not to the PR author". The bottleneck is human attention.

Four patterns in how projects respond

Reading the policies of about two dozen projects, mostly large and visible ones, I see four patterns.

1. Allow it, with disclosure and accountability

This is the most common approach: use AI if you like, but you must understand, and be able to explain, what you submit. Examples include Kubernetes, LLVM, NumPy, scikit-learn, Homebrew, Envoy, containerd and Arrow. They differ on attribution: the Linux kernel and Kafka ask for a commit trailer naming the tool, while Kubernetes and Homebrew prohibit such trailers and want disclosure in the PR description.

2. Gate who can contribute

These projects change who can open a PR rather than how it was written, and not only large foundations do it. Besides tldraw, Streamlit paused PRs from outside its maintainer team in July, saying AI coding tools had pushed volume beyond what it could review sustainably. It now asks for issues and feature requests instead. Ghostty auto-closes PRs from first-time contributors whom no maintainer has vouched for. Godot asks contributors with three or fewer merged PRs to get permission before sending features or large refactors. Airflow's cap of five open PRs for non-committers is a softer version of the same idea.

3. Don't accept AI-generated contributions

Servo cites maintainer burden, security, copyright and ethics. Gentoo and QEMU cite copyright and provenance. Zig, Redox OS and GIMP have explicit bans, and NetBSD treats LLM output as tainted code that needs the core team's written approval. Godot is close to this group, though it still allows menial help such as code completion and regex.

4. Use AI on the maintainer side

Some projects limit outsiders' AI use while building it into their own workflows. Envoy allows AI-assisted review, and Airflow maintains AGENTS.md files and PR triage skills for its maintainers. The principle isn't "no AI" but "AI with someone accountable in the loop".

None of these policies stands still, and most revisions tighten. Kubernetes moved from AI-assisted PRs being "acceptable" and AI commit messages "discouraged" in November 2025 to "not allowed" in March 2026. Ghostty went from a disclosure rule in August 2025 to a standalone policy, a vouch system and a denouncement list. LLVM's 2024 policy was about copyright, and its January 2026 rewrite is about maintainer time.

The same pressure in bug bounties

Bug bounties follow the same mechanics: cheap, plausible output meets limited human review, with a payout attached. curl ended its bounty citing a drop in the share of reports confirmed as vulnerabilities, from north of 15% to below 5%. HackerOne's Internet Bug Bounty paused new submissions from March 27, and Nextcloud ended its bounty on April 22. Google suspended its open source program over automated submissions, "the vast majority of which are not valid", and promised an update in Q1 2027.

It isn't only noise. AI also finds real bugs, and the Internet Bug Bounty paused because discovery now outpaces maintainers' capacity to fix. Either way, someone has to review.

The counterweight: providers supporting maintainers

The companies building the models are also investing in maintainers:

  • Anthropic, Claude for Open Source. Six months of Claude Max 20x for up to 10,000 maintainers and contributors, with eligibility tracks that include popular packages, foundation committers and critical infrastructure.
  • OpenAI, Codex for Open Source. Six months of ChatGPT Pro with Codex, API credits and selective access to Codex Security for core maintainers, building on a $1 million Codex Open Source Fund.
  • GitHub. Free Copilot Pro for maintainers of popular repositories, and, with CNCF, Copilot Enterprise for CNCF maintainers.
  • Funding. In March, Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft and OpenAI jointly gave $12.5 million to Alpha-Omega and OpenSSF, partly to help maintainers handle AI-generated security reports.

So projects limit AI-generated contributions while providers hand maintainers the same tools. The two fit together, since the programs mostly target triage, review and security work. Still, credits don't buy review attention, and that is the scarce resource.

What I expect in 2027

  • Gating moves into the platform. Projects build it themselves today with vouch lists and spam bots, and GitHub's PR cap is a first platform-level step. I expect trust signals such as account history and bypass lists to become standard settings.
  • Policies converge on a short core. Disclosure plus "you must be able to explain it" is already close to universal. Attribution is the loose end, and the kernel's switch from naming the model to a generic Assisted-by: LLM hints at where it settles. I don't expect an MIT-style standard, because projects make different governance choices: some ban, some gate, some allow. More likely are reusable templates, closer to the Contributor Covenant or the DCO, with a few presets that foundations publish and projects pick from.
  • More AI on the maintainer side. With review load still growing, triage and first-pass review agents are the obvious response. The open question is accountability: who answers for an agent's approval or rejection?
  • Open source bounties return in a different form. Google's Q1 2027 update is the first test. I expect returning programs to pay for reproducible, patch-ready findings, and funders to shift money from discovery to remediation.
  • Contributions shift away from raw code. If code is cheap, the scarce things are context, reproducers and judgment. Expect more projects to prefer issues, design discussion and verified bug reports over patches, and to accept code mainly from people with a track record.

Much of the work around code is moving to LLMs: writing, triage, first-pass review, even security fixes. What open source depends on is still human. Someone has to decide what belongs in the project, take responsibility for what ships, and extend trust to the next contributor. LLMs made producing a contribution cheap without making that judgment any cheaper, so human attention stays the bottleneck.

That doesn't end open source as a model. Companies still have good reasons to build in the open: adoption, shared standards, and users who find bugs and shape the roadmap. tldraw and Streamlit still do, while changing who can send them code. The likely result isn't less open source but a different shape: open to read, use and report on, and more selective about who writes the code that ships.