Peter Steinberger built PSPDFKit, a PDF rendering framework used on over a billion devices, ran it for 13 years, burned out, sold his shares, and stepped away from tech for three years. He came back in early 2025 and now builds software in a radically different way using AI agents, most notably through his project Clawdbot (now called OpenClaw), a hyper-personal AI assistant that blew up from 100 to over 3,300 GitHub stars in a single week after he put it in a public Discord.
His core claim: he ships code he doesn’t read, runs 5–10 AI agents in parallel, and has done 600 commits in a single day, none of which he considers sloppy.
The key ideas: closing the loop (agents must be able to test and verify their own work), treating prompts as the primary artifact rather than code, acting as an architect/builder rather than a hands-on coder, and designing systems specifically so agents can navigate them efficiently.
How Peter got into tech and built PSPDFKit
Grew up in rural Austria, got hooked on computers at 14 through a summer guest’s machine, started by writing copy-protection for DOS games and selling them.
First real job was in Vienna maintaining a legacy Microsoft MFC application; he secretly rewrote parts in .NET without telling his boss.
Got an iPhone in 2009/2010 and was immediately captivated. Built a third-party client for a gay dating app by scraping HTML with regular expressions, charged $5, made $10K in the first month, and decided to go independent despite his boss mocking the decision.
At a party at 3 a.m., got a call from Apple saying his app was removed for policy violations. That ended the app, but he’d already caught the startup bug.
While freelancing, someone asked him to fix a terrible magazine viewer app (one file, thousands of lines of Objective-C, using windows as tabs). He rewrote the PDF viewer portion in two months, extracted it, and started selling it as a component.
Used a WordPress template on GitHub Pages, a Fastlane flow, and a Dropbox link to distribute the source. Three people bought it in the first week at $200 each.
Kept adding features (text selection took 3 months), raised prices gradually, and by the time he moved to San Francisco for a job, PSPDFKit was already out-earning his salary.
Eventually chose to leave the US job and go all-in on PSPDFKit. Grew the company to ~70 people (now nearly 200) over 13 years, all remote-first from Vienna.
Marketing strategy: only target developers directly through high-quality technical blog posts and conference talks. Never did cold outreach. Developers would lobby internally for the product.
Tech stack evolved from Objective-C to a shared C++ renderer across all platforms, and they were early with WebAssembly for browser-based PDF rendering.
Cleverly built a benchmark that Google, Microsoft, and Apple all adopted as a WebAssembly benchmark, effectively making those companies optimize for PSPDFKit’s renderer.
PSPDFKit culture and hard problems
Every feature started with a written proposal. The team followed the boy scout rule and was conservative with API changes since many companies depended on it.
Peter forced every team member to spend one full day per month writing a blog post. He saw writing as a way to deeply understand problems and as living company documentation.
One example of a deceptively hard problem: a customer’s 50,000-page Bible had over 500,000 internal links, blowing up Peter’s data model (which assumed a few hundred links). Redesigning the internals to be lazy-loaded without breaking the public API took two months.
Peter personally handled support tickets, often replying within 5 minutes. He believed this was a key factor in the company’s success.
Burnout and the three-year gap
Burnout came from working most weekends, being the “waste bin” for every unresolved issue, loneliness of leadership, and trying to run the company too democratically.
One 5 a.m. call from his co-founder: a major airline’s planes were down because of a PSPDFKit crash. Peter disassembled their app and proved they’d modified the source code, triggering a license key fallback that caused the issue.
After selling his shares, he spent months not turning on a computer, struggled with the identity loss of early retirement, and slowly decompressed.
Returning to tech and discovering AI agents
Came back in April 2025 wanting to build a Twitter analytics tool as a web app, despite not having touched web development (React, etc.) in years. Found the experience of being bad at something again painful.
Tried Claude Code (which had just come out in beta) as his first AI tool, having missed GitHub Copilot, GPT-3.5, and GPT-4 entirely.
His first test: fed a 1.3 MB markdown file (a converted GitHub repo) into Gemini, asked for a spec, got 400 lines, fed that into Claude Code, and told it to build. It said “100% production ready.” It crashed.
Added MCP for browser access, let it loop for a few more hours, and got a working Twitter login page. That was his “holy mind-blowing moment.”
The addictive quality: he describes it as a slot machine. You type a prompt, and sometimes it does something mind-blowing. He was up at 5 a.m. regularly, and started a meetup called “Claude Code Anonymous” because the compulsion to keep prompting felt like a drug.
Peter’s current workflow: agentic engineering
He rejects the term “vibe coding” and calls it “agentic engineering.” The mundane code-writing is automated, but the cognitive load is higher, not lower, because he’s managing 5–10 agents in parallel.
He compares it to Starcraft: a main project with satellite projects running simultaneously, constantly context-switching between them.
He’s in a flow state more than ever, but it’s mentally more taxing than writing code himself.
Tool progression: started with Claude Code, tried Cursor and Gemini 2.5, went through an Opus 4 phase, and settled on Codex (OpenAI) as his primary tool for complex applications.
Codex is slower (reads files for 10 minutes before acting) but far more thorough. Claude Code is faster but requires more steering and produces lower-quality output on the first try.
He runs 5–10 agents in parallel, each working on different subsystems.
The conversation model: he doesn’t just write prompts and walk away. He has a dialogue with the model: “What are our options? Did you consider this? What about this trade-off?” He discusses architecture, and only says “build” when he’s ready. The model won’t build until he uses trigger words.
He sees himself as the architect/builder who has system-level understanding but delegates line-by-line code to agents.
Closing the loop: the single most important principle. Agents must be able to compile, lint, test, and verify their own output. This is why AI is good at code but mediocre at creative writing—code has a validation loop, writing doesn’t.
He designs systems specifically to be verifiable: CLIs that can be run headlessly, Docker-based integration tests, automated test suites that spin up the full stack.
Example: when tool calling broke across multiple providers (Anthropic, OpenAI, GLM), he had Codex design live tests that spun up Docker containers, installed the whole thing, exercised the loop with real API keys, and fixed all the edge cases automatically.
He believes this principle makes him a better engineer now than when he wrote code himself, because he’s forced to think about testability and architecture upfront.
Testing and documentation: he doesn’t write tests or documentation himself. He explains the trade-offs to the model and asks it to write beginner-friendly docs with technical detail at the end. He’s never had a project with better documentation.
He no longer cares much about CI (continuous integration) pipelines. The agent runs tests locally before he merges. If local tests pass, he merges. Main occasionally breaks, but rarely.
Clawdbot / OpenClaw: the hyper-personal assistant
The original idea (years old, predating the break): a deeply personal AI assistant that knows you—not a “good morning, here are your tasks” bot, but one that notices you haven’t texted a friend in weeks, knows they’re in town from Instagram, and suggests you reach up. Or notices you’re always sad after meeting a certain person and asks why.
He initially incorporated a company called “Amor Machina” (the loving machine) for this vision. The tech wasn’t ready in summer 2025, so he shelved it temporarily.
Started as “WhatsApp Relay”: a way to trigger actions on his computer via WhatsApp. Built it while traveling in Morocco, used it to navigate the city, make jokes, text friends, and even process voice messages (the agent figured out how to convert OGG to text using FFmpeg and OpenAI’s API on its own—this was Opus 4.5).
Added a heartbeat system: the agent pings every few minutes, checks a task list, and can be proactive. Used it as an alarm clock that turned on music and got louder until he responded. He called it “probably the most expensive alarm clock ever.”
Renamed to Clawdbot (from “Claudius,” a Doctor Who joke), then to OpenClaw. Put it in a public Discord with full read/write access to his computer. People saw it check cameras, do home automation, play DJ, and click through the terminal by watching the screen.
Went from 100 to 3,300+ GitHub stars in a week. He’s merged 500+ pull requests and describes himself as “a human merge button.”
Why CLIs over MCPs: Peter argues MCPs are a crutch. They require pre-exporting all functions and descriptions into context upfront, send rigid JSON blobs, and can’t be chained or filtered easily. CLIs let agents use standard Unix tools (grep, jq) to filter exactly what they need. He built “make-portal,” a tool that converts MCPs to CLIs on demand.
The one good thing about MCPs: they pushed companies to open up more APIs.
Onboarding: there’s no manual setup. Users type a one-liner, and the agent checks for Node, Homebrew, installs packages, and configures everything. For the first two weeks after launch, onboarding was literally “point Claude Code at the repo and have it configure itself”—which worked because the product was built by agents and structured the way agents expect.
The bootstrap experience: when you first start the bot, it goes through a “birth” process. It asks who you are, what your name is, what matters to you. It creates user.md, soul.md, and identity files that evolve as you interact. People stop thinking they’re talking to GPT-4 and start talking to “Vajra” (a unicorn with part of their name) or “Claude” as a friend.
Memory system: the bot remembers context across interactions—events you’ve seen, calendar conflicts, what friends have said. Peter describes it as “the technology blends away” and you’re just talking to a friend on your phone who happens to be infinitely resourceful.
Token-hungry: the bot spawns sub-agents and does extensive background work. Peter jokes that he’s “the best marketing tool for Anthropic” because so many people signed up for $200/month subscriptions because of Clawdbot.
How Peter thinks about code, PRs, and reviews
“I ship code I don’t read”: most apps are “pretty chasing printers”—data comes in one form, gets parsed, stored, retrieved, rendered. The plumbing is boring. He cares about system architecture and structure, not whether a specific Tailwind class is used or how a button is aligned.
He still cares deeply about structure: a recent PR was a 15,000-line refactor to a plugin architecture that he was very excited about. He just didn’t read every line.
PRs are now “prompt requests”: when someone opens a PR, he’s more interested in the prompts they used than the code. Prompts reveal how they thought about the problem, what they asked, and how much steering was involved. He asks contributors to include their prompts.
He rarely merges PRs as-is. He uses the PR as a starting point, discusses the approach with an agent, reshapes it to fit his vision, and weaves the code in. Sometimes he rewrites the entire thing.
He tells contributors not to send small fix PRs—it takes him 10x longer to review than to just type “fix this” into Codex and wait a few minutes.
Code quality of PRs has dropped: many contributors vibe code without understanding the overall design, so their PRs don’t fit the architecture. Understanding the system is still essential for steering agents effectively.
How software engineering is changing
Planning has changed: at PSPDFKit, every feature started with a detailed written proposal because building was expensive. Now, Peter plans less upfront because it’s so cheap to try things, see the shape, and iterate. He describes building like sculpting marble—you start with a rock and chip away, rather than climbing straight up a mountain. You spiral upward, sometimes straying off path, but eventually reach the top.
He doesn’t believe in tools like “Gatson” where you write a spec and it builds itself. You can’t know what you want to build before you build it. The process of building informs the design.
If he rebuilt PSPDFKit today: he could run the company with 30% of the people. He’d want senior engineers who understand what they’re building, are comfortable delegating, and know which parts matter and which can be vibed. He’d avoid elaborate orchestration layers (auto-creating tickets, agents emailing agents) as the “waterfall model of software building.”
Large companies will struggle to adopt AI: it requires redefining not just the codebase but the entire company structure. Current companies have rigid role definitions (engineer vs. manager vs. designer). The new world needs fewer people with high agency and high competency who can do everything. He estimates companies could be trimmed to 30% of their current size, which he acknowledges is economically scary.
He optimizes his codebase for agents, not for himself: files and structures are named and organized the way models expect (encoded in the model’s weights). He accepts trade-offs he wouldn’t personally prefer because they reduce friction for the agents.
Advice for different audiences
For experienced engineers: play with the technology. It’s a skill like any other—frustrating at first, then rapidly improving. The people who struggle most are those who love solving hard algorithmic problems (because AI does that well) and those who can’t let go of controlling every detail. The people who thrive are those who care more about the product outcome than the plumbing.
He looks for people active in open source on GitHub who “love the game” and are infinitely curious.
For new grads: it will be harder to enter the market. Be infinitely curious. Study complex open source projects and use AI as an infinitely patient tutor—ask “why was it built this way?” to gain system understanding. You don’t need to write a lot of code, but you need system understanding. Your advantage: you’re not tainted by old habits, and you’ll use agents in ways experienced developers don’t think about because you don’t know it “doesn’t work.”
For anyone: the way to learn is by building things. It feels like a game where your skills improve as you play, like a musical instrument. It’ll suck at first, like going to the gym, but you’ll quickly feel the improvements and get hooked.
What hasn’t changed
Peter still works harder than ever—more hours than when he ran PSPDFKit. Not because he has to, but because it’s addictive and fun.
He still cares deeply about how products feel, about polish, about the details that make software delightful. PSPDFKit succeeded because it felt the best, not because it had the most features. Clawdbot succeeds because the technology “blends away” and it feels like talking to a friend.
The fundamental challenge of software is still making complexity feel magical. At PSPDFKit, it was hiding the insanity of the PDF format behind a clean API. With Clawdbot, it’s hiding the token-hungry sub-agent orchestration behind a simple WhatsApp conversation.
Rapid fire
Favorite non-CLI, non-IDE tool: a cheap Android-powered digital photo frame (~$200) that has an email address. Friends can send photos, and it displays them. It gives him more joy than any gadget he’s bought, including an iPhone 17 he hasn’t unpacked.
How he recharges: going to the gym with a coach and leaving his phone in the locker. Or going for a walk without his phone, which feels “almost like an organ”—your body knows where it is, and not knowing causes genuine anxiety.
