To give you a sense of the scale I work at, I’m cruising towards 50 contributor PRs a day, combined between Beads (20k stars, 5 months old) and Gas Town (13k stars, 3 months old). That’s seven days a week; if I take a day or two off, they pile up and I may have to deal with 100 or more in a single day.

[...]

Through all that, my median time to resolution is about 15 hours, with few PRs waiting more than a few days. This is high velocity. But I still manage to keep my quality bar high enough that both projects continue to exhibit strong growth. It may look like I’m only merging 60% of the PRs from the metrics, but that’s an artifact of fix-merging. I actually merge about 88% of all incoming contributor PRs, one way or another, and both projects are flourishing from it.

[...]

I’m a very lazy person, and maintaining a popular OSS repo, let alone two of them, would simply not have been possible for me, like ever, up until maybe a year ago. I’m getting by with AI, that’s the only way. As my PR volume has increased, I’ve been able to keep afloat through model and tool improvements, automating as much of the decision tree as I can.

[...]

I do actively encourage forks where people are trying to take the code in a direction I just can’t follow. The earliest big fork was beads_rust from Jeffrey Emanuel, who told me he was very embarrassed to be forking my code, until we chatted about it and I gave it my heartfelt blessing.

[...]

My own approach is radically different from how most OSS maintainers work: I say Yes to AI. Instead of rejecting AI submissions, I encourage everyone to use AI to submit their PRs (subject to a growing list of hygiene rules). Indeed, I both observe and expect 99% of incoming PRs to be AI-assisted.

[...]

Instead of requiring perfect PRs from everyone, I aim to find a quick resolution that is satisfying to all parties. I accept most PRs, but still maintain hard lines on architecture, what goes in core, code quality, and many other AI-era design principles (e.g. ZFC). If I were to send every PR back to the contributor for fixes, the rest of the community might be losing out on some important fix or feature for days to weeks. And there it is, sitting there in the PR; it just has issues with it.

In this situation, if you want to maximize throughput, then you may need to fix the contributor’s code yourself before it can be merged. Most OSS maintainers say, “Go fix your code.” I try my best to fix it myself and get it merged. There’s an art to this that I’ll discuss below.

My core philosophy is, help contributors get to the finish line. I optimize for community throughput. I review every PR and try to find the value in it, and have my worker agents do something appropriate for each one.

[...]

Notice that the first resort for almost every OSS maintainer, which is to send your PR back requesting changes, is the last resort in my vibe maintainer workflow. It ranks even lower than rejection, which itself is very serious, because rejection can lead to forking. And it’s cumulative. The more PRs you reject, the higher the chance of someone getting fed up with you.

Requesting changes is unfortunately the last resort because is quickly leads to contributor starvation; if you keep making them rebase it, the sheer velocity of the project can prevent their PR from landing for weeks, until you take steps to help it along. So you might as well help it right from the start. Don’t send it back for changes.

[...]

When you get down to the last 5–10% of the PRs, they’re usually hefty features, and you may need to spend a lot of time digging into them and figuring out whether you really want to pull them in. You may ask the agent a ton of questions about each PR, ask it to consider alternatives, or just tell it you don’t see the point. If the agent can’t justify the PR, then it’s probably not worth taking yet.

But that last 5% to 10% is the part that takes hours a day. There’s always a list of PRs that are just right on the edge and need my judgment call, though I wish it weren’t so. It is definitely getting easier now that Gas Town is becoming essentially feature-complete, due to the launch of Gas City. So I auto-close any large features and redirect the contributors to Gas City.

[...]

Gas City was built by my buddies Julian Knutsen and Chris Sells, and as far as I can tell, it is exactly what I envisioned and outlined to them when they first suggested tackling it. They did a bang-up job. So good that Gas Town itself, the binary, is I think not long for this earth. Only its shape, the original characters, and all the individual features we loved about Gas Town remain — all available as LEGO-like pieces for creating your own agent orchestration shapes.