Uploaded August 2026 | Updated September 2026, 2 weeks ago
[EuroPython 2026 - S1 on 2026-07-17]
🎤 *Defending Open Source from "AI" Slop: A Maintainer's Practical Guide by Sviatoslav Sydorenko (Святослав Сидоренко)*
🔗 https://ep2026.europython.eu/session/defending-open-source-from-ai-slop-a-maintainer-s-practical-guide
📝 Abstract:
Open source maintainers are drowning in a new kind of noise. "AI"-generated pull requests — superficial, poorly reasoned, and submitted without genuine understanding of the codebase — are consuming review bandwidth that was already scarce. These contributions range from cosmetic "improvements" that introduce subtle bugs to elaborate refactorings that no one asked for, all bearing telltale signs of LLM output: confident tone, plausible-looking code, and zero awareness of project conventions.
This talk presents a practical, battle-tested framework for combating "AI" slop without discouraging legitimate contributors. Drawing from real experiences maintaining pip-tools, aiohttp, ansible-core, CherryPy, and other Python projects, I'll share concrete strategies that work today.
First, we'll dissect the anatomy of "AI" slop PRs — what they look like, why they pass superficial review, and the hidden costs beyond wasted review time: CI compute waste, security risks from plausible-but-wrong code, and the demoralizing effect on genuine contributors who see low-effort submissions getting attention.
Then I'll walk through a defense-in-depth approach being developed across my projects: updating `CONTRIBUTING.md` with explicit expectations about understanding the codebase before submitting changes; crafting repository-level LLM instruction files (like `AGENTS.md`/`CLAUDE.md`) that steer "AI" tools toward project-specific conventions; configuring PR templates to require evidence of human reasoning; and establishing community norms that set quality expectations without being hostile to newcomers.
We'll also tackle the harder questions: Where is the line between "AI"-assisted (the human drives and understands the change) and "AI"-generated (the human clicks "submit" on LLM output)? How do we preserve the welcoming culture that makes open source special while defending against low-effort spam? What should platforms like GitHub improve for maintainers?
You'll leave with a ready-to-adapt policy template and configuration files for your own projects.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
[EuroPython 2026 - S1 on 2026-07-17]
🎤 *Defending Open Source from "AI" Slop: A Maintainer's Practical Guide by Sviatoslav Sydorenko (Святослав Сидоренко)*
🔗 https://ep2026.europython.eu/session/defending-open-source-from-ai-slop-a-maintainer-s-practical-guide
📝 Abstract:
Open source maintainers are drowning in a new kind of noise. "AI"-generated pull requests — superficial, poorly reasoned, and submitted without genuine understanding of the codebase — are consuming review bandwidth that was already scarce. These contributions range from cosmetic "improvements" that introduce subtle bugs to elaborate refactorings that no one asked for, all bearing telltale signs of LLM output: confident tone, plausible-looking code, and zero awareness of project conventions.
This talk presents a practical, battle-tested framework for combating "AI" slop without discouraging legitimate contributors. Drawing from real experiences maintaining pip-tools, aiohttp, ansible-core, CherryPy, and other Python projects, I'll share concrete strategies that work today.
First, we'll dissect the anatomy of "AI" slop PRs — what they look like, why they pass superficial review, and the hidden costs beyond wasted review time: CI compute waste, security risks from plausible-but-wrong code, and the demoralizing effect on genuine contributors who see low-effort submissions getting attention.
Then I'll walk through a defense-in-depth approach being developed across my projects: updating `CONTRIBUTING.md` with explicit expectations about understanding the codebase before submitting changes; crafting repository-level LLM instruction files (like `AGENTS.md`/`CLAUDE.md`) that steer "AI" tools toward project-specific conventions; configuring PR templates to require evidence of human reasoning; and establishing community norms that set quality expectations without being hostile to newcomers.
We'll also tackle the harder questions: Where is the line between "AI"-assisted (the human drives and understands the change) and "AI"-generated (the human clicks "submit" on LLM output)? How do we preserve the welcoming culture that makes open source special while defending against low-effort spam? What should platforms like GitHub improve for maintainers?
You'll leave with a ready-to-adapt policy template and configuration files for your own projects.
---
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License: creativecommons.org/licenses/by-nc-sa/4.0
