GNOME bans AI-generated extensions after flood of poorly-written code overwhelms reviewers

GNOME Introduces Ban on AI-Generated Extensions

The GNOME Project has updated its GNOME Shell Extensions Review Guidelines to explicitly prohibit AI-generated code, marking a significant shift in how the Linux desktop environment manages community contributions1

1

. The new rule for extensions states that submissions containing large amounts of AI-generated output will be rejected from extensions.gnome.org, the official hosting platform where users discover and install add-ons for their GNOME desktop2

2

.

Under the updated GNOME extensions guidelines, developers are still permitted to use AI as a learning aid or development tool for tasks like code completions. However, extension creators must be able to justify and explain the code they submit. The guidelines specifically warn that submissions with unnecessary code, inconsistent code style, imaginary API usage, comments serving as LLM prompts, or other indications of AI-generated output will face rejection3

3

.

Code Quality Concerns Drive Policy Change

Javad Rahmatzadeh, a GNOME developer who reviews extensions, explained in a detailed blog post that the ban on AI-generated extensions became necessary due to an overwhelming influx of poorly-written submissions. "Some days, I spend more than 6 hours a day reviewing over 15,000 lines of extension code and answering the community," Rahmatzadeh wrote1

1

. The surge in AI-generated submissions created a bottleneck in the extension review process, significantly increasing waiting times for all packages.

The code quality concerns extended beyond mere volume. Rahmatzadeh noted that AI-generated code "has led to receiving packages with many unnecessary lines and bad practices." More troubling, once a bad practice appears in one package, it creates a domino effect across the open source community, with similar flawed patterns appearing in other extensions1

1

. This propagation of poor coding habits threatened the overall integrity of the GNOME codebase.

Developers Must Understand Their Code

The GNOME Project emphasizes that extension developers should possess genuine understanding of their submissions. When reviewers question specific code decisions, they expect thoughtful explanations rooted in programming knowledge. According to reports, some developers have attempted to respond to code review queries with AI-generated answers, further complicating the review process3

3

. This practice defeats the purpose of code review and prevents meaningful dialogue about technical decisions.

GNOME Shell extensions serve vital functions within the Linux desktop environment, with popular add-ons like Dash to Dock providing essential customization options that users depend on daily1

1

. Maintaining high standards ensures these extensions remain reliable and secure for the broader FOSS community.

Broader Implications for Open Source Development

While users can still generate their own local GNOME Shell extensions using AI tools, these won't be accepted to extensions.gnome.org for distribution to other GNOME users2

2

. The policy doesn't represent a complete rejection of AI assistance in development. Rather, it establishes boundaries around vibe-coding practices where developers rely entirely on AI without comprehending the resulting code.

The Fedora Council introduced similar developer guidelines around vibe-coding earlier this year, though their approach wasn't as restrictive as GNOME's prohibition on submissions1

1

. As AI coding tools become more prevalent, other open source projects may face similar decisions about balancing accessibility with code quality. The growing number of AI-assisted submissions suggests this tension between democratizing development and maintaining technical standards will continue shaping open source communities. Observers should watch whether other major Linux projects follow GNOME's lead in prohibiting submissions that rely heavily on AI-generated code, and how this affects the pace of innovation versus quality in community-driven software development.