We stopped AI bot spam in our GitHub repo using Git's –author flag

Original Article ↗ Hacker News Discussion ↗

Reaction to the --author / contributor-onboarding hack

  • Many call it elegant and clever: it reuses GitHub’s “require prior contribution” plus a captcha to drastically reduce AI/bot PRs and issues.
  • Clarifications: onboarding is triggered via the GitHub REST API; commits are co‑authored so GitHub recognizes the user as a contributor.
  • Critiques:
    • It shifts spam from PRs to many small commits; some note these now form a large fraction of the repo’s commit history.
    • Question whether “click OK 10 times + captcha” just adds friction that motivated slop farms can still bypass.
    • Concern about CI cost, since each onboarding commit runs the full pipeline.

GitHub’s role and missing tooling

  • Strong sentiment that GitHub/Microsoft benefit from AI-driven activity and have little incentive to curb it.
  • Requests for platform features:
    • PR “staging” or moderation queues; draft-only PRs that only maintainers can mark ready.
    • Better contributor metrics: PR rejection rate, cross-repo spam detection, AI/bot scores.
    • Ability to delete or archive PRs (not just close), and “burn it with fire” actions that nuke all spammer activity at once.
  • A GitHub representative mentions an upcoming “archive PRs” feature; maintainers argue pre‑moderation is more important.

Reputation, gating, and scoring ideas

  • Suggestions: PR “tokens,” OTP-style access keys, vouching systems, trust circles, Elo/karma-like contributor scores.
  • Pushback:
    • Elo specifically is ill-suited and easily gamed; any scoring system risks cartels and state actors.
    • New contributors get locked out; parallels drawn to Reddit karma and StackOverflow reputation.

Money, bounties, and perverse incentives

  • Several link PR spam to bounties and to GitHub contributions being used as hiring signals.
  • A controversial “Pfand” (deposit-per-PR) idea sparks long debate:
    • Pro: forces skin in the game, filters bots and low-effort work.
    • Con: burdens poor, young, unemployed, privacy-conscious contributors; enables scams and harassment; adds heavy payment/admin overhead.

Security, trust, and identity

  • Using “prior contribution” as a security gate is questioned: once a trivial PR is merged, an attacker gains elevated trust.
  • Some argue only org members should bypass approvals; others say if that’s enough to break you, your security model is already weak.
  • One camp advocates real-name, non-anonymous GitHub to reduce bad-faith and bot activity; others note pseudonyms are now allowed even in major projects and that sophisticated attackers can still build fake reputations.

AI slop, OSS health, and irony

  • Maintainers report that the majority of recent contributions are now useless LLM slop: verbose “plans” with trivial diffs or large, subtly broken patches.
  • Some see the post (and its highly polished style) itself as LLM-generated “slop” complaining about slop, especially ironic from an AI-focused company whose tools could generate the same PRs.
  • Broader worry: open source maintainers are being burned out cleaning AI spam while platform metrics (PR counts, “activity”) look great to investors.

Alternative anti-spam approaches

  • Mentioned techniques:
    • Proof-of-work / Hashcash-style schemes, broadly rejected as disadvantaging legitimate users and enriching botnet operators.
    • Network- or mesh-style communication limits to prevent N‑to‑N spam (not concretely specified).
    • A simple AGENTS.md file instructing AI agents not to submit PR spam, relying on models auto‑reading it as context; reported as surprisingly effective “for now.”