While AI coding assistants have become standard tools for software development, a growing number of open source projects are outright banning AI-generated contributions. Zig, NetBSD, GIMP, Gentoo, and qemu now reject pull requests containing LLM-generated code. The reasoning goes deeper than code quality concerns. It fundamentally challenges how we think about community contribution in an AI-augmented world.

Aspect	Key Point
Projects with AI bans	Zig, NetBSD, GIMP, Gentoo, qemu, Redox OS
Core philosophy	”Contributor Poker” prioritizes people over code
Linux kernel approach	Requires Assisted-by tag with human accountability
Main concern	Maintainer time spent on reviews yields no long-term contributor value

The Contributor Poker Philosophy

Zig Software Foundation VP of Community Loris Cro published “Contributor Poker and Zig’s AI Ban” on April 30, 2026, articulating why the project maintains one of open source’s strictest anti-AI policies. The explanation reveals a fundamentally different view of what open source contribution means.

The core insight: “You play the person, not the cards.” In contributor poker, maintainers bet on the contributor’s long-term potential rather than evaluating individual pull requests in isolation. The time spent reviewing a first-time PR represents an investment in building a relationship with someone who might become a trusted, prolific contributor.

LLM assistance breaks this calculation entirely. Even if an AI helps you submit a technically perfect PR, the time Zig’s team spends reviewing your work does nothing to help them identify new, confident, trustworthy contributors. If the code came from an LLM, maintainers might reasonably ask why they should review it when they could use their own LLM to solve the problem directly.

This philosophy matters for AI engineers building production systems because it reveals a tension between AI-augmented productivity and human relationship building that extends beyond open source.

What Problems Actually Drove These Bans

The bans emerged from documented, repeated problems that drained maintainer energy without producing value:

Drive-by contributions: PRs containing hallucinated code that would not compile, let alone pass CI. These required time to review and reject without any possibility of the contributor learning from the feedback.

Extreme first submissions: Multiple projects reported receiving 10,000+ line PRs from first-time contributors, an obvious sign of AI generation that creates massive review burden with minimal likelihood of productive iteration.

Deceptive behavior: Contributors explicitly denied LLM use during review discussions, only for follow-up technical conversations to reveal otherwise. This eroded the trust that makes contributor poker work.

The cURL bounty shutdown: Daniel Stenberg closed cURL’s bug bounty after AI-generated submissions hit 20%, demonstrating that even incentive-aligned contributions became unsustainable.

Understanding AI coding agent safeguards provides context for why maintainers increasingly treat AI-generated code as a risk rather than an opportunity.

The Linux Kernel’s Middle Ground

Not every project chose outright bans. Linus Torvalds called the debate “pointless posturing” and pushed the Linux kernel toward a pragmatic middle ground. The kernel now requires an Assisted-by tag for AI-generated contributions and enforces strict human liability.

This approach strips emotion from the debate by focusing on accountability. AI becomes just another tool in the development process. The human developer remains responsible for understanding, testing, and maintaining the code they submit. If problems emerge later, the human takes the fall.

The kernel’s scale makes this practical. With thousands of contributors and established trust hierarchies, maintainers can evaluate submissions based on contributor reputation rather than scrutinizing every line for AI involvement.

For smaller projects without these trust structures, blanket bans remain the more efficient policy. Review time is the scarcest resource in open source. Projects must decide whether to spend it vetting AI-generated submissions or developing human contributors who might provide value for years.

Why This Matters for AI Engineers

If you use AI coding tools daily, which most developers now do, these policies create a practical challenge. How do you contribute to open source projects that ban AI assistance?

The answer requires understanding what “AI-generated” actually means in these contexts:

Clearly prohibited: Pasting problems into ChatGPT and submitting the output as your contribution. Using AI to generate large chunks of code you do not understand. Letting AI write commit messages or PR descriptions.

Generally acceptable: Using AI to explain existing code in the project. Having AI suggest approaches that you then implement yourself. Using AI-powered IDE features like autocomplete, though some strict projects prohibit even this.

Project-specific: Each project defines its own boundaries. Zig’s policy states “No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker, including translation.” Other projects may be more permissive.

Before contributing to any open source project, check their contribution guidelines for AI policies. This has become as important as understanding their code style requirements or testing expectations.

The Trust Economics Behind AI Bans

Projects banning AI contributions are making a calculated trade-off. They accept potentially missing some good contributions in exchange for:

Preserving maintainer time: Every minute spent reviewing AI-generated code is a minute not spent mentoring human contributors who might become long-term assets.

Maintaining relationship investment: Open source thrives on accumulated social capital. Maintainers who know contributors’ strengths and growth trajectories can delegate effectively. AI-generated contributions provide no path to this trust.

Avoiding hidden maintenance burden: Code submitted by someone who does not understand it creates orphaned functionality. When bugs emerge or requirements change, the original contributor cannot help fix issues they never understood.

Warning: If you are considering AI-assisted contributions to a project with explicit bans, reconsider. The projects are not making these decisions arbitrarily. Violating contribution policies, especially through deception, can result in permanent bans from communities you might want to join.

How to Contribute Effectively Despite AI Tool Use

The most successful approach separates your personal productivity tools from your contribution workflow:

Learn the codebase first: Use AI to accelerate your understanding of a project’s architecture, but develop genuine familiarity before attempting contributions. Read issues, understand the roadmap, engage in discussions.

Start small: Projects that play contributor poker are betting on your growth trajectory. A small, well-understood fix demonstrates more potential than a large AI-generated feature.

Engage in review discussions: When maintainers provide feedback, respond thoughtfully. This demonstrates you understand the code and can evolve it. AI cannot maintain ongoing relationships with maintainers.

Build reputation incrementally: Contributor poker rewards consistency over time. Multiple small contributions that show increasing familiarity create trust that opens doors to larger work.

These principles align with effective AI engineering community practices where reputation and demonstrated expertise matter more than any single contribution.

The Broader Industry Implications

The open source AI contribution debate reflects larger tensions in software development. As AI tools become more capable, several questions become pressing:

Attribution and ownership: Who owns code that an AI helped write? If you used Claude to refactor a function, is that still your contribution?

Skill development: If developers rely heavily on AI assistance, are they building the deep understanding needed to maintain and evolve systems over time?

Community sustainability: Open source has always depended on contributors who grow into maintainers. If AI shortcuts this development path, where do future maintainers come from?

These questions do not have easy answers. But understanding why projects like Zig chose strict bans helps frame the trade-offs every AI-augmented developer navigates daily.

Frequently Asked Questions

Can I use GitHub Copilot when contributing to Zig?

No. Zig’s policy prohibits LLM assistance in any form for contributions, including IDE-integrated tools like Copilot. This is stricter than most projects.

How do I know if a project bans AI contributions?

Check the project’s contribution guidelines, Code of Conduct, or README. Projects with explicit policies typically state them clearly. When in doubt, ask maintainers directly.

What if I used AI to understand code but wrote the contribution myself?

This falls in a gray area that varies by project. Strict projects like Zig prohibit any LLM involvement. More permissive projects care primarily about whether you understand and can maintain the code you submit.

Will more projects adopt AI bans?

The trend is growing but not universal. Security-critical projects and those with limited maintainer bandwidth are more likely to implement bans. Large projects with established trust hierarchies may prefer accountability-based approaches like the Linux kernel’s Assisted-by tag.

Recommended Reading

• AI Coding Assistants Guide for Engineers
• AI Coding Agent Production Safeguards
• AI Community vs Self Study
• AI Career Path Engineering Focus

Sources

• Contributor Poker and Zig’s AI Ban - Loris Cro, Zig Software Foundation

The debate over AI in open source will not settle quickly. But for AI engineers navigating this landscape, the principles remain clear: understand projects’ policies before contributing, build genuine expertise rather than relying on AI shortcuts, and invest in the relationships that make open source communities work.

To learn more about building AI systems that work in production, watch the full video tutorial on YouTube.

If you want to accelerate your AI engineering career with guidance from experienced practitioners, join the AI Engineering community where members follow 25+ hours of exclusive AI courses, get weekly live coaching, and work toward high-paying AI engineering roles.