Open Source Didn't Ban AI Code. 83% of Its AI Policies Allow It, With One Catch
- Book: Prompt Engineering Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
---
July was the month open source "banned AI." On July 22, Codeberg members voted 358 to 144 to bar projects built mostly from AI-generated code (It's FOSS). About a week later, the GCC Steering Committee said it won't take a legally significant contribution if any part of it traces back to an LLM (It's FOSS).
Read the GCC rule to the end, though. Contributions under the legal-significance threshold (roughly 15 lines) can still come in if they are clearly marked, test cases are exempt, and AI-assisted work carries an Assisted-by: tag in the commit message. Even the "ban" is mostly a set of conditions.
Then look past the two headlines at the whole field. In September, Andre Hora, Romain Robbes and Stefano Zacchiroli published ["We Permit the Use of AI, but [...]"](arxiv.org), a study of 281 AI policies from the 2,000 most-starred GitHub repositories plus 36 well-known projects and organizations such as the Linux kernel, LLVM and the Apache Software Foundation. The title is the finding.
The numbers say "yes, but"
From the paper's results:
- 83.3% of policies permit or encourage AI in code contributions (76.2% permit, 7.1% encourage).
- 14.9% forbid AI in code. Only 5.3% forbid it for every kind of contribution.
- 67.3% require a high level of human involvement.
- 43.4% make the contributor accountable for the result. None of the 281 say accountability is optional.
- 48.8% require you to disclose AI use. Of the disclosure rules that say where, 64.7% want it in the PR description and 26.7% in the commit message.
So a ban is the minority position. What the majority asks for is a human who was there: someone who directed the work, read it, and will answer for it. The paper quotes the policy of psf/requests on this: "you must remove any LLM co-author tags and take full ownership of every line."
One thing the study leaves open, and the authors list it as future work: whether anyone actually follows these policies.
What maintainers actually do with slop
The paper counts 188 countermeasures against low-quality AI contributions across the policies. The breakdown:
| Countermeasure | Share |
|---|---|
| Close the PR | 48.4% |
| Ban or block the user | 20.8% |
| Disallow autonomous agents | 13.8% |
| Restrict new or external users | 4.8% |
| Everything else (six measures) | 12.2% |
Nearly half of all measures are the same move: close it. The rqlite policy says slop PRs "may be closed without comment," per the paper. rust-analyzer goes further and says it does not allow autonomous agents to open pull requests or issues at all.
Some projects now address the agent directly. The paper finds policies in AGENTS.md and CLAUDE.md as well as CONTRIBUTING.md and AI_POLICY.md. The contributing guide of llama.cpp tells fully autonomous agents not to contribute and to exclude the repo from their configuration.
My take: they banned the unread diff, not the model
Put the two findings side by side. Most projects accept AI code. The most common response to bad AI code is closing the PR. The deciding factor between those two outcomes is whether a human read the change before a maintainer had to.
A closed PR is a maintainer telling you the review didn't happen on your side, so it isn't going to happen on theirs. Reviewing a large agent diff costs real time, and maintainers are often volunteers. The policies push that cost back to the sender, which is fair. The diff can be cheap to generate. Someone still has to understand it, and the 67.3% requiring high human involvement is the field agreeing on who that someone is.
That moves the review upstream. If the reading has to happen, it should happen on your machine, before the PR exists. Once you open it, every unread line is a maintainer's problem.
Three steps before you open the PR
1. Read the project's policy first. It might live in a file you don't expect:
ls AI_POLICY.md LLM_POLICY.md AGENTS.md CLAUDE.md \
CONTRIBUTING.md 2>/dev/null
grep -inwE "ai|llm|agent|copilot" CONTRIBUTING.md \
2>/dev/null
Then follow its format. There isn't one standard. The paper notes RustPython asks for Assisted-by and not Co-authored-by, Nextcloud requires an Assisted-by trailer, and psf/requests wants LLM co-author tags gone entirely.
2. Read the change step by step. One big diff hides the step where the agent rewrote a file you didn't ask about. Start with the summary, then walk the branch commit by commit, oldest first:
git diff main...HEAD --stat
git log -p --reverse main..HEAD
The --stat line shows the file you didn't ask about. The log shows each step in order. If you can't explain a hunk, ask the agent to undo it or redo it smaller. "Full ownership of every line" starts here.
3. Disclose where the project asks. Git has a flag for trailers (git docs):
git commit -m "Fix off-by-one in pagination" \
--trailer "Assisted-by: Claude Code"
Then say it in the PR description too, since that's where most disclosure rules point: which agent, what it did, what you checked by hand.
Doing the reading in Hermes IDE
I build Hermes IDE, so weigh this section with that in mind. Everything above works with plain git. Hermes is built around that order of operations: the agent works and you read before you land.
Every agent turn is saved, so you can diff or restore any single turn, with undo. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows the changes by turn or by file, with risk flags, and a line comment goes back to the agent that wrote that line. That's the "read it turn by turn" step without scrolling one long diff (README).
!The Hermes Review Desk in By turn view, listing two turns of a Claude Code task with turn 1's diff of src/db.ts and a drafted commit message
The Review Desk (⌘G) in By turn view: two turns of a Claude Code task, turn 1's diff of src/db.ts, the changed files, and a commit message drafted from the turns.
Only after that does Land come in. It commits, opens a pull request or merges locally, into the branch the task started from, and it can be undone. Check that the commit message carries the trailer your project asks for before you land. Each task also runs on its own hermes/ branch and worktree, so the PR holds one task's work and nothing from the agent next door.
You can download Hermes. It is source-available under BSL 1.1 and runs on macOS, Windows and Linux. It runs Claude Code, Codex and other agents in their own terminals, with your own sign-ins. It isn't affiliated with Nous Research or its Hermes Agent. It can't make an agent's change good, but it gives you a place to check the change first.
Where do you draw the line?
If you maintain a project, does your policy say what "human involvement" means in practice? If you contribute, do you disclose the agent by default, or only when a project asks? Tell me in the comments.
---
If this was useful
Projects now write their AI rules into AGENTS.md and CLAUDE.md, which means a contribution policy is also a prompt. The Prompt Engineering Pocket Guide covers how to write instructions an agent actually follows, whether you're the maintainer writing them or the contributor whose agent reads them. If you'd rather review agent work turn by turn, Hermes IDE is the tool I build for exactly that.
Mentions
Open Source Didn't Ban AI Code. 83% of Its AI Policies Allow It, With One Catch - Book: Prompt Engineering Pocket Guide - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- July was the month open source "banned AI." On July 22, Codeberg members voted 358 to 144 to bar projects built mostly from AI-generated code (It's FOSS). About a week later, the GCC Steering Committee said it won't take a legally significant contribution if any part of it traces back to an LLM (It's FOSS). Read the GCC rule to the end, though. Contributions under the legal-significance threshold (roughly 15 lines) can still come in if they are clearly marked, test cases are exempt, and AI-assisted work carries an Assisted-by: tag in the commit message. Even the "ban" is mostly a set of conditions. Then look past the two headlines at the whole field. In September, Andre Hora, Romain Robbes and Stefano Zacchiroli published ["We Permit the Use of AI, but [...]"](arxiv.org), a study of 281 AI policies from the 2,000 most-starred GitHub repositories plus 36 well-known projects and organizations such as the Linux kernel, LLVM and the Apache Software Foundation. The title is the finding. The numbers say "yes, but" From the paper's results: - 83.3% of policies permit or encourage AI in code contributions (76.2% permit, 7.1% encourage). - 14.9% forbid AI in code. Only 5.3% forbid it for every kind of contribution. - 67.3% require a high level of human involvement. - 43.4% make the contributor accountable for the result. None of the 281 say accountability is optional. - 48.8% require you to disclose AI use. Of the disclosure rules that say where, 64.7% want it in the PR description and 26.7% in the commit message. So a ban is the minority position. What the majority asks for is a human who was there: someone who directed the work, read it, and will answer for it. The paper quotes the policy of psf/requests on this: "you must remove any LLM co-author tags and take full ownership of every line." One thing the study leaves open, and the authors list it as future work: whether anyone actually follows these policies. What maintainers actually do with slop The paper counts 188 countermeasures against low-quality AI contributions across the policies. The breakdown: | Countermeasure | Share | |---|---| | Close the PR | 48.4% | | Ban or block the user | 20.8% | | Disallow autonomous agents | 13.8% | | Restrict new or external users | 4.8% | | Everything else (six measures) | 12.2% | Nearly half of all measures are the same move: close it. The rqlite policy says slop PRs "may be closed without comment," per the paper. rust-analyzer goes further and says it does not allow autonomous agents to open pull requests or issues at all. Some projects now address the agent directly. The paper finds policies in AGENTS.md and CLAUDE.md as well as CONTRIBUTING.md and AI_POLICY.md. The contributing guide of llama.cpp tells fully autonomous agents not to contribute and to exclude the repo from their configuration. My take: they banned the unread diff, not the model Put the two findings side by side. Most projects accept AI code. The most common response to bad AI code is closing the PR. The deciding factor between those two outcomes is whether a human read the change before a maintainer had to. A closed PR is a maintainer telling you the review didn't happen on your side, so it isn't going to happen on theirs. Reviewing a large agent diff costs real time, and maintainers are often volunteers. The policies push that cost back to the sender, which is fair. The diff can be cheap to generate. Someone still has to understand it, and the 67.3% requiring high human involvement is the field agreeing on who that someone is. That moves the review upstream. If the reading has to happen, it should happen on your machine, before the PR exists. Once you open it, every unread line is a maintainer's problem. Three steps before you open the PR 1. Read the project's policy first. It might live in a file you don't expect: ls AI_POLICY.md LLM_POLICY.md AGENTS.md CLAUDE.md \ CONTRIBUTING.md 2>/dev/null grep -inwE "ai|llm|agent|copilot" CONTRIBUTING.md \ 2>/dev/null Then follow its format. There isn't one standard. The paper notes RustPython asks for Assisted-by and not Co-authored-by, Nextcloud requires an Assisted-by trailer, and psf/requests wants LLM co-author tags gone entirely. 2. Read the change step by step. One big diff hides the step where the agent rewrote a file you didn't ask about. Start with the summary, then walk the branch commit by commit, oldest first: git diff main...HEAD --stat git log -p --reverse main..HEAD The --stat line shows the file you didn't ask about. The log shows each step in order. If you can't explain a hunk, ask the agent to undo it or redo it smaller. "Full ownership of every line" starts here. 3. Disclose where the project asks. Git has a flag for trailers (git docs): git commit -m "Fix off-by-one in pagination" \ --trailer "Assisted-by: Claude Code" Then say it in the PR description too, since that's where most disclosure rules point: which agent, what it did, what you checked by hand. Doing the reading in Hermes IDE I build Hermes IDE, so weigh this section with that in mind. Everything above works with plain git. Hermes is built around that order of operations: the agent works and you read before you land. Every agent turn is saved, so you can diff or restore any single turn, with undo. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows the changes by turn or by file, with risk flags, and a line comment goes back to the agent that wrote that line. That's the "read it turn by turn" step without scrolling one long diff (README). !The Hermes Review Desk in By turn view, listing two turns of a Claude Code task with turn 1's diff of src/db.ts and a drafted commit message The Review Desk (⌘G) in By turn view: two turns of a Claude Code task, turn 1's diff of src/db.ts, the changed files, and a commit message drafted from the turns. Only after that does Land come in. It commits, opens a pull request or merges locally, into the branch the task started from, and it can be undone. Check that the commit message carries the trailer your project asks for before you land. Each task also runs on its own hermes/ branch and worktree, so the PR holds one task's work and nothing from the agent next door. You can download Hermes. It is source-available under BSL 1.1 and runs on macOS, Windows and Linux. It runs Claude Code, Codex and other agents in their own terminals, with your own sign-ins. It isn't affiliated with Nous Research or its Hermes Agent. It can't make an agent's change good, but it gives you a place to check the change first. Where do you draw the line? If you maintain a project, does your policy say what "human involvement" means in practice? If you contribute, do you disclose the agent by default, or only when a project asks? Tell me in the comments. --- If this was useful Projects now write their AI rules into AGENTS.md and CLAUDE.md, which means a contribution policy is also a prompt. The Prompt Engineering Pocket Guide covers how to write instructions an agent actually follows, whether you're the maintainer writing them or the contributor whose agent reads them. If you'd rather review agent work turn by turn, Hermes IDE is the tool I build for exactly that. 
changing the cwd is indeed a simpler fix than handling the link by ra itself. but actually we should do the opposite, it should set the cwd to the package root instead of the (default) workspace root. the cargo test command will always run the tests from the package root, so the stacktrace printer "normalize" the paths relative to it. however, the vscode auto file link detection will try to resolve relative paths based on the cwd when the task is initially launched^though this is the behavior I observed, I'm not sure if this is documented by vscode. [this might be related, or at least interesting to dig into], not some child processe's (the test binary's, in this situation) runtime cwd when the message is printed. as long as the launching cwd is consistent with the runtime behavior, vscode will resolve the relative path to the correct uri and open it. I think ra already has a code path to set the cwd for code lens actions, e.g. I found this pr related to cwd and the debug code lens: rust-analyzer#17275 for this one, I think we just need a small change for the test code lens case.
Agree that the domain and time scales matter a lot. When working on systems where nanoseconds were quite important, time was given significant attention. However in general - I agree with OP. Most of the time I care about milliseconds. > Sounds like the author’s experience is strictly in Python. Er [1], no [2]. [1] rust-lang/rust-analyzer [2] tigerbeetle/tigerbeetle