- 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 [...]", 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 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.
Top comments (0)