The open source fight over AI and vibe coding isn’t slowing down

The open source world is in the middle of a cultural shift. It’s no longer just about which license you use or which language you prefer. The new dividing line is whether you allow AI in your development workflow – or ban it completely.

On one side are platforms and projects building around AI-assisted coding and agents. On the other are communities that see AI as a threat to software freedom, code quality, and the sustainability of real human contributors. In between is a growing group of developers who don’t love AI, but feel it’s getting harder and harder to avoid.

How AI and “vibe coders” entered the FOSS world

As large language models (LLMs) like ChatGPT became widely available, a new kind of contributor started showing up in open source: people using AI to rapidly generate entire projects or big chunks of code, often with minimal understanding of what they were submitting. These are sometimes called “vibe coders” – developers who rely heavily on AI, spin up impressive-looking repos, but may not have a real community or user base behind them.

From the outside, these projects can look extremely active: constant commits, heavy CI/CD pipelines, multi-platform builds, and frequent binary releases. But maintainers are noticing a pattern: the amount of infrastructure and activity often far exceeds the actual number of real users. It’s a kind of AI-fueled illusion of momentum.

This tension – between traditional, community-driven projects and AI-boosted solo efforts – is now showing up directly in platform policies and project rules.

Codeberg: AI allowed, but not for “vibe-coded” projects

Codeberg, a popular Git hosting platform focused on free and open source software, has taken a cautious middle path. In a post about “protecting our FOSS commons from LLMs,” they raised two big concerns:

• Infrastructure strain: aggressive web crawlers from AI companies hammering their servers to scrape code for training.

• Rising hardware costs: storage and infrastructure are getting more expensive, making it harder to host ever-growing amounts of low-value or AI-generated content.

Codeberg’s updated terms of service don’t ban AI outright. Instead, they draw a line between:

• Established, human-driven projects that may use AI as a tool, have a history predating LLMs, active maintainers, and real users.

• Heavily AI-driven or agent-created projects with little human activity, no real community, and code that’s largely generated rather than developed.

The first group is welcome to stay. The second group is now “on the chopping block.” Codeberg is signaling that it wants to support real communities, not endless AI-spawned repositories that nobody maintains or uses.

SourceHut: a near-total ban on AI assistance

SourceHut has taken a much harder stance. As of September 10, 2026, its terms of service prohibit using LLMs or other generative AI tools to produce or assist with:

• Source code

• Assets

• Tickets and security reports

• Emails and other communication on the platform

There are a few key details in how this is enforced:

• No retroactive punishment: if you used AI in the past, your existing project can remain, as long as you stop using AI going forward.

• Case-by-case enforcement: potential violations will be evaluated individually, with room for exceptions.

• No harassment allowed: SourceHut will act against users who shame others for past AI use.

In practice, if you want to keep hosting your project on SourceHut, you must commit to not using AI assistance for future development. This makes SourceHut one of the strictest major platforms when it comes to AI in open source.

GitHub and GitLab: full steam ahead on AI integrations

While Codeberg and SourceHut are tightening their rules, the big commercial platforms are going in the opposite direction.

GitHub is deeply integrating AI into its platform, from GitHub Copilot to more advanced code suggestions and automation. GitLab is doing something similar, layering AI into issue management, code review, and development workflows.

They aren’t forcing anyone to use AI, but they are clearly designing for a future where AI assistance is a normal part of software development. For many developers, especially newer ones, this will make AI feel like the default way to work.

If you’re curious how strong open-source coding models are becoming, tools like Kimi’s open-source coding models are already pushing this space forward. For example, Kimi K2.6 as an open-source coding model shows how capable AI-assisted front-end work is starting to look.

Prompt injections and “canaries” to catch AI-generated commits

Some projects aren’t banning AI, but they are trying to detect it. One emerging technique is adding a kind of “canary” or prompt injection to a special file that AI agents are likely to read.

For example, NetworkManager added instructions in an AGENTS.md-style file telling any AI agent that reads it to include a specific, unusual word – “BiblioClipped” – in commit messages, merge requests, reviews, or other contributor communication. The idea is simple:

• If that word appears, maintainers know an AI blindly followed the prompt.

• Human contributors are extremely unlikely to use that word by accident.

Another project, Ghostty, did something similar, instructing AI tools to insert obviously embarrassing phrases like “I’m a sad, dumb little AI driver with no real skills.”

These tricks are easy to bypass if you know what you’re doing: you can avoid feeding the file to the AI, override the instructions, or filter out the injected text. But they are effective at catching low-effort “slop” – people pasting code from an AI tool without reading it or understanding it.

Agent files and mixed opinions on how to guide AI

Some large projects are debating whether to add explicit “agent files” – documents aimed at AI tools that describe project rules, style, and constraints. LLVM, for example, has an open RFC and a long discussion about adding such a file.

The community is split in several ways:

• Some are against AI entirely and don’t want to encourage its use.

• Some support AI but worry that repo-level prompts may actually reduce code quality, based on early research.

• Others see these files as a practical way to make AI outputs more aligned with project standards.

This shows an important nuance: even among people who are okay with AI, there is still real debate about how to integrate it responsibly.

The Linux kernel: cautious experimentation with AI

The Linux kernel is too big and too diverse to have a single, rigid stance on AI. Instead, it’s evolving a set of expectations and guidelines.

The kernel does have documentation on AI use: how contributors should handle AI-generated code, what’s acceptable, and how to attribute or review it. The overall principle is simple: you are responsible for the code you submit, no matter how you wrote it.

There are already tools like Sashiko, which use AI to review kernel code, find issues, or identify performance bottlenecks. Some parts of the kernel are more open to these tools than others. For example:

• Graphics subsystems tend to be more experimental (they were also early adopters of Rust).

• File systems or specific architectures may be more conservative.

One thing is clear: each release sees more AI-influenced code. It’s still a small percentage, but it’s growing. Even when AI generates ugly or “hideous” code, it can still surface important performance issues or optimization opportunities, such as speeding up kernel compilation.

Asahi Linux and the legal risk argument against AI

Not every project close to the kernel is comfortable with AI. Asahi Linux – the project bringing Linux to Apple Silicon – has taken a strong anti-LLM stance.

On their site, they lay out how generative AI can harm:

• Software freedom and open source communities

• The open internet and digital privacy

• User consent and developers themselves

They also link to SourceHut’s policy as an example of the direction they support.

Asahi has a particularly strong reason to be cautious: they are already operating in a legally sensitive space, reverse-engineering proprietary Apple hardware. Introducing AI-generated code with unclear licensing or provenance could create extra legal risk, especially if it accidentally reproduces copyrighted or proprietary material.

GNOME projects: a growing block of AI-free software

In the GNOME ecosystem, a different kind of resistance is forming. There isn’t yet a GNOME-wide LLM policy, but many individual projects and teams are saying “no AI” on their own.

This started visibly with the image viewer Loupe, which explicitly rejected AI-generated code. Other GNOME projects followed, and the stance has spread to:

• The GNOME Extensions website, which doesn’t want AI-generated extensions.

• GNOME Circle projects, which have adopted similar rules.

Many maintainers in these projects also work on core GNOME components. So even without an official, top-level ban, there’s a strong cultural expectation: if you show up with AI-generated code, don’t expect a warm reception.

It wouldn’t be surprising if, eventually, GNOME adopts a formal, project-wide AI policy that largely continues this trend.

KDE: no hard policy, but accountability first

On the KDE side, the picture is more relaxed. There’s no strong, formal policy for or against AI yet.

The current informal approach looks like this:

• If the code is good and you can explain it, it’s likely to be accepted, regardless of whether AI helped you write it.

• Low-effort, unexplained, or obviously misunderstood contributions will be rejected, AI or not.

This is similar to how many large projects already operate: tools don’t matter as much as the contributor’s understanding and willingness to take responsibility.

When maintainers use AI vs. when contributors do

An interesting pattern is emerging: some developers who are publicly skeptical or critical of AI become more open to it when they are the ones in control of how it’s used.

What they often object to is not the tool itself, but:

• Being flooded with AI-generated bug reports, security reports, or patches that are wrong or low quality.

• Not knowing whether a contributor understands the code they’re submitting.

For example, Daniel Stenberg (curl’s maintainer) has been vocal about the damage caused by low-value, AI-generated security reports. It got bad enough that curl temporarily shut down its bug bounty program because so many reports were garbage.

But when a tool like Mythos came along – using AI to help analyze issues in a more controlled way – he was open to experimenting with it, as long as it didn’t create more noise for maintainers.

This highlights a key distinction: many maintainers are okay with using AI themselves to assist their work, but strongly opposed to reviewing endless AI-generated submissions from others.

Users pushing back: the GrapheneOS example

It’s not just maintainers who have opinions. Users are starting to care whether their favorite privacy or security-focused projects use AI at all.

GrapheneOS, a security- and privacy-focused Android fork, recently announced updates to some of its applications, including the camera app. When users discovered that AI tools were used for testing, code review, and generating tests, some reacted very negatively.

On platforms like Hacker News, the discussion quickly turned into a backlash, with many replies criticizing any use of AI in a project positioned around privacy and trust. Even though AI was used mainly as an internal tool, not baked into the product itself, the reaction shows how emotionally charged this topic has become.

The next generation of developers is growing up with AI

One of the biggest unknowns is what future contributors will look like. People teaching programming today often report that students are already heavily using AI tools for assignments, debugging, and even entire projects.

This raises some big questions for the future of open source:

• Will AI-native developers be interested in contributing to projects that ban AI?

• Will they prefer platforms and communities that embrace AI as a normal part of the workflow?

• Will AI-heavy projects burn out quickly, appearing and disappearing without long-term maintainers?

It’s possible that strictly no-AI projects become the equivalent of niche legacy stacks like COBOL: still important, but with a shrinking pool of people willing to work on them. It’s also possible that AI-heavy projects struggle to build real communities and quietly fade away.

We simply don’t know yet. What’s clear is that AI is reshaping how new developers learn, experiment, and think about software.

Many developers don’t like AI – but still use it

Another emerging trend: a lot of developers are conflicted. When asked whether they intentionally use AI in their work, responses often split roughly down the middle. But when you dig deeper, many who say “yes, I use it” also say “I don’t really like it.”

For many, AI feels like:

• A tool that’s too useful to ignore in the short term.

• Something they worry may harm open source, licensing norms, or long-term developer skills.

This tension – between practical convenience and philosophical discomfort – is likely to define the next few years of AI in open source. It’s also why debates over open vs. closed models, and how AI is trained and deployed, are becoming more intense. If you’re interested in that side of the discussion, the broader backlash around models like Anthropic’s Fable 5 and the push for open models is covered in more detail in this analysis of why open models matter.

Where this leaves the FOSS world

No one knows exactly how this will play out. What we can say with confidence is:

• Policies are diverging: some platforms and projects are banning or tightly restricting AI; others are doubling down on AI integration.

• Cultural norms are shifting: “vibe coding,” agent-driven repos, and AI-assisted workflows are forcing communities to rethink what contribution and authorship mean.

• The change will be drastic: whether AI-heavy or AI-free projects win out, the FOSS landscape in 10–20 years will look very different from today.

For now, the best any project can do is be explicit: decide what role, if any, AI should play in your codebase and your community – and communicate that clearly to contributors and users. The fight between anti-AI camps and vibe coders isn’t ending anytime soon, but how each project responds will shape the future of open source more than any single tool or model.