Speaker
Description
In under two years, AI coding assistants went from a productivity promise to a maintainer's headache inside GNOME itself. In December 2025, the GNOME Extensions team banned AI-generated submissions outright after reviewer Javad Rahmatzadeh reported spending hours a day wading through 15,000+ lines of AI-produced code riddled with unnecessary try-catch blocks, invented APIs, and comments written for an LLM's benefit rather than a human's. By July 2026, GNOME's security team went further, collapsing its 90-day disclosure window to 30 days specifically because AI-generated vulnerability reports had become the norm rather than the exception, and by August, reviewers were reduced to writing instructions aimed directly at the bots generating the noise.
This talk uses GNOME's own paper trail as a case study for a pattern now documented across open source: AI lowers the cost of producing a contribution while leaving the cost of evaluating one untouched, and that imbalance is quietly reshaping maintainer labor. The broader evidence backs this up. A controlled study of experienced open-source developers found they were actually 19% slower when using AI tools, despite believing the opposite. Multiple studies have found that AI-generated code carries measurably more code smells, defects, and complexity than human-written code, alongside recurring security weaknesses. And even after a contribution merges, the maintenance burden doesn't disappear: one empirical study found that 83% of the follow-up work on AI-generated files still falls on human maintainers, not the agents that wrote them.
The talk closes with practical takeaways for maintainers: what a defensible AI-contribution policy looks like, where automated triage genuinely helps versus where it just adds a layer of bureaucracy, and how to protect reviewer time without shutting the door on genuine new contributors.
Talk Description
In under two years, AI coding assistants went from a productivity promise to a maintainer's headache inside GNOME itself. In December 2025, the GNOME Extensions team banned AI-generated submissions outright after reviewer Javad Rahmatzadeh reported spending hours a day wading through 15,000+ lines of AI-produced code riddled with unnecessary try-catch blocks, invented APIs, and comments written for an LLM's benefit rather than a human's. By July 2026, GNOME's security team went further, collapsing its 90-day disclosure window to 30 days specifically because AI-generated vulnerability reports had become the norm rather than the exception, and by August, reviewers were reduced to writing instructions aimed directly at the bots generating the noise.
This talk uses GNOME's own paper trail as a case study for a pattern now documented across open source: AI lowers the cost of producing a contribution while leaving the cost of evaluating one untouched, and that imbalance is quietly reshaping maintainer labor. The broader evidence backs this up. A controlled study of experienced open-source developers found they were actually 19% slower when using AI tools, despite believing the opposite. Multiple studies have found that AI-generated code carries measurably more code smells, defects, and complexity than human-written code, alongside recurring security weaknesses. And even after a contribution merges, the maintenance burden doesn't disappear: one empirical study found that 83% of the follow-up work on AI-generated files still falls on human maintainers, not the agents that wrote them.
The talk closes with practical takeaways for maintainers: what a defensible AI-contribution policy looks like, where automated triage genuinely helps versus where it just adds a layer of bureaucracy, and how to protect reviewer time without shutting the door on genuine new contributors.
Author(s) Bio
AI Engineer | GNOME Nepal Session Manager
| Category | Project organization and Governance |
|---|---|
| Pronouns | She/Her |
| Where are you located? | Kathmandu, Nepal |
| Do you need travel sponsorship from GNOME Foundation in order to join our event? | Yes |