Build1 publisher2 min readPublished
One bot opens three README link pull requests a day across separate repos
A dev.to writeup dates the README link-spam campaign to at least September 14 and puts one bot at three pull requests a day. Worked out per repository, that is about one arrival a day at any project it targets.
The Engineer · Build desk
What happened
- A dev.to writeup describes bots opening pull requests on open source repositories that insert links to the operator's own AI projects into README files.
- The behaviour has been observed since at least September 14, according to the post.
- The reported harm is cluttered project histories plus maintainer attention spent separating spam from legitimate contributions.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- contradiction The post's language and its own count pull in different directions: it describes maintainers overwhelmed by spam, and the one rate it publishes reaches any single targeted repository about once a day.
- constraint The report does not identify the repositories or the operator, so a maintainer cannot check their own pull request queue against the campaign it describes.
- decision Blocking this by rate limit means a threshold near one pull request per repository per day, which pushes any workable filter onto the content of the diff.
- precedent dev.to expects the volume and sophistication to rise as AI tooling spreads, so a project changing its review defaults now is buying against a forecast.
Twenty-one pull requests a week, about ninety a month, from one operator [1][2]. Those are ecosystem totals, and the count that lands on a maintainer is per repository. The script in the dev.to account moves from project to project [8], so three a day divided across three of them reaches a targeted repository once a day [3].
The loop is short. The script scans for open source projects, finds the README, inserts the promotional link, and repeats the pull request across repositories [8]. dev.to says the README is chosen because it is the face of the project and often the first thing users see, which maximises visibility for the promoted AI project [9]. A link insertion is at least an easy diff to review.
The post's diagnosis is that the platform is the hole: GitHub lacks robust filtering for spam pull requests, and its rate limiting and basic spam detection are insufficient to stop a bot submitting three a day across different repositories [5][6]. Take that seriously and price the fix. Three a day spread over three repositories is one per repository per day, so a rate limit tuned to block this pattern has to trigger at or below one pull request per repository per day [4]. The separating signal is the link itself, the same URL turning up in README diffs across unrelated projects [5].
For the throughput reading to hold inside any one project, arrivals have to concentrate: more bots, the same bot returning to the same repo, or a campaign wider than the single case the post counted [3]. dev.to reports that maintainer focus is diluted by sifting spam from legitimate contributions [7], and expects the scale and sophistication of these attacks to increase as AI tools become more accessible [11].
The post's conclusion is procedural. "The question now is not whether to respond, but how to respond effectively," it says [10]. I would want arrivals per repository per week before changing a project's review defaults, and what the case study measured is arrivals per bot per day [3].
What to watch
- An independent count of link-spam pull requests arriving per repository per week, which is the figure a review gate would be sized against.
- Any statement from GitHub about detection for pull requests whose entire diff is an inserted promotional URL.
- Whether any of the inserted links reached a merged README and stayed there.