AI Disclosure Beats Banning AI Code in Open Source Projects

Two things landed in open source the same week, and they read like opposite sides of a war.

On August 4, the essayist Fogus published "Born Against," arguing that hobby and craft communities reject AI coding tools for a reason that has nothing to do with quality.^[2]

A day later, Rust announced a policy: fine to use a model to review, analyze, or check, but not to create, with disclosure required when you do.^[3]

Every thread on both split into the same two camps: ban it, or allow it. That framing skipped a question nobody could answer with data until four days ago. When a project actually adopts an AI policy, what happens to the code and the community?

Why do some programmers reject AI coding tools?

Because in a craft community, the struggle is the product. That case deserves to be stated at full strength before any data enters the room, because it is not a quality argument and no benchmark refutes it.

Fogus names the communities precisely: chess engines, operating-system development, language development, emulator development, the demoscene, code golf. In these places, as he puts it, "the process of mastering a difficult field itself is the product, and something that runs is generally a nice-to-have." The finished artifact was never the point.

That is a claim about apprenticeship, not about defect rates. It is also the argument most likely to be dismissed as nostalgia by people who have never belonged to a community like that. It should not be.

Should open-source projects ban AI code?

The first large-scale evidence says a ban is not the highest-leverage move available. A team analyzed 29,624 repositories, identified 385 that had adopted an AI policy, and measured what changed in the eight weeks after adoption against matched projects that had not.^[1]

The direction of every result was the same. Code smells fell about 16%. Reported vulnerabilities fell about 11%. Cognitive complexity fell about 17%. Active contributors rose about 13%, and AI-assisted contributions kept growing rather than disappearing.

The finding that reframes the fight comes in the authors' own words:

AI governance primarily regulates rather than prohibits AI-assisted development.

Most policies in the wild are not bans. And the ones that worked best were the least prohibitive: the paper reports that policies "emphasizing transparency and responsibility produced stronger community and quality outcomes than restrictive approaches alone."

Read that carefully, because it is easy to overclaim. The study does not show that bans backfire. It shows that projects adopting policies improved, that most of those policies regulate rather than prohibit, and that the transparency-first ones outperformed the restrictive ones.

The authors sort what a policy can ask for into five dimensions, which is a useful checklist even if you never read the paper: transparency, responsibility, attribution, constraints, and enforcement. The comparison that produced the finding above set policies emphasizing the first two against restrictive approaches alone, rather than testing each dimension on its own.

Does requiring disclosure actually improve a project?

In the study's window, yes, and the mechanism is the interesting part. Disclosure of AI assistance rose about 11%. Review got richer: about 8% more review turns per pull request, and about 4% more reviewers on each one. More eyes, more rounds, on work that was now labeled.

That is the answer to the craft objection rather than a dismissal of it. The purist fear is that AI-generated work slides in unannounced and hollows out the review-and-apprenticeship culture.

Disclosure attacks exactly that failure. It does not reduce the amount of AI in the tree. It makes that AI visible enough for the community to do the thing it actually values, which is look hard at the work.

Why a ban does not do the work

There is also a mechanical reason bans fall short of what maintainers hope for. Agents do not read your contribution rules.

A benchmark of coding agents found they almost never retrieve a repository's stated rules, and never once refused to contribute to a project that bans AI-generated code.^[4] We covered that finding when it landed, and it is why the bans keep appearing in the first place: the soft rules were provably ignored.

A ban, in other words, is a sign on a door the agent cannot see, which leaves enforcement where it always was: with the humans.

What the evidence does not settle

It is one study, and its limits matter as much as its numbers. This is matched-observational work, not a randomized trial, so projects that chose to adopt a policy may differ from those that did not in ways the matching cannot fully remove. The window is eight weeks. It is a first-version preprint.

What raises the credibility is that the authors published a full replication package, so the analysis can be checked rather than taken on faith.

And the craft objection sits entirely outside what any dataset can decide. Whether a community should want its members to struggle through a hard problem is a question about what that community is for. Fogus is not making a claim the study can test, and the study is not making a claim that answers him.

What should a maintainer actually do?

Write the policy that makes contributions visible and reviewable, then put the enforcement in review where it can work:

• Ask contributors to disclose AI assistance, and to own the result either way.
• Hold that code to the same review bar as everything else, which is where the quality gains in the study came from.
• Attribute it, so the project's history stays honest.
• Skip the rule you cannot enforce. The agent will not read it, and it costs you the visibility you actually need.

Rust's policy is a working template for the shape. It permits the uses where a model helps and forbids the one the project cares most about, requires disclosure, and puts the weight on human judgment, which is why its author writes that "reviewing is made of decisions."

That lands where the rest of the measured evidence on AI-native work keeps landing. The scarce human contribution is judgment, not typing, whether you are measuring what context files buy or measuring productivity honestly.

Governance that maximizes visible, reviewable work puts human judgment back in the middle, which is what these communities wanted all along.

Ban or allow was never the real axis. Visible or invisible is.

A prohibition you cannot enforce does not remove AI-assisted contribution from your project. It removes your ability to see it. The evidence says the projects that chose to see it got better code and more people, while keeping the craft the purists are right to protect.