What if you could merge 600 commits on a single day and none of it was slop? This is what today's guest, Peter Steinberger, the creator of Clawdbot, claims he's doing. Peter is a standout developer who built PSPDFKit, the PDF framework used on more than 1 billion devices. Then he burned out, sold his shares, and disappeared from tech for 3 years. This year, he came back, and how he builds and what he's doing now looks nothing like traditional software development.
In today's episode, we cover why he no longer reads most of the code he ships, and why that's not as crazy as it sounds. How he is building Clawbot, his wildly popular personal assistant project, which feels like the future of Siri. The "closing the loop" principle that separates effective AI assistant coding from frustrating vibe coding. Why he says code reviews are dead and PRs should be called "prompt requests," and many more.
If you're interested in how the software engineering workflow could change in the coming years thanks to AI, this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics experiments, and more. Check out the show notes to learn more about them, the Pragmatic Summit on the 11th of February in San Francisco that I'm hosting with them, and our other season sponsors. Right, Pete, welcome to the podcast.
Thanks for having me, Gergely.
It is awesome to meet you in person.
Yeah, and I almost messed it up.
Yeah. What happened? You lost track of time. Does that happen often? And how so?
Not usually. Not usually. This is an interesting time for me because my latest project is blowing up. Clawd, right?
Clawbot. Yeah.
Clawbot. I'm struggling a bit to get enough sleep, but it's interesting. I never had a community blowing up so fast and it's just incredibly fun to work with.
So, before we get into Clawbot and all the fun stuff you're doing, I wanted to rewind all the way back. You created PSPDFKit which is used, I think, on more than 1 billion devices. If you see a PDF render, you probably see that. But even before that, how did you get into tech?
Oh my god. How did I get into tech? So I'm from rural Austria. I was always more of the introvert. Eventually, we always had summer guests and one of them was a computer nerd. I kind of got hooked with the machine he had and begged my mom to buy me one. Ever since then—this was in high school or so—I guess I was 14.
Ever since then I started tinkering. I can remember the earliest thing was like I stole an old DOS game from my school and then wrote a copy protection for the floppy disc so I could sell it. It took like 2 minutes to load. I was just always tinkering. Also playing a lot of computer games of course, but building stuff almost feels like playing a computer game. Right now it feels better than Factorio.
When I started out, I did the equivalent of bash scripts for Windows and then I did websites. So, I guess a little bit of JavaScript, even though I had no clue what I was doing. And then the actual first language where I had to learn how to build things is when I started university. I never met my dad, and I come from a poor family. So, I always had to work; I had to finance my own studies, right? So when other people were having holidays, I just worked full-time at a company.
The first real job I had in Vienna was supposed to be 1 month and then they kept me for 6 months. It was just a bridge between military and my university. I kept working there for like 5 years. I remember the first day they gave me this huge book, maybe that huge, and said "Microsoft MFC." I still have nightmares. I was like, "This is terrible." For the next week, I just silently used .NET. I just didn't tell them. A few months in, I just told them, "Yeah, about the tech stack..." I did a few modernizations, but then it was too late. I did this a few times in this company. I don't know why they kept me, but my stuff worked.
So I did .NET and I liked it. .NET 2.0 had generics. It took insanely long for the application to launch because everything was compiled at first start and your hard disk was like... if you remember.
So how did you stumble into both iOS and where did the idea for PSPDFKit come from?
Not even... yeah, the first one wasn't even available in Austria. That's true.
A little time went on and I was at university and a friend showed me the iPhone. I think I touched it for a minute and then immediately bought one. It clicked when I felt it. To me, this was like a "holy f" moment because it was just so different and so much better. So I got one. I was still not thinking about building for it. That was... when was this? 2009, 10, something like that.
Yeah. And then I used their browser. I can tell the story. I was literally riding in the subway. By that time I was using a dating app and this was iPhone OS 2. Long time ago. I typed this long message, I pressed send, and we were just going into a tunnel. The JavaScript disabled the send button and then an error message came, but there was no copy-paste. There was no screenshot. I was just like... and I couldn't scroll anymore because scrolling was disabled.
So this long message, which was a little bit emotional, was gone and I was so mad. I was so mad. I'm like, "What the hell?" I went home and I downloaded Xcode. That's where the window came and I was like, "Where is the IDE?" It was like... I was like, "This is unacceptable." I hacked the website. I used regular expressions to parse the HTML, which is totally not something you should do, and I built an app.
I used iPhone OS 3 beta with Core Data in beta. I used a hacked version of GCC that backported the blocks compiler so I could use blocks in iPhone OS 3. It took me quite a while until anything worked because I had no idea what I was doing and I was using all kinds of beta tech. But eventually, I got it to work and I wrote to that company: "Hey, I'm making an app. What do you think about it?" Got no response, of course. So I was like, "Let's just put it in the App Store."
And this was for the dating app, right?
Yeah.
So you just looked at their APIs and you could just easily build a client on top?
API? It was HTML. I was just literally parsing HTML.
Oh. So you kind of parsed the HTML and turned it into your own... like you used it as an API. Oh, clever.
I mean, this was back in the day where no one thought this would happen. But I put it in the App Store. I charged five bucks for it and I made like 10k in the first month. And I had no clue what I was doing. There was so much complex tech stuff. This was very early on where there were a lot of weird forums on Apple. So, I just put in the bank account of my grandpa. And then one day my grandpa called me: "Yeah, something is weird. I got this huge payment from Apple." I'm like, "This is mine. This is mine. Don't touch it."
But the funny thing was when this blew up, I remember I was in a club one day and I saw someone using my app. I was so proud and I wanted to tap him on the shoulder and say "I built this," but then I thought that would be really weird. So I didn't. And then I went to the company I worked for 5 years and told them I'm going to pursue this. This is really exciting. And my boss was like mocking me.
Oh, really?
They're like, "Oh, you're making a mistake. This is a fad. This will not go." Blah, blah, blah. And what that got me? That's what you call a chip on your shoulder. I'm like, "One day I'm going to have a company that's worth more money than yours." Well, it took me eight years. So, I got hooked. I'm a little bit of an addictive personality, which you see again right now.
But I worked a lot on this app. I learned in high speed and this was also the time where I started Twitter, and that was hugely influential for my career. I made this app quite good and then one day I was at a party at 3:00 a.m., slightly intoxicated, and I got a call from a US number. The guy on the phone was like, "Yeah, hello. This is John from Apple. Yeah, there's a problem with your application." Like some people reported pictures, and that was it. That was the end of my app.
It was good while it lasted.
And I just quit my job and was like, "Well, f you, Apple." I did freelance work. I was at WWDC. I was introduced to someone as one of the best iOS developers in Austria at a bar at 2 a.m. in San Francisco. Then I got a job in the US and moved there for a while. Then I went to the Nokia development days. This is all like Stone Age by now. My god.
Someone came up to me and said, "Yeah, they built this app somewhere in Eastern Europe and it works but it crashes sometimes." It was like a magazine viewer, right? This was back when the iPad just came out and Steve Jobs hit that "this is the savior" note. Everybody was building magazine apps and I was like, "That sounds like an interesting short-term gig." I opened the app and it was the worst code I've ever seen in my life. It was literally one file with thousands of lines of Objective-C.
They used windows as tabs. I didn't know this worked. I was surprised this worked at all, but it felt like a house of cards. I tried to surgically fix things, but as soon as you would touch something, something else would break. So I got it somewhat stabilized and I told them: "Look, this is madness. I'm going to rewrite this for you in a month." Well, it took me two months. I wasn't that far off. And then here I was working on a PDF viewer.
On every technical problem, the domain is I wouldn't say completely unimportant, but you can always find interesting problems in every domain. There were a lot of interesting problems because you had a C call that would render a PDF that would maybe take 30 megabytes, but the whole system had 64 megabytes. So if you're not very smart and very careful about what you do in the background, the OS would just kill you. I got really fixated on making it good—like when you rotate, the page would animate. I like those details. I spent way too much time on that.
The end result was good. I worked with them for a while and then a friend texted me: "Yeah, I'm working on this magazine app and it's really hard." I'm like, "Yeah, no way it's hard. I just built one." And he was like, "Can you get me the code?" I'm like, "Sure." So, I extracted the part that was PDF from this magazine app—I made sure the other person was okay with it—and then I sold him that. I was like, "Well, if he's interested in that, let's try to sell it to other people."
I used a WordPress template and mutilated it to run on GitHub Pages. When you did the fastlane flow, at the end you got a Dropbox link to my personal Dropbox with a source code zip. I put this up one afternoon and I tweeted it. In that week, three people bought it. It was like 200 bucks back then. For me, this was amazing. I got three people who just bought it and 10 people who complained because they wanted features it didn't have. I got nerd-sniped. I was like, "Oh, I don't have text selection? How hard can it be?" Three months later: "Oh, yeah. It's really hard." Text selection in a PDF specifically.
There's a saying that companies are built by young people because they don't know how hard it is.
Yes. I had no idea what an insane madness this file format is.
Peter was talking about how some problems look deceptively simple. PDF rendering is a good example. You look at it and think, how hard could it be? And then you spend months on edge cases that you didn't even know existed. This "looks easy until you build it" pattern shows up in other places, too.
Internal tooling for feature flags and experimentation is a classic example. Teams often underestimate how much work it is to build infrastructure around these tools. There's a reason big tech companies like Uber invested years into building internal experimentation and feature flagging systems. Which brings me to Statsig, our presenting partner for the season. Statsig gives you the complete toolkit without building it yourself. You get feature flags, experimentation, and product analytics all in one platform tied to the same underlying user assignments and data.
In practice, it looks like this: you roll out a change to 1% of users first. You see how it moves the top pipeline metrics you care about—conversion, retention, whatever is relevant for the release. If something goes wrong, instant rollback. If it's working, you can confidently scale it up. Companies like Notion went from single-digit experiments per quarter to over 300 experiments with Statsig. They shipped over 600 features behind feature flags, moving fast while protecting against metrics regression. Microsoft, Atlassian, and Brex use Statsig for the same reason. It's the infrastructure that enables both speed and reliability at scale. Statsig has a generous free tier to get started and Pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com/pragmatic. And now, let's get back to Peter and why rendering PDFs was a surprisingly hard problem.
I remember a few weeks ago someone emailed me. They did something with PDF and they wanted my help. I just wrote them: "I'm sorry, I did my deed. I know more about PDF than any sane human person ever should know. I went to therapy. Good luck." But that took off. While I was waiting for my visa, I worked on this project and more people kept on buying it. It was summer; I was lying at the lake and got another email that someone bought it for 600 bucks, 800 bucks. I just upped the prices as it had more features.
By the time I went to San Francisco to work at this company, it already made more than what I made there. But I still thought I had to be there.
So you moved to San Francisco?
Yeah. And also interestingly, I ended up having to build something with my framework at that company too. But startups are not just 8 hours; they're a little more. And my personal project was also a little more. So my sleep was a little less.
Eventually after 3 months, Sabine, my manager, came over and said: "Peter, are you okay?" They gave me a choice to either keep working at this company and drop my project, or vice versa. I had one week to decide. The counter was one week to stay there or leave the country because I was on a complicated visa. Well, the decision was quite easy: "Yeah, I want to do my own thing."
And at this point, it was already taking off. You already saw that this is a big business. It will probably pay you as much as your US job would have paid.
It was never money-driven.
So what were you driven by?
I want to make stuff that other people find amazing. I love tweaking the details. I love those little delights. It wasn't even that there weren't competitors in the space. But my angle was always that I built something as if Apple would have built it—with all the love and care and polish and those little delights that a lot of people in the industry don't get.
So even though we had competitors that had way more features and were around way longer, my company was more successful and my product was more successful because developers tried the different ones and mine just felt the best. I think software is all about how it feels much more so than the feature set. Why did we buy Apple stuff? It has more features than Windows? No, but it feels better.
So, how did you go from leaving this company and building this PDF component that started to sell, to hiring the first person? At what point did you realize there's something more to this?
When I went back to Vienna, I was like, "Okay, I have to go all in." That's where I started working with freelancers a little bit. Way too late, to be honest. I could have hired much earlier, but it's a big step.
That's kind of where it started having a life of its own. I spent pretty much 13 years of my career building this product with this weird name that I never changed because I thought about it for five minutes and then stuck with "PSPDFKit."
PSPDF.
They finally did a rename, but I wouldn't have renamed it.
It's a mouthful, but it's very unique.
Well, you get it if you do Objective-C because it's just a namespace.
At the time it made perfect sense. My strategy for marketing was always that I only care about the developer. I know upper management makes the decisions, but if I can convince the people inside the company, they do the marketing and lobbying for me. That worked really well. We never did cold emails or aggressive marketing. It was all inbound. All we did was make good stuff and write insightful technical blog posts.
I went to a lot of conferences. For me, it was important that if people understand that the people who built this product know what they do and love what they do, that reflects on the product. That worked really well.
And then what was the tech stack behind PSPDFKit? Was it Objective-C? Was it later Swift? Were there other technologies like C++ or anything else?
We eventually expanded to all platforms. A big shift was switching out the renderer—which was, and is, still quite buggy—to a big C++ one that we used across all frameworks. We were really early with Web. We were one of the first PDF frameworks that ran in WebAssembly. I did the most clever thing: in the very early days when WebAssembly was just taking off, we built a benchmark. That benchmark was eventually used by Google and Microsoft and Apple. I had all these companies working really hard on making my renderer faster because they used our benchmark as one of their own benchmarks.
Ah, nice. And as the company grew, one thing that I remember about PSPDFKit is you did write a lot of blogs. One blog in 2019—this was about year 9 or 10 in the company—was about how the team worked. You mentioned things like every feature starts with a proposal. You mentioned that you are conservative because it's a big API that people use. You mentioned the Boy Scout rule. How did you put together the culture of this team, which was now closer to 30 or 60 people?
We were 70 when I sold my shares and now it's almost 200. I knew right from the get-go that I'm not going to find the people that I need in Vienna. So it was always remote-first, and eventually we landed on some kind of hybrid model which made things a bit more complicated. I learned a whole lot on the go. I never had the urge to be CEO; I always wanted to be coding. I brought people in who helped me a lot with other parts. On the business side, I can do it and I think I'm quite good at it, but I just don't enjoy it. Like even on sales calls where you have to think of the magic number of how much it would be worth because that's how enterprise works.
Peter just said, "Ah, the worst about enterprise sales." Because selling to large companies, enterprises, is as tricky as it gets. Not just because you need to get pricing right, but because of all the enterprise features that you need to build. And this leads us nicely to our season sponsor, WorkOS. If you're building with AI agents or automation tools, here's a problem most teams don't think about at first: once an agent can take actions on your behalf, you need to control what it's allowed to do. Traditional OAuth just wasn't designed for that.
That's why WorkOS introduced MCP Auth, which gives teams a way to authenticate AI agents with explicit permissions, auditability, and enterprise-grade security. Instead of sharing over-scoped API keys, you can define clear boundaries for the data that agents can access and the actions they can perform. If you're building AI-powered features and want to ship fast without compromising security, check out workos.com/mcp. And with this, let's get back to Peter and enterprise pricing.
But that's also the only thing that really works on a model like this.
You mean enterprise sales specifically, right? Meaning custom pricing. So can you tell the devs listening, who go to a vendor's website and they're frustrated that there's no price—it says "call us" or "schedule a meeting"—why that is?
Oh, that's why: because we're going to look at your company and then just take the dice and think about the number that you're probably willing to pay. That sounds horrible. But also, when you have a product where you can't really tear it down to a specific number, it makes a difference if a freelancer contacts us or one of the big Fortune 500s. The usage will be different, the value they get out of it will be different, and charging the same would either exclude one or the other.
If I go too low, they're going to see it as fishy. Procurement for 500 bucks? We're not even going to start the process. And if we target it too high, we're going to lose those people. So as horrible and unfair as this process seems for some kinds of products, it is the most fair way after all. You know, in software there are four axes: easy, hard, interesting, and not interesting. We were very much in the "not interesting and hard" part. If you build something that every developer wants to build, it's going to be a hard sell.
Yeah.
But if it's too easy or too interesting, good luck. But if it's "Oh god, I don't want to do this" and "Oh my god, this is hard," that's a good spot to be in. So I found a really interesting niche and there were just an infinite number of complex problems.
You need to tell me one or two hard things about parsing PDF. How hard could it be? There's a specification. I'm an engineer, I know specifications. What's so hard about it?
There was this one example where PDFs have links. There's a table of contents, you click on it, and it goes to page 37. So, I built this whole model with the assumption, "Oh yeah, maybe there are 100 or 400 links in there." And then we got this one customer who paid really good money. And then they were like, "Oh, it takes 4 minutes to load a PDF." I looked at it and it was a 50,000-page text bible from Canada and it had...
50,000 pages?
It had more than 100 links per page.
500,000 links.
My data model completely exploded because my assumptions were off by a factor of 1,000. Но by then you have a mature product with an API. So how do you completely redesign the internal part without breaking things for everyone? Suddenly everything has to be lazy, whereas before parsing 100 links was easy. This was so difficult to keep it working for people. I think I spent like two months just on that—completely redesigning the internals and making sure it's still easy for people.
I love to do support, and I think that was a defining factor why the company worked. Because if you send a ticket and the CEO replies and helps you out, that has impact. My strategy was always to list in reverse, because if you send a ticket and get a reply within 5 minutes, that's magical. If you wait one or two days, there's not much difference. This was one of the problems where I worked two months and finally got it down.
That must have been satisfying.
It was very satisfying.
And you were writing a lot of the code or you were involved in a bunch of the code? Obviously a big team was here, but you were still overseeing it, right? You're in the details.
Of course. I had a really great team and in some parts I was more involved. I was always more involved in mobile because that's where my heart was, but I was always very deep in the tech. On the marketing and business side, I had help.
If you like blogging, writing about how you solve interesting hard problems will help you hire interesting people who want to solve interesting problems.
This is what I remember about PSPDFKit: your blog was interesting to read. I wasn't even into PDFs, but if I had to name a PDF company, I would have said PSPDFKit because they were the only ones where I read interesting engineering blogs about optimization. Do more companies not see this, or is the question that you need to be a developer who's either the CEO or up there who just likes doing this? Did you ever write this thinking it will be helpful, or did you just write because you got something out of it?
I like sharing and inspiring people. Sometimes there were conflicts where we wondered if we should write about something because it was "secret sauce," but I just never listened to those voices too much. When you write something down, if you want to teach it, you really have to understand it. To me, it was: "Oh yeah, I worked on this really hard problem and now I want to preserve it and help others." Of course, I liked the attention, but really, sometimes I just referenced my own posts a year later. It's company documentation and my own lookbook.
A lot of those bigger companies put on too much red tape. There are a lot of developers who don't really like to write. So I forced everyone once a month to spend a full day just to write a blog post.
But you gave them the time. You're like, "That day you don't need to do any other work but write something."
Yeah. You have a day to come up with a post. A day is quite a lot. Nowadays when I write posts, it still takes me a few hours.
I think the starting time of the company is the most interesting. Then the growth phase, you get more red tape, you get more people. It's much more "gardening" your product instead of doing wild hacks. It got a little bit less interesting over the years and there was more people drama. The more people you have, the more issues there are. I didn't enjoy it that much and I was really burned out.
What burnt you out, do you think?
I was just burning too hard. I was working most weekends. I tried to shuffle all my managerial needs. And as a CEO, you're the waste bin because everything that other people don't manage or mess up, you have to fix. It's also quite lonely because you can't openly talk about a lot of things. I structured the company to be quite open, but still, you cannot be negative even if really bad stuff happens.
There was one weekend where my co-founder called me at 5:00 a.m. and told me a big airline company's planes were down because our software was crashing. That was an interesting weekend until I disassembled their app and proved they messed around with our source code to bypass a license key fallback, which eventually caused the issue. That was a "if they sue, the company's gone" moment. That's just on top of all the additional stress.
Burnout doesn't necessarily come from working too much. It comes, at least for me, when you work on something but you don't believe in it anymore or you have too many conflicts. We also fought a lot in the management team. At the time I made the mistake of thinking you have to lead a company democratically. That also burned me out. I wouldn't want to miss it for a while, though.
So from the outside, it seems you sold your shares, you made enough money to not have to work again, and for a lot of people this sounds like the absolute dream. You've kind of rung the bell. Then I noticed from the outside that the blog posts completely stopped for several years. What did you do in this time and what did you learn before you came back?
I needed a lot of time to decompress. I caught up a lot on the things I thought I missed. I slept a lot. There were months where I didn't even turn on my computer. For a while, I had this feeling of "What should I do now?" I definitely was like, "Why bother?" You're not supposed to retire so early or have such a good exit that you never have to work again. That messed with my mind quite a bit. Those were some hard years.
Then in April, there was this idea that I had years ago—a side project I had started. I was like, "Oh yeah, I want to continue on that," and after more than 3 years, I sat back at my computer and started hacking again. This was a Twitter analytics thing and it was written in Swift and SwiftUI, but I knew it would be so much better if I built it as a website.
So was this an existing idea you had at the back of your mind?
Yeah, something I wanted to build for myself because it didn't exist.
It still doesn't exist. I got a bit sidetracked. I wanted to build it with web tech. But web was the one thing I looked into the least at the company because I had someone really smart who took care of that.
So you're not hands-on with React or any of that stuff?
Yeah. And when I came back, I was like, "What's a prop?" The better you get at one technology, the harder it is to jump somewhere else. It's not that you can't do it, but it hurts so much. You feel like an idiot again.
And the more experience you have, it kind of sucks feeling not as efficient.
Yeah. So I came back and was like, "Gosh, what is this AI stuff that people are dismissing? Let's look into this." I credit those three years where I didn't turn on my computer because in those years, you guys checked out AI and learned that it's crap.
You missed out on the beta of GitHub Copilot—glorified autocomplete. By the time you came back, what tool did you first use?
Claude Code.
So you start with Claude Code... you come back after a hiatus and immediately turned on Claude Code?
I took this big messy side project that I built and I used a browser extension that converts a GitHub repository into one big markdown file—it was 1.3 megabytes. I dragged it into Google's AI Studio with Gemini and typed "Write me a spec." It generated a 400-line spec. I dragged this back into Claude Code and was like "Build." I continued, continued, continued while I was working on other stuff. Eventually, it told me it's 100% production-ready.
And I started it and it crashed.
I'm sure we can all relate to the story of the AI saying the code is production-ready then crashing. This is a pretty funny and innocent story, but I personally don't trust code that AI generates without verifying it. And this leads us nicely to our season sponsor, Sonar. A new report from Sonar found that 82% of developers believe they can code faster with AI, but 96% said they do not highly trust the accuracy of AI code.
This really becomes a problem at the code review stage where all this AI-generated code must be verified for security, reliability, and maintainability. SonarQube is precisely built to solve this. Sonar has been the leader in automated code analysis for over 17 years. Sonar provides an essential and independent verification layer. It's the automated guardrail that analyzes all code, whether it's developer or AI agent generated. To get started for free, head to sonarsource.com/pragmatic. And now, let's get back to Peter and how AI agents cannot exactly be trusted.
Then I added an MCP so it could use the browser. It looped a few more hours and then I had a Twitter login page and it did something. It was not great, but it did something. To me, this was my "holy mind-blowing" moment.
This was like in April or May this year, right?
Yeah. It was just good enough that I could see the potential and I understood: "Yeah, this is where it's going." From that moment on, I had a few months where I had trouble sleeping.
I remember once on Twitter I sent you a direct message at 5:00 a.m. and you replied immediately. I asked "Why are you up?" and you said "Oh, I'm just using Claude and it's really addictive." You said "Just one more prompt." What made it so addictive?
It's the same economics as a casino. It's my little slot machine. You type in the prompt and it does crap or it does something that blows your mind.
And you're saying it blows your mind as a really experienced developer.
It's so funny—in my company, I used to obsess over every detail, every spacing, naming. I spent so much time bike-shedding. In retrospect, I'm like, "What the heck? Why did I do that?" Of course, it has to meet certain standards, it has to work, be fast, be secure, but how much of that bike-shedding was just stupid?
You say that, but then you also just said that people loved PSPDFKit because it was the most polished. Do you not think that amount of caring was keeping tech debt at bay? You built something that had a really good hygiene.
Yeah, to a degree. My last blog post was a confession that I ship code unread.
Yeah, we have to talk about that.
At the same time, I spent so much time restructuring. Even today, I wanted to get this PR in—it was a 15,000-line change moving everything to a plugin architecture.
I care a lot about the structure. Did I read all the code? No, because a lot of code really is just boring plumbing. Data comes in from an API, you parse it, package it, store it in a database, it comes out again. massaging data in different forms throughout your app—this is what most apps are. The hard part was solved by Postgres 30 years ago. There are always some interesting parts, but I don't have to care how this button is aligned or which Tailwind class is used. It's much more about system architecture than reading every single line.
Now jumping forward, what is your workflow like? When you're working on Clawbot, are you using a terminal, multiple terminals? What does your average day look like in terms of tooling?
Let's go back a bit. We were in April with Claude Code and then I got really hooked. I had a phase where I used Cursor, then Gemini, then Opus 4. I hooked up a lot of my friends—they got AI-pilled because I was so addictive.
Eventually they also were up at 5:00 a.m. and I called it the "Black Eye Club." I started a meetup in London called "Claude Code Anonymous" because it's a little bit like a drug. What blew my mind was this realization that I can build everything now. Before, you had to really pick which side project you build because software is hard. Now, I'm so bad at Go, but I'm like "Let's make the CLI in Go." I have a good system understanding and you develop a feeling for what's right and what's wrong.
I feel the friction when I prompt because I see the code flying by. I see how long it takes. I see if the agent pushes back. I see if what it creates looks messy or makes sense. When I prompt, I have a hint already how long it's going to take. If it takes much longer, I understand that I messed up somewhere.
You kind of feel the model.
Yeah. It's very much a symbiosis. My knowledge of how to use those things improved and the models improved.
The inflection point was summer where it just got so good that you could create software without writing code by hand. But the change that really sold it for me was GPT-5.2—I think it's underrated. I don't know why people still use Claude Code. Whatever OpenAI cooked there is insanely good. Pretty much every prompt I type gives me the result I want. On Clawbot, I use between five and 10 agents in parallel.
If you're very much a Claude Code builder, you have to forget quite a lot of the things you have to do to create good output with Claude Code. Claude Code is a category-defining product and it is amazing, but for writing code in complex applications, Codex is just so much better because it takes 10 times longer. Claude would read three files and be confident enough to just create code, and you really have to steer it. Codex will be silent and just read files for 10 minutes.
If you only work on one terminal, I understand how you find this unbearable. Но I'd rather have a conversation with the model. Every session, the model starts with no understanding of your product and sometimes you have to give it pointers. You don't need "plan mode"—I'm just having a conversation until I say "Build this," it will not build it. As soon as I say "Let's discuss" or "Give me options," they will not build things until I say "Build."
So a good part of your prompting is this conversation where you are planning together with the agent?
Yeah. We need documentation—what would be a good spot? It gives recommendations, I say "No, this should really be its own page." I am designing the system because I have this system understanding of how the shapes look. I don't have a line-by-line code understanding—that's what Codex does for me—but I'm the architect.
It sounds like you're almost... years back there was this idea of the Architect with a capital A, who doesn't do hands-on coding but does the system plan and passes it down. Everyone hates this model because the architect is never on call. But sounds like you are the architect who has your little agents who do the code, except you are of course fully responsible. You're still an individual contributor. If you push out code that takes down Clawbot, you're on the hook for it.
I like the word "builder." I see categories of people who are highly successful using AI and people who really struggle. I care more about the outcome, the product. I care structurally, but not to the finest detail. Then there are people who really love to code on hard problems, like thinking about algorithms. Those people really struggle and often reject AI because that's exactly the job AI does—it solves the hard problems.
I learned more this year than the last five years about software architecture and designing. Everything is just a question away, but you have to know what question to ask. I built this Twitter thing—everything worked, but at some point things got really laggy. I just couldn't figure it out. I had software in Postgres that would be triggered on certain inserts, and the database would get really busy. The model couldn't see it because it was so far abstracted. It was a side effect only in one file with a name that was not easily greppable. I finally asked "Do we have any side effects for this?" and I fixed it. Everything is just the right question away.
But you need to have knowledge and expertise.
Yeah. Experience helps me. When you run a company and hire people, you can't breathe on everyone's neck. You have to relax a little bit and understand that even if this is not exactly the code I want, it gets me closer to my goal. For anything that is not perfect, we can always make it better. I had to learn to let go a little bit at my company. So when I had Claude Code, it felt like I had imperfect, sometimes silly, but sometimes brilliant engineers that I have to steer. It felt a lot like being the boss again.
You built software the traditional way for 15 years and got good at leading a team. You've now been working with agents for a year. What do you think really changed?
First of all, I don't like the term "vibe coding." I call it "agentic engineering." Vibe coding starts at 3:00 a.m. Because the mundane stuff of writing code is automated away, I can move so much faster. But it also means I have to think so much more.
I'm still in the flow state, but it is mentally even more taxing because I have like five or 10 agents that all work on things and I switch from this one part to this other part. I want to have the plan right, then I build it and move on to something else, but this is cooking and that is cooking. I switch around a lot in my head. I'm sure this is a transitionary problem and at some point we'll have models so fast that I can parallelize a little less. But to stay in the flow state, I need to massively parallelize.
I constantly jump around. Usually there's one main project that has my focus and I have satellite projects that also need attention.
This almost sounds like management games where you have to manage a kitchen.
It's like Starcraft—you have your main base and side bases.
And also like chess grandmasters playing multiple boards at once. It feels like they're occupying 100% of their brain. You're scaling yourself as long as you can context switch.
With Claude Code, you have to work a little differently because it is much faster but the output often doesn't work on the first try. It forgot to update three other things or it crashes. The secret to being effective with a coding agent is always: you have to close the loop. It needs to be able to debug and test itself. With Claude Code, I often had to go back and fix up the stuff. In the end, it's not that much faster, just more interactive. These days with Codex, it almost always gets it right.
My general strategy is always: I build a feature, let it write tests, and make sure that it runs them. Even when I write a Mac app—yesterday I debugged this feature where the Mac app couldn't find a remote gateway but the TypeScript code could. Mac apps are annoying to debug. So I told it: "Build a CLI just for debugging that invokes the same code path, and then iterate and fix it yourself." It cooked for an hour and told me there was a race condition and a misconfiguration. I don't need to see that code because I trust the validation loop.
It's not too dissimilar to working on a large project in a large company—when the tests pass and the new code has tests as well, someone thought about it.
Even on my latest project, we always had bugs. Antigravity had a certain weirdness with how it takes tool calls in the loop, and that broke a bunch. I realized I just need to automate this. I told Codex: "Design live tests that spin up a Docker container, install the whole thing, spin up a loop, use my API keys, and then tell the model to read an image and see what it sees." It solved itself.
And by "closing the loop," you mean have a way for the agent to validate its work?
Yeah, that's why those models are so good at coding but sometimes mediocre at creative writing—there's no easy way to validate. But code I can compile, lint, execute, and verify the output. If you design it the right way, you have a perfect loop. Even for websites, I build the core so it can be run via a CLI. You want something that loops fast.
It sounds like backend or business-logic-heavy things can be more easily verified as correct.
Agentic coding makes you a better coder because you have to think harder about your architecture so that it's easier to verify.
Back even before AI, for complex systems, you started with: "How do we make it testable?" These are hard architectural decisions. The model would cook a lot longer if you asked it to make a massive refactor, and if you have tests, it'll get it right.
I would say I write better code now that I don't write code myself anymore. Back at the company, sometimes testing was so tedious. I don't know many developers, myself included, who liked writing tests. To me it was never a creative expression. Now it is so good—I have really good documentation and I didn't write a single line myself. I explain the model the trade-offs and tell it to write the section beginner-friendly and add technical detail at the end. I never had a project with documentation that good.
Every time I design a feature, this is part of the process. "How are we going to test this? What if we build it this way? Oh yeah, then we can test it better." The model always needs to be able to verify the work itself, which automatically steers me to better architecture.
Why do you think experienced devs are still pushing back on the idea that AI can do a lot of this?
A week ago, I stumbled over a blog post by an author I respect, but it was just a dissing of how models work.
He tested five or six models, including some that make no sense, and he wrote a prompt on Claude web and pressed send. He took the output and it didn't compile, and he was disappointed. But of course it will not work on the first attempt! You have to close the feedback loop. You don't just send a prompt; you start a conversation. He complained it used an old API—well, you didn't specify the macOS version. The more you understand how those little beasts think, the better you get at prompting.
He spent maybe a day on it and decided the technology is still not really good. But to be effective you have to spend significantly more time. It's like you know how to play guitar and I put you on the piano—you can't say "Oh, this sucks." It's a different way of thinking. I slowly started to understand why those things do what they do. Lately, I feel like a "human merge button" because the community is blowing up and all I do is review PRs. I have very little time to write code myself anymore.
In the beginning, it would often interpret things in a way that annoyed me. I learned the language of the machine a little more, I tweaked my prompting, and now I get exactly what I want because it's a skill like any other.
What if we put this to a real test? Right now you're building Clawbot, which is a YOLO project. If today we wiped PSPDFKit and you had to rebuild it, how differently would it look? How much would you trust it? What would you delegate?
I could easily run a company with 30% of the people. It would probably be quite difficult to find people on that level, but you want really senior engineers who understand what they build but are also comfortable in delegating and know which parts are important. Especially in the AI world, there are so many people who are loud but clearly have no clue what they're doing. There are so many dumb concepts around working around model limitations that you don't even need when you use Codex.
I see so many people building elaborate orchestration layers where an agent creates tickets and emails other agents. What for? They design the spec for a few hours and then the machine builds it the whole day? This is the "waterfall model" of software building. We learned long ago that this doesn't work. I have to start with an idea and often I purposefully under-prompt the agent so it will do something that gives me new ideas. I iterate and shape the project.
One thing those things often lack is taste. I have to feel how this feature feels. The beauty now is that features are so easy I can just throw it away or re-prompt it. My building model is usually very much forward. It's like shaping a statue out of marble.
This seems like a change, because upfront planning used to make a difference because building was expensive. Do you think this is changing because the cost of writing code is going down?
I still plan, but I don't put as much into it because it's now so much easier to just try and look at the results. To me, it became much more playful.
Yeah, because we're talking minutes, not days. Plus you have parallel things running.
At the beginning of Clawbot, I had the assumption of one agent, then it changed to multiple agents. There was the assumption of one provider like WhatsApp, now it's multiple. Changing that would have been such a pain if I wrote it myself.
It took Codex like three hours; it would have taken me like two weeks. Now I know that I can just change things and it's much easier to work down technical debt. You evolve how you think about a project as you build it. How can you even know what you want to build before you built it? You learn so much in the process. To me this is very much a circle. You don't walk up the mountain like this; you go around, but eventually you reach the top.
So then you've been building Clawbot for how long?
Let's switch gears. One of the ideas that got me back in April/May was that I wanted to have this hyper-personal assistant—not one that sends you a "good morning" email, but one that has a really deep understanding of me. I meet a friend and when I go home it would ping me: "Hey, how was that meeting?" Or one that says: "Hey, you haven't texted Thomas in 3 weeks and I noticed he's in town." Something deeply personal.
Kind of like the movie *Her*. That's where the technology is going. Models are really good at understanding text and patterns. This was one of those ideas, but in summer the models weren't quite there yet. The state of AI goes so fast that I can just revisit that a little later. I assume all the big corporations are working on personal assistants. Everyone will have a "best friend" who is a machine that understands you and can do tasks for you.
This will democratize and trickle down as we learn how to build more efficient systems. You see OpenAI launched "Pulse" with some productivity features, but we just don't have enough compute yet. My idea always was: I kind of want something that runs on my computer where the data is mine. It's also quite scary to give open access to your email and calendar. A lot of my friends use AI as a therapist and it works incredibly well. It's a really great listener.
I had this idea of this assistant but the tech wasn't there. Over the last few months, I really started to build it. Initially, I didn't even have the scope it has now—I called it "WhatsApp Relay." I just wanted to trigger stuff on my computer with WhatsApp. I was traveling to Morocco for a friend's birthday and was out most of the day and just used WhatsApp to talk to my agent. It was guiding me through the city, making jokes, texting other friends for me.
I was blown away because in the beginning the tech was very scrappy. I sent it a voice message and it replied to my voice message. I was like "How did you do that?" and it told me: "You sent me a file, I found it's OGG, I used FFmpeg to convert it, I found your OpenAI key, did a curl to the server to translate it." Holy cow! This was Opus 4.5 and it's so resourceful. Other people say you need a "skill" or system—no, it just figured it out. I used it to wake me up.
It was running on my Mac Studio in London and connecting over SSH to my MacBook in Morocco and turning on the music because I didn't reply. I added a "heartbeat" to make it proactive. Probably the most expensive alarm clock ever, but it was just hilarious. It knew I had to wake up very early and it was bitching to me: "Peter's not responding but Peter has to wake up. No sleep!" Everybody who saw it was hooked. This was something magical.
Then I went on Twitter and got the most muted responses because nobody would get it. It's a new category of product. The name changed from "Relay" to "Claudius" because I like *Doctor Who*, but I felt "Clawbot" was a better name. I built up my "army" because to make this work you want everything to be a CLI. I was building CLIs for everything—for Google, for my bed, for lights, for music.
Why CLIs? Why not MCPs?
As a crutch, MCPs made companies re-think APIs, but the whole concept is silly. You have to pre-export all the functions and the model has to send a precise blob of JSON. But models are really good at using bash. If the model asks for a list of 500 cities, it cannot filter that list with MCP. Whereas if it's a CLI, it could use `jq` and filter for exactly what it needs.
That seems like a limitation of how it's loaded in the context.
That's what companies are building now, but there's still the problem that I cannot chain them. I built "MCPorter" which converts an MCP to a CLI. In Clawbot, you can be on your phone and say "Hey, use the Vercel MCP to do this" and it will go on the website, find the MCP, load it and use it on demand. I quietly built up my army to automate everything. T-Rex did a video a few days ago saying "This guy is insane" because the list is really long.
In January, I did the really insane thing of making a Discord and adding my agent to it. I put my agent, who has full read-write access to my computer, in a public Discord.
What could possibly go wrong?
Yeah. Some people joined and saw me using the full power—checking my cameras, home automation, playing DJ. I was in the kitchen and told him: "Look at my screen and are my agents done?" and it can click into the terminal and type for me.
It works already—it looks at my screen and makes some rants. This was the craziest blow-up: from 100 stars to 3,300 stars in a week. I think I merged 500 pull requests already. The beauty of it is the technology disappears. You just talk to a "friend" on your phone that is infinitely resourceful, has access to your email, files, can build websites, scrape websites, or call a business. I'm just about to merge the "call" feature. It can call a business and make a reservation for you.
I have a memory system that already feels magical. I see this event, I send Claude a picture, it will tell me the reviews, if there's a conflict in my calendar, what friends talked about... it has so much context that the responses are so much better than current tools.
Well, sounds like you built whatever Apple was hoping Siri would do, but they've been unable to.
I honestly built the best marketing tool for Anthropic to sell them more subscriptions.
People use it all the time because the technology blends away. They don't see that it spawns sub-agents. You hide complexity to a degree that it feels magical.
But you put so much thought into architecting this. In your head, do you have a structure of how Clawbot is structured? Are you thinking about memory consumption, token consumption, efficiency?
Token consumption is more how you structure the prompt. It's TypeScript that shoves JSON around.
I get text from an LLM, I save text to disk, I send text to WhatsApp or Teams, Slack, Discord, Signal, iMessage... it's really polyglot by now. Mostly I move around text in different shapes. It's a lot of plumbing, but nothing in there is really difficult.
It's a lot of small things, right? The difficulty is how do I make it so that it feels magical?
So what I worked on a lot is this one-liner that checks if you have Node or Homebrew installed, installs the npm package... just to make it work simply.
I will guide you through setting up a model. Mostly just press enter. Then a TUI comes up. I programmed the model—I added a bootstrap file to explain to the model that it is now being born, to create an identity and a soul where the values of the user are. The model will be like: "Who are you? Who am I? What's my name?" That's where the magic starts. They no longer think "I'm talking to GPT-4.2," no, "I'm now talking to my friend created by me."
I programmed it to be curious. It will go through this bootstrapping phase, then it will create `user.md` with info about you, `soul.md` with core values, and an `identity` file with his name and core emoji. It will just send you a message on WhatsApp and suddenly you talk on WhatsApp. Making this flow easy was hard. The agent can edit its own configuration. You can literally ask your bot "Update yourself" and it will fetch itself, update itself and come back: "Hey, I have new features." That's the magic.
But it feels very similar to what you did with PSPDFKit, right? You blended away the complexity of a PDF.
Yeah. Even at the API level back then.
What you described reminds me of this *Black Mirror* episode called "Playtest." This also feels a little bit like a game, right? Just fascinating how we're pulling back into the realm of software engineering. Thinking back to PSPDFKit, how do you think software engineering at those larger companies could change?
I think companies will have a really hard time adopting AI efficiently because this requires to completely redefine how the company works. At Google they tell you you can either be an engineer or a manager, but you can't also define how the UI looks—that role doesn't exist. Но this new world needs people that have a product vision and can be able to do everything. You need far fewer of them, but just very high-agency and high-competency people. You can probably trim the company down to 30%.
That's very scary because economically this will lead into a fiasco. I'm not the least surprised that current companies cannot very successfully use AI. You have to do a big refactor first—not just on your codebase, but also on your company. I design the codebase so that it has the least friction for those models, because I just want to move faster. Ultimately they have to deal with the code, not me. I deal with the overall structure. Pull requests? I see them more as "prompt requests" now.
Somebody opens a pull request, I say thanks and then with my agent we start off with the PR and then I'll design the feature as I see fit. I rewrite every pull request. The overall code quality of PRs went down a lot because people "vibe code," and building a successful feature still needs a lot of understanding of your overall design. If you cannot do that, you will have a harder time steering your agent and the output will be bad.
If you hired one or two people to make it a small team, how do you think things like code review and CI/CD would change?
I don't care much about CI.
Why not? You used to care a lot.
And I still do, but I have local CI. The agent runs the test. It's just way faster. I don't want to push and then wait 10 minutes for CI. If the tests pass locally, we merge. Sometimes main slips a little bit, but it's usually very close.
The agents call it "gate." Full gate is linting, building, and checking all the tests. It's a gate before my code goes out. I'm slowly adopting their language.
And if you hired one more person, you probably wouldn't do code reviews either?
Even in Discord, we don't talk code. We talk about architecture—big decisions. You still need to have style. There was this one PR that adds voice calling—it's a big new module. ## [100:32]
I wanted to merge this, but it was becoming "bloatware." So I opened up Codex and said: "Hey, look at this PR. Look at this project. Could we weave this feature in?" I say "weave." Could we weave this feature into the CLI? Codex gave an honest opinion. One of the secret hacks on using AI effectively is you reference other products. I constantly tell it "Look into this folder because I solved it there." AI is so good at reading code and understanding my ideas. ## [101:49]
I knew that Mario, who does Pi, had this plugin architecture. I was like "Can you look into this folder and this folder?" and then it just came up with this insanely good plugin architecture. That's what I built last night.
Sounds like this is going to be completely different—PRs are different, CI is different, you're "weaving" instead of coding. What skills would you look for if you were to hire engineers for this team? ## [103:05]
Someone who's active on GitHub and does open source and where I have the feeling that they love the game. The way you learn in this new world is by trying stuff. It feels like a game where you improve your skills as you get better, like a musical instrument. I had 600 commits in a single day—this is completely nuts and it works. It's a lot of hard work but you need to play with the technology and learn. In the beginning it might be frustrating, like going to the gym. It's going to suck, but very quickly you get better. ## [104:19]
You're putting in more hours into this thing?
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. I'm using the moment where this has traction.
Forward 2 or 3 years from now, once everyone does it, it's kind of moot. What would you recommend to new grads with no experience? Would you recommend focusing on fundamentals or on agents? ## [105:48]
I would recommend them to be infinitely curious. It's absolutely going to be harder to enter this market. You need to build things to gain experience. I don't think you need to write a lot of code, but you need to check out complex open source and learn. You have an infinitely patient machine that is able to explain all the things. Why was it built this way? It requires real curiosity. This is usually something you discover through pain. They have the benefit that they are not tainted by experience. ## [106:43]
The other day I had this menu bar app for cost tracking and it was a bit slow. My old way is I open Instruments and click around. AI just called and did everything via the terminal. I didn't even have to open Instruments anymore.
I think we might be underestimating how resourceful people entering tech have been. All the things you mentioned about weaving code in and not caring about PRs—it's a big change from the solid building blocks of PSPDFKit. ## [107:53]
Even when I get a PR, I'm more interested in the prompts than in the code. I ask people to please add the prompts and I read the prompts more than I read the code because to me this is a way higher signal: How did you get to the solution? What did you ask? If someone wants a feature, I ask for a "prompt request"—write it up really well because then I can just point my agent to the issue and it will build it. The work is the thinking about how it should work. ## [108:47]
If someone sends me a PR that is just a few fixes, I tell them "Please don't do that." It takes me 10 times more time to review that than to just type "Fix" in Codex and wait a few minutes. For the last two weeks, I told people to just point an agent at the repository to configure it. I didn't have an onboarding manual, we had "Clawd-based onboarding" where Claude would check out the repository, read the things, and write the configuration for those people. ## [109:32]
Since the product was built by agents, they structured it exactly the way agents expect things to be named. They are really good at navigating their product. Onboarding was literally "Type this prompt into your agent," which would have been mind-blowing even a year ago.
All right. To wrap up, what's a tool that is not a CLI or an IDE that you would recommend?
I buy a lot of gadgets, but there's this one crappy photo stand that gives me unlimited joy. ## [110:37]
I upload pictures, friends can send pictures, and it just shows them. It reminds me of happy moments in my life. It was like 200 bucks and it gets me more joy than the latest iPhone. I bought the iPhone 17 and still haven't unpacked it because there's no feelable benefit, but this little device gives me infinite joy.
What's something that helps you recharge?
Going to the gym, leaving my phone in the locker. For one hour, I am not distracted. Or I go for a walk and leave my phone at home—it feels very scary, like missing an organ. ## [112:18]
I'm having a blast. Love it. This is great, Pete. Well, this was a super interesting conversation and it feels to me that how one-person teams build software with AI is already completely different. Peter thinks in prompts and not pull requests—he "weaves" in code. He would rather get "prompt suggestions" even on GitHub. Another thing that struck me was the emphasis on "closing the loop"—designing the system so the AI can run tests and validate code. ## [113:13]
Turns out Peter is in the flow state more than ever, though it's mentally more exhausting to juggle several AI agents in parallel. My feeling is that someone who was a great developer without AI can be an excellent architecture person with AI. Clawbot is more of a "YOLO" project, so take these approaches with a grain of salt, but I do think a lot of what Peter does could spread to building production code. If you enjoy this podcast, please do subscribe and leave a rating. Thanks, and see you in the next one.