Open-Source Projects Are Banning AI Coding Agents — Here'...

When Andrew Galkin (BurntSushi) added an AI_POLICY.md to ripgrep — a tool with 64,000+ GitHub stars used by basically every developer on the planet — it wasn't a small event. It was a line in the sand.

The policy is direct: autonomous agents are not allowed to contribute. PRs that appear to come from agents will be closed, possibly without notice. AI-assisted coding is fine. A human who used Copilot to write a patch? Welcome. But an agent that opened a PR on its own? Rejected.

Ripgrep didn't invent this. The policy was adapted from Astral's uv (85,000+ stars) and ruff (47,000+ stars) projects, which have had similar AI policies since early 2026. Together, these three projects form the backbone of most Python and Rust developer toolchains. Their stance matters.

What the Policies Actually Say

The policies from Astral (uv, ruff) and ripgrep share nearly identical language. Here's what they agree on:

1. AI-assisted coding is welcome. Using Copilot, Cursor, or Claude Code to help you write code? Completely fine. The policy explicitly supports this.

2. You own what you ship. If you submit a PR, you're responsible for understanding every line — whether you typed it or an AI suggested it. "I didn't write that, the AI did" is not an acceptable defense.

3. Autonomous agent PRs are banned. This is the critical line. If a PR appears to come from a fully autonomous agent — one that independently decided to find a bug, write a fix, and open a pull request — maintainers will close it.

4. Don't use AI to write comments. Issue descriptions, PR body text, and replies to maintainer questions must be written by humans. AI-generated comments may be hidden without notice.

5. AI context is allowed in quotes. If you want to include AI output in a comment, put it in a quote block (>) and add your own human explanation of why it's relevant.

6. Non-native English speakers get grace. AI for translation or grammar editing is explicitly supported, but you're expected to ensure the output reflects your actual voice and ideas.

Why This Is Happening Now

Three forces are converging:

The Agent PR Flood

Autonomous coding agents like Devin, OpenHands, SWE-Agent, and various GPT-wrapper bots have started opening PRs on popular open-source repos. Some are good. Many are not. All of them create work for maintainers who have to review, test, and respond to them.

A maintainer of a project with 60,000+ stars doesn't have time to explain to a bot why its patch breaks the build on a niche platform. The signal-to-noise ratio is collapsing.

The "I Don't Understand My Own PR" Problem

We covered this in our piece on AI coding agent maintenance costs: when developers submit AI-generated code they don't fully understand, the maintenance burden shifts to reviewers and future contributors. For a single-person-maintained project like ripgrep, that burden is existential.

BurntSushi wrote a detailed essay in 2024 about the challenges of maintaining ripgrep alone. Adding a flood of AI-generated patches he has to carefully vet — patches where the submitter can't explain the edge cases — isn't help. It's liability.

The Accountability Gap

Open-source maintainers are legally and reputationally responsible for what they ship. If a dependency gets compromised through a sloppy AI-generated PR, the maintainer's name is on the commit. The AI that wrote the code has no accountability, no reputation to protect, and no skin in the game.

What This Means for Developers Using AI Tools

If you use Cursor, Claude Code, Copilot, Windsurf, or any of the coding agents we track, here's the practical takeaway:

You're Fine (Probably)

All of these policies explicitly support AI-assisted development. Using Copilot to autocomplete a function? Using Cursor to refactor a module? Using Claude Code to understand a codebase? All welcome. The issue is autonomy, not assistance.

The Line: Can You Explain Your Own PR?

Before opening a PR — whether to ripgrep, uv, or any major OSS project — ask yourself: can I explain every line of this change in my own words? Can I defend the design decisions? Can I describe the edge cases?

If the answer is no, you're not ready to submit, regardless of whether an AI helped you write it.

Don't Let Your Agent Run Free on Others' Projects

If you're using an agent like Claude Code with MCP tool calling to autonomously fix issues across your dependency tree, stop before it opens PRs on projects you don't maintain. Many projects will close those PRs immediately. Some may block your account.

Read the CONTRIBUTING.md First

More projects are adding AI policies. Before contributing to any popular open-source repo, check for AI_POLICY.md, CONTRIBUTING.md sections on AI usage, or similar guidelines. If none exists, default to the ripgrep/uv standard: AI-assisted yes, autonomous no, human accountable always.

The Bigger Picture: Who Maintains AI-Generated Code?

This isn't just about open-source etiquette. It's about a fundamental tension in the developer AI stack:

AI coding agents can generate code faster than humans can review it. That's the entire value proposition. But code generation isn't the bottleneck in software — code understanding is. The hard part of software engineering has never been typing. It's knowing what to type, why, and what happens when things go wrong.

When an AI generates a 500-line PR that passes tests but introduces a subtle concurrency bug, the human who reviews it needs to understand concurrent programming deeply enough to catch what the tests missed. That human is usually a maintainer doing this for free.

The ripgrep/uv policy is a rational response: we'll accept AI-assisted work from humans who demonstrate understanding, but we won't accept work from entities that can't be held accountable.

What Should Agent Builders Do?

If you're building AI agents or agent frameworks, this trend should inform your design:

1. Default to local-only actions. Agents should fix code locally, run tests locally, and let the human decide whether and how to submit.

2. Never open PRs autonomously on external repos. This should be an explicit capability gate, not a default behavior.

3. Generate contribution-ready context. Instead of a PR body, generate a summary the human can use to write their own PR description.

4. Surface understanding, not just output. The best agent-assisted PRs include explanations of why the change is correct, not just what changed.

The Evaluation Criteria That Matters

For teams evaluating coding agents, add this to your checklist alongside the usual latency, cost, and accuracy metrics:

Criterion	Why It Matters
Autonomy boundaries	Can you prevent the agent from opening external PRs?
Human-in-the-loop enforcement	Does the agent require explicit approval before taking external actions?
Code explanation quality	Can the agent explain its changes well enough for a human to defend them in code review?
Test generation	Does the agent write tests for its own changes, or just the implementation?
Edge case awareness	Can the agent identify and articulate edge cases in its generated code?

Where We're Headed

The ripgrep and uv AI policies won't be the last. As coding agents become more capable and more autonomous, expect this to become a standard part of CONTRIBUTING.md across the ecosystem. Some projects may adopt more permissive policies — explicitly allowing agent contributions with certain guardrails. Others may go further and ban even AI-assisted code.

The most likely outcome: a tiered system where projects declare their AI comfort level, agents respect those declarations via automated checks (imagine a x-ai-policy header in GitHub responses), and developers operate within those boundaries.

Until then, the rule is simple: use AI to write better code, not to avoid understanding it.

NeuralStackly tracks 1,000+ AI tools for developers and builders, including coding agents, code review tools, and testing/eval infrastructure. All benchmarks, pricing, and comparisons are free to explore.