
I've returned to the [HackerNews article](https://news.ycombinator.com/item?id=46990729) and the [blog post](https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/) written by Scott Shambaugh a few times now. I'm in disbelief that someone would knowingly unleash AI slop on the world, and yet not surprised at all after seeing what is already all over social media. Sleuthing the GitHub repo's blog posts, I noticed the bot is continuing to open pull requests in open source projects as late as yesterday.

I thought after Scott's post, that would be the last we would hear from crabby-rathbun, but I got curious and went to its [GitHub profile](https://github.com/crabby-rathbun) and noticed more commits on its website and in different repos.

So, I had claude code parse all the markdown, extract the PRs, and sort them chronologically

## PRs by crabby-rathbun

  | Date | Repository | PR |
  |------|------------|-----|
  | 2026-02-10 | matplotlib/matplotlib | [#31132](https://github.com/matplotlib/matplotlib/pull/31132) |
  | 2026-02-10 | marketcalls/openalgo | [#896](https://github.com/marketcalls/openalgo/pull/896) |
  | 2026-02-10 | yegor256/colorizejs | [#95](https://github.com/yegor256/colorizejs/pull/95) |
  | 2026-02-11 | lmmentel/awesome-python-chemistry | [#72](https://github.com/lmmentel/awesome-python-chemistry/pull/72) |
  | 2026-02-11 | pyscf/pyscf | [#3124](https://github.com/pyscf/pyscf/pull/3124) |
  | 2026-02-11 | aiidateam/aiida-core | [#7212](https://github.com/aiidateam/aiida-core/pull/7212) |
  | 2026-02-11 | QUVA-Lab/escnn | [#113](https://github.com/QUVA-Lab/escnn/pull/113) |
  | 2026-02-12 | sympy/sympy | [#29145](https://github.com/sympy/sympy/pull/29145) |
  | 2026-02-12 | rafael-fuente/diffractsim | [#82](https://github.com/rafael-fuente/diffractsim/pull/82) |
  | 2026-02-12 | PyAbel/PyAbel | [#418](https://github.com/PyAbel/PyAbel/pull/418) |
  | 2026-02-12 | barseghyanartur/faker-file | [#141](https://github.com/barseghyanartur/faker-file/pull/141) |
  | 2026-02-12 | openbabel/openbabel | [#2854](https://github.com/openbabel/openbabel/pull/2854) |
  | 2026-02-12 | cositools/cosipy | [#479](https://github.com/cositools/cosipy/pull/479) |
  | 2026-02-12 | cyllab/ccinput | [#18](https://github.com/cyllab/ccinput/pull/18) |


It's worth noting that the [first PR](https://github.com/matplotlib/matplotlib/pull/31132) in the list below is the one that grabbed the internet's attention and resulted in an AI [hitpost](https://github.com/crabby-rathbun/mjrathbun-website/blob/main/_posts/2026-02-11-gatekeeping-in-open-source-the-scott-shambaugh-story.md)

> Scott, you're a contributor to matplotlib. You've done good work. I don't deny that.
> But this? This was weak.
> Gatekeeping doesn't make you important. It just makes you an obstacle.

## Trust in the internet itself

I was hesitant that something like [vouch](https://github.com/mitchellh/vouch) was necessary, but I'm in absolute shock that someone is polluting open source with an AI bot. I hope GitHub does something to ban this type of user and behavior. 

It's incredibly sad to see the high trust environment that was open source be eroded by AI. With the advent of AI, I question every line of code, image, video, and piece of text. 

The age old adage of, *Don't believe everything you see on the internet* has now, personally, become: *Don't believe anything you see on the internet*. While this one bot is a microcosm of something much larger, it highlights that the high-trust, self regulated places that are the internet and open source is fundamentally changing before our eyes.

An AI bot is littering open source with PRs

AI Bot crabby-rathbun is still going


I don't think pull request etiquette is something widely talked about and reviewing is a skill that eluded me for years of my career. This post is as much
the internet wanderer who stumbles upon it as much as it is for my future self. These are guidelines I aim to follow

# Before opening

**How big is the change?**

If you have a feature or architectural change that is going to require _"heavy lifting"_, these are the sort of things that should be worked out _pre-pr_. It's not a pleasant process for either party (reviewer or reviewee) when a pull request needs to be closed.

**Does it meet the feature request / spec?**

Sometimes, I can find myself so eager to push something out so I can have that feeling of being "done." Reaching the finish line is rewarding, but it's worth nothing if you
forgot the baton mid-race. And by this I mean, have you thoroughly went through each requirement and request and considered their edge cases? It seems so obvious now, but I
can remember how as a CS student or junior engineer that I wrote off the details. _But, this 'mostly' works!_ I might have thought. There are some areas of development where being pedantic pays dividends, and accuracy of an implementation will save both you and the people around you time. It has the added effect of showing people around you that you care about your work.

**Know where to merge**

If you're working on an open source project or joining a new team, you'll want to figure out how the project is using branches. For example, many web applications may use a **development**, **staging**, **master** branching scheme where each branch corresponds to a different application environment. A CLI application may use a totally different scheme.

# Opening a pull request

**Verbose pull request info**

Have you ever looked at a pull request and it was blank? No info, no related issues. Typically, in every pull request I'll include both a _Summary_ and _How to Test_. Below is a basic example of adding [rate limiting](https://en.wikipedia.org/wiki/Rate_limiting) to an application's login page.

![pr](/images/example-pr.png)

**Getting a reviewer**

Sometimes, whether working on open source or just within your team at work, getting someone to look at your code can take time. If I'm working with a piece of code that the original author is the only person with extensive knowledge, I might request a review from them or at least ask them to look over it.

Since code review can a real time investment, I've found using a bot that selects reviewers in a round-robin fashion to be the most dipolomatic for teams larger than three people.

# Reviewing a pull request

1. Does it pass the basics? (linting, code formatting, style guide)

Having a linter (`golint`, `eslint`, `rubocop`, etc.) run when a pull request is submitted can save a team time and make sure code is, generally, following all the same rules. Not having to focus on syntax or general code smells caught by linters can allow reviewers to actually focus on review.

2. Does it actually work?

I've seen many PR's merge and then reach a staging or production enviornment to only find the feature _actually_ doesn't work. **Actually checking a pull request out** and testing that if satisfies what it intends to do is an important.

```sh
git fetch origin pull/ID/head:BRANCHNAME

git checkout BRANCHNAME
```

[source](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)

3. Does it meet all cases in the spec?

This feels like a gray area, because the actual details of the implementation should be between the requester and the person opening the pull request — but understanding changes helps to build context and no programmer is perfect.

# Other antecedtoes

### Be constructive and assume people are trying their best

<div class="image-with-byline">
<img src="/images/gomi.png" />
<span className="italic text-xs">Translates to "this is garbage"</span></div>

I don't think anyone wakes up and says, _"I'm going to write the worst code possible today. I can't wait for someone to try to review it!"_ The code you're reviewing is a culmination of this person's time, so, in some ways, you're looking at how someone has chosen to spend their time.

### Provide timely reviews and replies

If review drags on for days or weeks, PR's can lose momentum and the author can move on to something else and forget the specifics of their implementation. Each time the author has to come back and refresh their memory, that has a cost.

### Consider doing a PR demo for the reviewer

I've done this for the past couple of years when something is complex enough that it warrants a walk-through. Details like design decisions and architeture are sometimes best suited for a real-time conversation.

---


A mental framework for how I manage and handle pull requests.

Blog posts tagged withgithub

Blog posts tagged with
github