Not skimmed. Not glanced at the diff for 4 seconds before hitting “approve.” Actually read it, line by line, understood every function, every edge case.
If your answer is “yesterday” — cool, you’re thorough. You’re also mass slow.
Peter Steinberger — the guy who built OpenClaw, the fastest-growing repo in GitHub history (180,000+ stars), the project that OpenAI and Meta are fighting to acquire — made 6,600 commits in January 2026. Alone. No team. As of today, he just joined OpenAI to lead their next generation of personal agents. Sam Altman called him “a genius.” OpenClaw moves to a foundation and stays open-source.
His motto? “I ship code I don’t read.”
That quote sounds reckless until you look at the results. And then you start to wonder — how many of the “best practices” you follow every day are actually just habits you never questioned?
I spent two weeks stress-testing Peter’s approach on my own stack (Convex, n8n, Claude Code — the usual suspects). Some of it changed how I work permanently. Some of it felt like doing a trust fall with a mass robot. All seven of these habits sounded wrong until I saw what happened when I actually tried them.
TL;DR: Peter Steinberger shipped 6,600 commits in one month using seven counterintuitive habits that sound reckless until you see the results — like shipping code without reading it and deliberately under-prompting AI agents. You'll get his exact framework for trusting test suites over code reviews, why he killed all his multi-agent setups, and the mental shifts that let him build faster than entire teams while maintaining quality.
1. Ship code you’ve never read
That’s not a joke. That’s a direct quote from Peter Steinberger on the Pragmatic Engineer podcast. The man who built PSPDFKit — a PDF framework running on over a billion devices — came back from a 3-year retirement and decided that reading code was optional.
“I ship code I don’t read.”
The setup that makes this not-insane: his agents compile, lint, and run the full test suite before anything gets committed. If the pipeline is green, it ships. Peter reviews architecture decisions. He reviews system design. He does not sit there reading through auto-generated TypeScript like it’s a novel.
I tried this on a Convex backend migration last month. Instead of reviewing every mutation line by line, I wrote comprehensive tests first, then let Claude Code generate the implementation. Tests passed. I merged without reading the code.
My hands were sweating the entire time. Like the first time you rm -rf a directory and realize you forgot to check which one.
But nothing broke. And I shipped in 3 hours instead of a full day.
The mental shift: stop reviewing code. Start reviewing outcomes. If your test coverage is solid, the code is just… plumbing. Which brings us to point 7. But I’m getting ahead of myself.
2. Kill your MCPs and subagents
Everyone and their dog is building multi-agent swarms right now. Five agents coordinating through MCPs, passing context back and forth, with an orchestrator agent managing the whole circus. It looks impressive in a demo. In production, it’s a Rube Goldberg machine that breaks every Tuesday.
Peter doesn’t use MCPs. Doesn’t use plan mode. Doesn’t use subagents.
One agent. Good prompts. Targeted skills. Thats it.
I know what you’re thinking because I thought the same thing — “but my workflow is complex, I need multiple agents.” So I ran an experiment. I had an n8n pipeline with 4 different AI nodes doing sequential processing: extract, classify, enrich, format. Four agents, four API calls, four places where things could silently fail.
Replaced it with a single Claude Code call with a well-structured prompt. Same output. Faster. $12/month cheaper. And when something breaks, I debug one thing instead of playing detective across four black boxes.
Peter put it bluntly in an interview: most multi-agent setups give the illusion of productivity but actually produce worse slop. The human-machine loop — one human, one agent, tight feedback — is where the real quality comes from.
Not every workflow should be simplified this way. But way more of them can be than you think.
3. Under-prompt on purpose
This one messed with my brain.
// What I used to write:
"Create a Convex mutation that takes a user ID and a list of
transaction objects, validates each transaction amount is positive,
checks the user exists in the users table, batches inserts in
groups of 50, handles partial failures by rolling back the batch,
and returns a summary object with succeeded/failed counts."
// What Peter would write:
"Handle batch transaction imports for users."
Six words. That’s it. Peter intentionally gives vague prompts to let the agent explore solutions he hadn’t considered. On the Lex Fridman podcast, he described discovering that his agent used FFmpeg and Whisper to process a voice message he sent — a solution chain he would never have specified in a prompt.
I was skepti — no wait, I was terrified. Vague prompts feel like handing your car keys to a stranger and saying “you’ll figure it out.”
But I tried it on three features last week. Two of them came back with implementations I wouldn’t have thought of. One of them was genuinely better than what I had in my head. The third was garbage and I threw it away in 30 seconds.
Two wins and one quick delete. That’s a good ratio. The trick is under-prompting for exploration, not for production. You’re not shipping the first attempt. You’re discovering the approach, then tightening the prompt for the real build.
4. Spend 10x more time planning, 10x less time coding
Most devs I know (including past me, honestly) spend about 5 minutes thinking about a feature and then 4 hours coding it. Peter flips that ratio completely.
He spends a “surprisingly long time” — his interviewer’s words, not mine — going back and forth with an agent just on the plan. He challenges the agent. Pokes holes. Asks “what about edge case X?” Rewrites the approach. Pushes back when the agent suggests something lazy. Only when the plan is airtight does he kick off the implementation and move on to planning the next thing.
This is the developer equivalent of a chess grandmaster spending 20 minutes on one move. Looks slow. Is actually fast. Because the alternative is spending 20 minutes moving pieces randomly and then another 40 minutes undoing the mess.
I’ve been doing this with Claude for my Convex schemas and it’s borderline therapeutic. Instead of jumping into code and realizing 2 hours later that my data model is wrong — but I digress, anyone who’s done a Convex schema migration at midnight knows that particular flavor of regret — I now spend 30 minutes arguing with Claude about the schema design. The actual implementation takes a fraction of the time because the architecture is already sorted.
Peter uses Codex specifically for this reason. He plans the work extensively, then kicks it off on Codex because Codex runs long tasks autonomously. Claude Code keeps coming back for clarifications, which breaks his flow.
Different tools for different humans. The principle stays the same: plan long, code short.
5. Run 5 agents in parallel and read none of them live
Open three terminal windows. Launch three different features simultaneously. Close the lids on all three and go make coffee.
That’s Peter’s workflow. He runs 5–10 agents in parallel on different features and stays in a flow state by not watching any of them work. He checks results when they’re done. Not before.
This sounds like senior developer heresy. We’re trained to watch, monitor, catch errors early. The idea of running 5 autonomous code-writing processes and just… not looking… feels like leaving 5 burners on and going for a walk.
But think about what you’re actually doing when you watch an agent type code in real-time. You’re not adding value. You’re just anxious. It’s the developer equivalent of opening the oven door every 2 minutes to check on the cake. All you’re doing is slowing it down.
I tested this on a smaller scale — 3 agents, not 5. One was refactoring a Supabase auth flow. One was building a new n8n workflow. One was writing tests for existing Convex functions. I set them up with clear prompts (well, clearer than point 3 — I’m not that brave yet), launched them, and went to lunch.
Came back to: 2 completed successfully, 1 failed on a test it couldn’t resolve. I fixed the failure in 15 minutes. Total output: 3 features’ worth of progress in 90 minutes of wall-clock time.
The key insight Peter shared: the flow state isn’t about monitoring agents. It’s about queuing them. Your job becomes prompt engineering → launch → prompt engineering → launch → review batch. Assembly line, not babysitting.
6. Replace code reviews with “prompt requests”
Remember when pull requests used to mean something? You’d open a PR, write a description explaining your changes, a teammate would review the diff line by line, leave comments about variable naming and missing null checks, you’d go back and forth for two days, and eventually someone would approve it because everyone was tired.
Peter considers PRs dead. Not dying — dead.
His replacement: prompt requests. Instead of reviewing the code an agent produced, you review the prompt that produced it. If the prompt is solid and the tests pass, the code is approved. His team doesn’t even talk about code anymore. Their discussions are 100% architecture and high-level decisions.
This is the most controversial point on this list and I’m not fully converted yet. For solo projects? Yeah, it works. I’ve been copying my Claude Code prompts into commit messages instead of writing manual descriptions, and it’s genuinely more useful for future-me to see “what I asked for” rather than “what changed.”
For teams? I think you still need some code review for knowledge sharing. But Peter’s point stands: the prompt is becoming more important than the output. In a world where any decent agent can write the code, the quality of your instructions is the differentiator.
I mean — a dude with 180,000 GitHub stars and offers from Meta and OpenAI says PRs are dead. Maybe the rest of us should at least consider it 🦞
7. Treat 80% of your code as disposable data plumbing
Quick exercise. Open your project right now. Look at your most recently edited files. How many of them are doing something genuinely interesting — novel algorithms, complex business logic, creative UI patterns?
And how many are just… moving data from point A to point B? Parsing JSON. Transforming API responses. Mapping database rows to frontend objects. Validating inputs. Formatting outputs.
Peter’s estimate: 80% of application code is “massaging data in different forms.” And he argues that this 80% doesn’t deserve obsessive human attention. Let the agent handle the plumbing. Save your brain for system design.
This clicked for me when I audited my own Convex project last week. I had 47 files. Of those, maybe 8 contained real logic — the scheduling engine, the billing rules, the permission system. The rest? Data plumbing. Fetching from Supabase, reshaping for the frontend, validating webhook payloads. Important work, but not thinking work.
I’ve started tagging files mentally as “architect” vs “plumber.” Architect files get my full attention. Plumber files get delegated to Claude Code with good tests and I don’t look back. (See point 1.)
The productivity gain isn’t just time. It’s cognitive. When you stop spending mental energy on data transformation boilerplate, you have actual brainpower left for the decisions that matter. It’s like finally clearing your desk of papers so you can actually think.
Bonus: Argue with billionaires about your IDE
This is the part I promised and I still cant believe it’s real.
When Mark Zuckerberg first reached out to Peter about acquiring OpenClaw, their first interaction wasn’t a term sheet. It wasn’t a valuation discussion. It wasn’t even small talk.
They spent 10 minutes arguing about whether Claude Code or Codex is better.
Ten minutes. Peter Steinberger and the CEO of Meta. Debating AI coding tools like two devs in a Discord channel at 2 AM. Zuckerberg later called him “eccentric, but brilliant.”
And when asked on the Lex Fridman podcast about his mindset during acquisition talks with both Meta and OpenAI simultaneously, Peter said: “I don’t do this for the money. I don’t give a fuck.”
Plot twist: today, Peter chose OpenAI. Not Meta. He argued with Zuckerberg about code editors, turned down whatever Meta was offering, and joined the Codex team instead. OpenClaw becomes a foundation, stays open-source, and Peter gets to build “agents for everyone” with the resources of the biggest AI lab on the planet.
In his own words on his blog: “I could totally see how OpenClaw could become a huge company. And no, it’s not really exciting for me. I’m a builder at heart.”
43 projects before OpenClaw. A PSPDFKit exit worth $100M+. Three years of retirement and soul-searching. And now he’s joining OpenAI because building things is more fun than owning things.
That’s not a negotiation tactic. That’s what happens when someone is so deep in the craft that everything else becomes background noise. Peter wasn’t negotiating. He was vibing.
Every counterintuitive habit on this list comes from the same root: caring obsessively about the work and almost nothing about the process around it. Ship without reading. Prompt without overthinking. Plan without coding. Review prompts, not diffs.
The habits sound insane until you realize they all point in the same direction — spend your finite human attention on the things only a human can do, and trust the machines with everything else.
If these habits made you question at least one thing about your workflow — that’s the point. Peter just joined OpenAI today, which means the OpenClaw ecosystem is about to get very interesting very fast. I’m currently testing his “self-modifying agent” setup on my production stack. If you want to see how spectacularly that goes (or doesn’t), follow me and I’ll share the results.
Next up: the OpenClaw security deep-dive that everyone’s been asking for. The one where I tell you all the ways your lobster can betray you. 🔒
Top comments (0)