Maintaining CI/CD configurations across dozens of Python projects means copying the same tox invocations, Python version matrices, and error-handling logic into every repository. This poster presents five architectural patterns from the reusable-tox.yml project that eliminate this duplication by applying familiar software engineering principles to GitHub Actions workflows.

Each pattern is illustrated with a before/after YAML comparison and a Python code analogy, making the design decisions immediately recognizable to Python developers:

• Singular inputs — accepting one Python version per workflow call instead of JSON arrays. Like writing def run(version: str) instead of def run(versions: list[str]) — simpler to reason about, test, and compose via caller-side matrix strategies.
• Caller-side matrix strategy — separating "what to test" (the calling workflow's job) from "how to test" (the reusable workflow's job). The same Separation of Concerns you'd apply to Python modules.
• Three-phase execution — splitting tox runs into environment preparation (tox --notest), main execution, and debug rerun on failure. Like Unix pipelines — each stage transforms data through a single responsibility, improving cacheability and error diagnosis.
• Composite action hooks — providing extension points where projects inject custom setup logic without modifying shared infrastructure, discovered automatically via hashFiles(). The Dependency Injection pattern applied to CI/CD.
• Explicit over implicit — refusing to auto-detect tox environments or infer configuration. Predictable and debuggable beats magical and surprising.

The poster includes a "Which pattern solves your problem?" decision flowchart and a QR code linking to the open-source repository with ready-to-fork templates.

Born from maintaining dozens of Python projects including aiohttp, CherryPy, and pip-tools, these patterns treat CI/CD with the same architectural rigor as application code.

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.