OpenClaw's Peter Steinberger Made 449,693 Contributions in a Year — How On Earth Does He Do It?
I opened Peter Steinberger’s (@steipete) GitHub profile today and just stared at his contribution graph.
449,693 contributions in a year. 607 today, April 6th. Over 13,000 on his peak day.
Peter is the author of the open-source AI agent project OpenClaw. He just announced he’s joining OpenAI to keep pushing on agents, and he’s handing OpenClaw over to a foundation to keep it independent. In other words: this isn’t some engineer hiding inside a big company gaming KPIs. This is an indie developer who built a side project so good that OpenAI scooped him up — and that’s his output cadence.
Then I clicked over to my own profile: 30 to 50 PRs a day, 60-something on a really good day. Compared to Peter, I’m 10–20x slower on average and a few hundred times slower at peak.
At first I tried to comfort myself: surely most of those are bot commits, surely it’s scripts, surely it doesn’t really count. But the more I thought about it, the less it held up — even if you cut 600k in half, then in half again, what’s left would still grind me into the floor. In the AI era, the bottleneck for writing code stopped being “do you know how to write it.” It became “how many full idea → ship loops can you complete in a day.”
Why I’m fixating on PR output rate as a metric
A few days ago I wrote a post called Indie Dev Is Just a Math Problem. Today’s realization is the footnote to that post.
Indie dev success has always been a probability game. Maybe one product has a 1% chance of working. Ten products, 10%. A hundred products, basically inevitable. But “ship a product” is too big and too vague to measure against day to day. You can’t tell whether you actually moved forward today.
A PR is the smallest, most measurable, most honest unit of progress in this probability game.
One PR = one full loop of “idea → write it → make it run → merge it.” More loops mean:
- More directions tried
- More feedback pulled out of real code
- One step closer to the product that will actually work
I’m not tracking deliverables, I’m tracking cadence — because cadence is the only thing you actually control. You can’t control luck, you can’t control the market, but how many PRs you merged today? You can.
Peter does 600 a day. I do 40. That doesn’t mean “he’s 15x smarter than me.” It means he runs 560 more loops than I do every day. Over a year, the dead ends he’s walked, the assumptions he’s tested, the traps he’s stepped in — they’re dozens of times mine. That’s the truly scary part. And it’s why he could go from being an indie developer to OpenAI. It wasn’t one moment of brilliance. It was loop count, compounded daily.
What I’ve come up with so far
These are the directions I’m experimenting with. Not all of them are right:
1. Stop letting your keyboard be the input bottleneck. Even fast typing tops out around 80 words per minute. Speech easily hits 200+. I’m increasingly dictating requirements to the AI, and the speedup is immediate. A paragraph that takes 30 seconds to say takes two minutes to type.
2. State the requirement clearly the first time. Don’t make the AI guess. The most wasteful pattern is: “tweak this” → AI tweaks → “no, I meant…” → AI tweaks → “still not it…” Half an hour gone, no PR shipped. Spending two minutes upfront to lay out the requirement, the constraints, and the expected output is 10x faster than ping-ponging.
3. Have AI review AI’s code. I’m slow at reading code, but having a second AI act as a reviewer is essentially free. Two models picking at each other catch most of the dumb issues before merge — and what they save me is my own debugging time.
4. Add unit tests for every function. Sounds like a cliché, but in the AI-writing-code context the meaning is completely different: tests aren’t there to prove the code is correct. They give the AI a deterministic feedback loop. The AI runs the tests, green means done, red means it fixes itself, no human in the loop. That is the real lever for output rate.
5. Most important: avoid the “one sentence at a time” tug of war. This is my biggest trap. Once I’m in it, half a day yields one PR. The moment I sense it starting, my new rule is: stop, rewrite the full requirement spec from scratch, and have the AI redo it from zero. It feels wasteful. It’s much faster than the tug of war.
I’d love to hear how you do it
I’m currently shipping at about 5–10% of Peter’s pace. I don’t expect to catch him, but I want to know —
How do you raise your own output rate?
- Tools or workflows I’m probably not using yet?
- What’s your voice input setup?
- How do you avoid getting dragged into endless back-and-forth with the AI?
- When you maintain multiple projects solo, how do you switch context without losing speed?
Comments, email, Twitter — I read all of it. The point of this post isn’t a conclusion. It’s bait for a conversation. In the AI era, whoever cracks “personal output rate” first is already most of the way to winning.
And indie dev was always a math problem.