100 PRs in 14 Days: AI-Scale Link Spam Hits Awesome Lists

The pull request looks fine. Clean formatting, a reasonable description, a plausible new AI tool for the list's Image Generation section, even a context paragraph explaining where it fits. If you maintain an awesome list, you've merged a hundred PRs that look exactly like this.

Then the bot comment loads underneath it: this submitter has opened 100 PRs in the last 14 days. Sixty of them target awesome lists. The identical title has been submitted to 37 different repositories.

That thread happened last week on awesome-ai-agents-2026(opens in new tab), and it's worth reading in full, because it's the clearest public specimen we've seen of how open-source link spam works in 2026. Not because the spammer was clever. Because the whole exchange, including the confession buried in the middle of it, maps the economics.

What actually happened

A submitter proposed adding an AI image tool to the list, describing it as a multi-model platform "by ByteDance." An automated workflow the repo runs, labeled PR Spam Guard, replied with a report: account age, follower count, PR velocity across GitHub, and a list of near-identical submissions to other awesome lists, some in different languages.

The submitter responded politely and at length. The product is real and it's theirs. Some of the sibling PRs had already been merged elsewhere after review. The volume spike, they explained, "came from a Python outreach workflow I built earlier this month," with a promise to throttle down going forward.

And then the sentence that gives the whole game away: they'd stop "once I have enough dofollow merges."

The maintainer closed the PR on two grounds. First, an affiliation mismatch: the PR sold the tool as a ByteDance product while the tool's own site footer disclaims any ByteDance affiliation. Second, the parallel-blast pattern itself, which the repo's contributor policy rejects "even when the underlying product is real."

Why this wave is harder to catch

Old link spam announced itself. Broken English, keyword-stuffed anchor text, a URL that had nothing to do with the repo. You could triage it in five seconds.

This is different in three ways.

The submissions are individually plausible. Each PR is well-formatted, correctly sectioned, and written in the register of a genuine contributor. LLMs made the marginal cost of a convincing, customized PR effectively zero, so a script can now produce sixty of them that each pass a five-second look.

The products are semi-real. This wasn't a phishing link. It was a working tool that its owner genuinely operates, dressed up with a first-party affiliation it doesn't have. "Is this link malicious" is the wrong question now; "is this description honest, and is this a contribution or a campaign" is the right one, and it takes real minutes per PR to answer.

The target is the list's SEO, not its readers. Awesome lists rank well and many carry dofollow links. To a growth workflow, a curated list maintained by a volunteer is just a high-authority backlink with a merge button. The submitter said this part out loud.

The asymmetry is the problem. Each blast PR costs the sender nothing and costs a conscientious maintainer ten to twenty minutes of adjudication. Sixty repos ate that cost in this campaign alone, and this was one submitter.

The defense that worked

What caught it wasn't judgment, it was arithmetic. The spam-guard bot checked things that no individual PR reveals:

None of these require reading the PR's content. That's the point: the individual artifact is now too well-crafted to judge in isolation, so the useful signals moved to the aggregate, where automation is honest and volume is visible. It's the same failure geometry we described in silent-success drift: polished individual outputs, and the truth only visible when you compare them in bulk. The human decision at the end, weighing a real product against a dishonest description and a blast pattern, stayed human. The bot just made sure that decision happened with the campaign in view instead of one polite PR at a time.

We run the same principle on our own repos, at smaller stakes: deterministic CI guards for the failure classes that recur (schema coverage, migration drift), so review attention gets spent on the judgment calls machines can't make. It's the argument we made in instrument, don't trust, and this PR thread is the best external validation of it we've seen this year.

If you maintain a list

Three things worth stealing from this repo's setup, roughly in order of effort:

1. Write the policy line first. One sentence in CONTRIBUTING along the lines of "parallel-blast submissions are closed regardless of product quality" turns every future close into policy enforcement instead of a negotiable debate. This maintainer's close was short and friction-free because the policy already existed.
2. Check the claimed affiliation, not the link. The single highest-value manual check in this case took one click: the tool's own footer contradicted the PR's headline claim. Dishonest framing is a cleaner rejection reason than volume, because it doesn't depend on what the submitter did elsewhere.
3. Automate the aggregate checks. A scheduled action that queries a submitter's recent PR velocity and cross-repo title duplicates covers most of what caught this campaign. You're not building a spam classifier; you're surfacing five numbers next to every PR from an unfamiliar account. The same logic behind building the kill switch before the agent ships: decide the tripwires while you're calm, not mid-incident.

And if you're on the other side, doing developer outreach for a real product: the maintainer in this thread told you exactly what works. A single, honest, non-blast submission that describes what the tool actually is gets reconsidered. Sixty scripted ones get your product name pattern-matched to spam in the exact communities you wanted attention from.

FAQ

What is an awesome list?

A community-curated README of tools and resources for a topic, following the awesome-list convention(opens in new tab) on GitHub. The good ones rank highly in search, which is precisely why they're now outreach targets.

Is it against GitHub's rules to mass-submit PRs?

GitHub's acceptable use policies(opens in new tab) restrict spam and inauthentic activity, but enforcement at this scale-and-politeness level is rare in practice. Realistically, defense sits with individual repos and their contributor policies, which is why the policy-line-plus-bot pattern matters.

Do dofollow backlinks from GitHub READMEs even help SEO?

Debatable and shifting; many GitHub surfaces apply nofollow, and search engines discount low-effort link patterns. But what matters here is that growth workflows believe they help, which is enough to generate the volume maintainers have to absorb.

Won't spammers just adapt to velocity checks?

Somewhat: they can slow down, vary titles, and rotate accounts, and this submitter promised to do exactly that. But every adaptation raises their cost per link, and the economics of blast outreach only work when the cost stays near zero. Raising the price is the win condition, not perfect detection.

The ten-minute version

If you maintain anything with a merge button: add the one-sentence parallel-blast policy to CONTRIBUTING today, and next time an unfamiliar account submits a link, spend your first minute on their public PR history instead of the PR body. The artifact is crafted to pass inspection. The pattern never is.