Outline — Humans vs. Slop: Rewriting the Rules of Open-Source

Speaker

Jack Wotherspoon — Developer Advocate at Google in DevRel for AI DevTools. Career focused on open source and developer communities. Built open-source client libraries at Google for ~5 years (including Google ADK — Agent Development Kit), and is a core maintainer on Gemini CLI (100,000+ GitHub stars, 700+ external contributors). Introduced by an MC referred to as "Macey".

Abstract (verbatim, as provided)

When the cost of generating code drops to zero, the cost of reviewing and maintaining that code skyrockets.

For decades, open-source has been built on a simple foundation: human developers collaborating on shared problems. But that foundation is shifting. As AI agents make it possible to generate pull requests in seconds, maintainers are facing a crisis.

In this session, we'll move beyond the hype to discuss how the rise of "AI slop" is fundamentally changing the way we manage, trust, and scale open-source projects. We will explore the new rules of engagement for a world where agents are part of the team.

Thesis (synthesis)

The economics of open source have inverted: code generation is now free and subsidized, but human review still costs the same, so maintainers are being swamped by low-effort AI-generated PRs (Wotherspoon dislikes the word "slop" but uses it). The fix is not to reject AI contributions outright but to build filtering and trust infrastructure — issue-first workflows, rate limits, checked-in context files and agent skills, and emerging community systems like Vouch and OSS Vacation — that preserve the human social contract underneath.

Section TOC

Terminology glossary (definitions the speaker actually gave)

• Slop — Wotherspoon explicitly says: "I use the word slop, but I don't actually really like that word too much." He uses it to mean low-quality, low-effort AI-generated code/PRs.
• The social contract (old world) — "if you were an external contributor to an open source project, you're kind of expected to read the docs, make sure that whatever is breaking isn't on your fault... take a look at the code base, understand why something's going wrong before you would put up kind of a pull request."
• Drive-by PR — "someone confident. They had no expectation that they were actually going to have to follow up or do anything... a prompt and forget it."
• Subsidized inference — "these plans that are offered by all the major companies are quite subsidized. So you're paying $20 or $200, but you're potentially getting thousands of dollars actual inference out of those subscriptions."
• Context files / agents.md — Checked-in instruction files agents are supposed to read. "don't just commit the context files for Claude... you should actually add an agents.md as well" so contributors using any tool benefit.
• Agent skills — Codified procedures (e.g. PR creator, docs writer, code review) checked into the repo. Gate criterion: "what would you use over 50% of the time?" — those go in as enabled-by-default.
• OSS Vacation / open source vacation — "any pull request or issues during that time will get automatically closed and say, hey... we're on open source vacation." Configured via vacation.markdown.
• Vouch — "trusted maintainers or contributors can vouch for other people" — a referral trust system. Uses a .td file with allowlist/blocklist of GitHub handles, scanned by GitHub Actions.
• Denounce — The inverse of vouch: "bots or people who have put up sloppy code can get denounced and then they get blocked."
• Prompts as PRs — "don't give me the code. Just give me the prompt that you use to generate the code and I'll go do it myself." Wotherspoon notes he hasn't adopted this himself.

Named frameworks / concepts introduced

1. The economics inversion: generating code is free, maintaining/reviewing it is not.
2. The new playbook for maintainers (six concrete moves):
   • Require an issue before a PR
   • Rate-limit external contributor PRs (now native in GitHub settings)
   • Add automation (e.g. stale PR closure after 60 days)
   • Check in context files including agents.md (not just CLAUDE.md)
   • Check in agent skills (PR creator, docs writer, code review)
   • Adopt community trust mechanisms (Vouch) and capacity signals (OSS Vacation)
3. The "use over 50% of the time" rule for which agent skills are enabled by default.
4. Three values for the human–agent future: trust, structure, respect.
5. Take-home checklist: update CONTRIBUTING.md with an AI-contribution section; check in context files & skills; add automation to protect your time.

Named examples / projects referenced

• Gemini CLI — Wotherspoon's project; 100k stars, 700+ external contributors.
• Google ADK (Agent Development Kit) — his prior project.
• Anti-Gravity CLI — Google product used in the live demo to spawn 10 sub-agents.
• GitHub Copilot — moved from subscription to per-token billing; subject of the Theo demonstration of subsidized-inference exploitation (60M tokens from one prompt; $30 plan ≈ $30,000 of inference).
• curl — flooded with fake AI-generated security reports.
• Tldraw — closed external PRs entirely.
• Ghostty / Go CLI — Mitchell Hashimoto's projects using Vouch; he reports "PR quality has gone way up."
• Python coding agent / "Mary" — heavy user of OSS Vacation, even when not traveling.
• Theo (tech influencer) — demonstrated the Copilot token loophole.

Open questions / not covered

• Specific code or syntax of vacation.markdown or the Vouch .td file beyond "list of GitHub handles".
• Concrete numbers on how much PR volume dropped at Gemini CLI after introducing each rule.
• Whether/how to compensate maintainers — Wotherspoon acknowledges the question on commercial OSS support models but says "I haven't seen that" in his experience.
• The full text of any of the agent skills (PR creator, docs writer, code review) — only their names and high-level purpose are given.
• How exactly conflict between many enabled skills should be managed (the questioner raised this; Wotherspoon's answer is just the 50%-of-the-time gate).
• Whether the issue-first rule applies to security-sensitive fixes.
• Specific stance on whether AI-only PRs should ever be accepted (he describes other companies' positions but doesn't fully commit Gemini CLI's).