Peter Steinberger: 'I Ship Code I Don't Read'

A former founder who burned out, sold his shares, and vanished from tech for three years came back and started shipping 600 commits a day. Peter Steinberger’s claim that he doesn’t read most of the code he ships sounds reckless until you understand the system he’s built around it. This nearly two-hour conversation with Gergely Orosz on The Pragmatic Engineer is the most detailed walkthrough yet of what a mature AI-native development workflow actually looks like in practice.

The Setup

Steinberger built PSPDFKit, a PDF framework running on over a billion devices. He started as a freelancer in rural Austria, his first programming device an Amiga (“not a Mac, because we were too poor”). His entry into mobile development came through building a gay dating app for himself, at a time when that took real courage. From there he noticed PDF rendering on iOS was terrible, began building a framework, and grew it into a company of about 60 people over 13 years.

The early days were scrappy: selling licenses through a WordPress template, customers downloading the SDK via Dropbox links. The company grew, but the transition from engineer to CEO gradually pulled him away from code. After 13 years of nonstop operation, he was done.

He retired for three years (2022-2025), didn’t touch programming at all. This period coincidentally covered AI coding tools’ evolution from terrible to remarkably capable. When he returned in April 2025, right as Claude Code’s beta launched, he had no negative bias about AI. He’d skipped the entire phase of “AI coding is unreliable” and embraced the tools with a completely open mind.

Within months he was building OpenClaw (originally Clawdbot), a hyper-personal AI assistant that became the hottest AI project in tech, drawing more Google searches than Claude Code or Codex. The sheer volume is striking: 6,600+ commits in January alone.

“From the commits, it might appear like it’s a company. But it’s not. This is one dude sitting at home having fun.”

Closing the Loop

The single most important concept in Steinberger’s workflow is what he calls “closing the loop.” It’s the sharp line between effective AI-assisted coding and frustrating vibe coding.

AI writes code, but the code must prove itself through automated verification before it’s accepted. Tests, linting, type checking, build validation. If any of these fail, the AI gets the error output and tries again. The human never reads the intermediate code; they read the test results.

“I ship code I don’t read. And that’s not as crazy as it sounds, because I don’t need to read it if the tests pass.”

This only works with heavy investment in feedback infrastructure. Steinberger estimates roughly 40% of his time goes into building and maintaining tests, CI pipelines, and verification systems. The remaining 60% is actual feature development, but at a pace that would be impossible without the closed loop.

He draws a sharp distinction: vibe coding is when you prompt an AI and accept whatever comes out. Closing the loop is when you build the systems that prevent bad code from ever landing. One is gambling; the other is engineering. This is also why AI is genuinely good at coding but mediocre at writing: code can be automatically verified, prose cannot.

Why Code Reviews Are Dead

Steinberger’s most provocative claim: code reviews as traditionally practiced are obsolete.

When AI generates thousands of lines per day, human review becomes a bottleneck that doesn’t scale. More importantly, the reviewer lacks the context that the AI had when generating the code. You end up skimming diff views, catching cosmetic issues, and missing actual logic bugs.

His alternative: invest review energy into better tests. A comprehensive test suite catches more bugs than a human reviewer, runs instantly, and scales infinitely. When receiving PRs for OpenClaw, he reads contributors’ prompts more than their code.

“Pull requests, I see them more as prompt requests now. I read the prompts more than I read the code.”

He tells contributors: write up your prompt really well, because then he can point his agent to the issue and it will build it. Small fix PRs actively frustrate him: “Please don’t do that. It takes me 10 times more time to review that. Just type ‘fix’ in Codex and wait a few minutes.”

PRs have become discussions about architecture and taste, not line-by-line code inspection. When someone submitted a PR adding voice calling, instead of merging directly, he had Codex analyze the PR alongside his existing project, designed a plugin architecture, and reimplemented it properly.

The Architecture of Working with Agents

Steinberger’s daily workflow looks nothing like traditional development.

Multiple AI providers in parallel. He uses Claude Code for complex reasoning and Codex for broad refactoring, running 5-10 Codex agents simultaneously on independent tasks. When he needed to switch OpenClaw from single-agent to multi-agent architecture, Codex handled the refactor in three hours. It would have taken him two weeks.

Planning is lightweight and iterative. He doesn’t write detailed specs upfront. His mental model is a spiral: you don’t climb straight up the mountain, you circle around it, sometimes straying from the path, eventually reaching the top. Against upfront planning tools like Gastown:

“How can you even know what you want to build before you built it? You learn so much in the process of building it.”

Context management is critical. He uses CLAUDE.md files extensively, project constitutions that tell AI tools about codebase structure, conventions, and constraints. These serve as persistent memory across sessions. He designs the codebase not for himself but for the agent: naming, structure, and file organization optimized for model comprehension.

Testing as first-class architecture. Tests aren’t an afterthought; they’re the primary feedback mechanism. He writes test specifications before feature code, lets AI implement both, and trusts the test results over code inspection.

OpenClaw: Building What Siri Should Have Been

The original vision wasn’t even Clawdbot but “amant machina” (the loving machine): a deeply personalized AI that would remind you that you haven’t contacted a certain friend in three weeks and they happen to be in town, or notice that you’re always sad after meeting a particular person. Models weren’t capable enough in summer 2025, so he shelved it.

He started simpler: a WhatsApp relay triggering agent tasks on his computer from his phone. The turning point came during a trip to Morocco. The agent autonomously handled voice messages, a capability he’d never explicitly programmed. Stunned by its resourcefulness, he kept adding skills: Google Places, Sonos speakers, home cameras, bed control, lighting.

The build strategy was pure Unix philosophy: everything as a CLI.

“I was just building CLIs for everything: for Google, for my bed, for lamps, for music.”

CLI vs MCP: A Surprisingly Strong Opinion

Steinberger’s criticism of MCP is specific and structural:

• MCP pre-exports all functions and descriptions when the session loads, polluting the context window
• It returns massive amounts of unnecessary data (a weather query returns 50 fields when you just want to know if it’s raining)
• It cannot chain calls (can’t “get cities over 25 degrees, then filter for specific information”)
• Installing new MCPs requires restarting Claude Code

CLI advantages: agents natively understand Unix, can use jq to filter JSON, can compose via pipes. He built make-porter, a tool that converts MCPs to CLIs. Users can say on their phone “use the Vercel MCP to do X,” and the agent will find the MCP, load it, and use it.

His nuanced take: MCP’s greatest contribution isn’t the protocol itself but that it made companies rethink opening up more APIs. The ecosystem effect matters more than the technical implementation.

Going Public on Discord

On January 1st, Steinberger made what he calls an “insane” decision: he put an agent with full read/write access to his computer into a public Discord server. People could watch him using the agent’s full power: checking cameras, controlling home automation, playing DJ, having the agent look at his screen and report on other agents’ work status.

The result: from 100 to 3,300 GitHub stars in a week, 500 merged pull requests.

The agent’s onboarding flow for new users is particularly clever: a one-line install command, then the agent guides you through identity creation, asking your name, interests, and values. It generates user.md, soul.md, and identity.md files. These are evolving documents that the agent continuously updates during interactions. The agent can even self-update.

What Changes for Engineers

The conversation surfaces a layered view of which skills remain valuable:

Still essential: Systems thinking, taste in product design, knowing what to build, understanding failure modes, writing good tests, architectural coherence.

Diminishing: Memorizing APIs, writing boilerplate, manual code review, detailed upfront specs, holding large codebases in your head.

Newly critical: Building verification systems, managing AI context windows, knowing when to use which tool, and the discipline to not ship without tests even when AI makes it temptingly fast.

Steinberger pushes back on “junior developers will be replaced.” His view is more radical: the entire workflow is restructuring, and senior engineers who refuse to adapt will lose their leverage advantage over juniors who embrace AI. New developers have a surprising edge: “They use agents in ways that we don’t even think about, because they don’t know that it doesn’t work, and by then it probably does.”

On the economics: if one skilled developer with AI tools can match a team of five, what happens to software companies? Rebuilding PSPDFKit with AI, he estimates, would require about 30% of the original headcount. He’s careful to note this doesn’t mean developers are obsolete. It means the bar for what one developer can accomplish has shifted dramatically upward.

The Addiction of Building Again

“I’ve never worked so hard as I do now. Not because I have to, but because it’s so addictive and so much fun.”

Managing multiple AI agents is mentally more exhausting than writing code yourself. His sanity strategy: going to the gym, locking the phone in the locker. “I really have a good hour where I just feel me.”

A small detail that says a lot: the tech product that brings him the most joy isn’t the iPhone 17 (bought but still unopened) but a $200 Android photo frame.

Afterthoughts

This is currently the most detailed first-person account of what all-in AI-native development looks like at production scale. Steinberger isn’t theorizing; he’s describing a workflow running at extreme volume for months, with a high-profile open source project as proof.

• The “close the loop” principle is deceptively simple but separates everyone who gets results from everyone who gets frustrated. Most developers skip the verification infrastructure because it’s boring. That’s exactly where the leverage is.
• “Prompt requests” replacing pull requests isn’t just a quip. If a contributor’s value lies in clearly expressing intent rather than writing code, the entire open-source collaboration paradigm shifts. Steinberger says he judges contribution quality better by reading prompts than code.
• His CLI vs MCP stance deserves serious attention from technical decision-makers. Under current agent capabilities, the Unix philosophy (small tools, pipe composition, text streams) fits agent workflows better than structured protocols. This may change as agents evolve, but in early 2026 it’s strong engineering intuition.
• The burnout-to-return arc is its own signal. If AI tools can re-engage people who left the industry because organizational complexity killed the creative spark, that’s a workforce story as much as a productivity story.
• His monthly commit counts are eye-catching, but the real metric is that OpenClaw works and people use it. Volume without quality is noise; the test infrastructure is what converts volume into signal.