How to Stop AI Bot Spam in Your GitHub Repo With Git Filters

Open-source maintainers are dealing with a new class of noise: automated pull requests generated by AI coding assistants, bots, and "contribution helper" tools that blast repositories with low-signal changes. The commits look real, the diffs are syntactically valid, and the PR descriptions are grammatically correct — but the signal-to-noise ratio is collapsing. If you maintain a repo with any visibility, you have probably already seen this.

The good news is that Git and GitHub give you more control than most teams realise. Used deliberately, they can filter the noise before it ever reaches a reviewer's queue.

Why AI-Generated Commit Spam Is a Real Problem

Automated tools that generate commits on behalf of users often share a tell: the author metadata. Many AI coding agents — whether they are running in CI pipelines, browser extensions, or standalone CLI tools — stamp commits with a recognisable identity, either a known bot email, a generic username, or a service account pattern.

Beyond the identity signal, the contributions themselves tend to exhibit patterns:

  • Cosmetic changes dressed as refactors (renaming variables, reformatting comments)
  • Bulk documentation edits that restate the obvious
  • Dependency bumps without an accompanying rationale
  • Tests that assert trivially true conditions

Individually, each PR seems harmless. Collectively, they consume maintainer attention — the scarcest resource on any open-source project.

Using --author to Audit Your Commit History

Git's --author flag is a first-principles tool for inspecting who — or what — has been committing to your repository.

# List all commits by a specific author pattern
git log --author="dependabot\|renovate\|copilot\|bot" --oneline --all

# Count commits matching a pattern
git log --author="bot" --oneline --all | wc -l

# Show full author metadata for the last 100 commits
git log -100 --format="%an <%ae>" | sort | uniq -c | sort -rn

Running the third command on a moderately active public repo will often surface surprising contributors — service accounts you forgot were active, or third-party integrations that quietly commit on behalf of users. That visibility alone is valuable.

Layering in GitHub's Native Controls

Git's --author flag is diagnostic. GitHub's platform controls are preventive. Used together, they form a practical defence.

Branch protection rules are your first line. Under Settings → Branches, you can:

  • Require pull request reviews before merging
  • Restrict who can push directly to main or develop
  • Require signed commits (this alone disqualifies most bots that do not have GPG keys configured)

CODEOWNERS is underused for this purpose. By assigning human owners to critical paths — core business logic, security-sensitive modules, public APIs — you ensure that any PR touching those paths requires an explicit human approval, regardless of how it was generated.

Required status checks tied to meaningful CI gates (not just lint passes, but integration tests and coverage thresholds) raise the floor for what a viable contribution looks like. A bot can format code; it cannot easily guarantee that a behavioural change does not regress a test suite it has never seen run.

Writing a Responsible AI Contribution Policy

Technical controls are necessary but not sufficient. Teams that have successfully managed this problem tend to publish an explicit policy — a short section in CONTRIBUTING.md that defines what responsible AI-assisted contribution looks like.

A workable policy covers three things:

  1. Disclosure. Contributors should declare if a PR was substantially generated or modified by an AI tool. This is not punitive; it is contextual. A reviewer knowing that a diff was AI-generated will read it differently.

  2. Accountability. The human submitting the PR is responsible for its correctness, regardless of how it was produced. Bots do not own bugs. People do.

  3. Scope limits. Some changes — security patches, architectural decisions, deprecation of public interfaces — should require a human author by policy, not just by convention.

This does not ban AI tooling. It treats AI as a tool in the contributor's hands, not as an autonomous agent with commit rights.

What This Means for Teams Building on Open Source

If your product or service has dependencies on open-source libraries — and it almost certainly does — the health of those upstream repos is a silent dependency on your SLA. A maintainer who burns out managing bot noise is a maintainer who stops cutting security releases.

For teams building internal tools or proprietary SaaS products, the same logic applies at the repository level. Copilot, Cursor, and similar tools are genuinely useful for accelerating development. But if your engineering culture treats AI output as a contribution rather than a draft, the diff between "fast" and "correct" starts to widen in quiet, hard-to-detect ways.

Audit your commit authorship. Set explicit merge policies. Write down what responsible AI-assisted development means for your team — before the noise compounds.

Source: Archestra AI Blog — Only Responsible AI, via Hacker News.

Why this matters for your project: Whether you are scaling a SaaS platform or shipping a mobile product, your codebase is only as trustworthy as the process that governs it. Automating the wrong parts of your review pipeline does not accelerate delivery — it accelerates the accumulation of unreviewed risk. Clear authorship policies and targeted Git hygiene keep your team in control of what actually ships.