The creator of Clawd: "I ship code I don't read"

22:40Oh, that's right, because we're going to look at your company and then just take the dice and think about a number that you're probably willing to pay. And that sounds horrible, but also when you have a product where you can't really tear it down to a specific number, Like it makes a difference if a freelancer contacts us or one of the big Fortune 500s. Let's not say names. Yeah. Because the usage will be different. The value they get out of it will be different. And charging the same, you would either exclude one or the other. If I go too low, they're going to see this fishy. It's like procurement for like 500 bucks.

23:19We're not going to even start the process. And if we target it too high, we're going to lose those people. So as horrible and unfair this process seems, for some kinds of products, it's the most fair way after all. You know, on software, there is, I would say there's like four axes. There's like easy and hard and 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,

23:46The Pragmatic Engineer Host:it's going to be a hard sell. It's a hard sell anyhow. Selling anything to developers is a hard sell. 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. I, what's so hard about it? I mean, there was this one example where, you know, like PDFs have links.

24:25So like, there's like a table of contents and you click on it and it goes to like page 37. So I built this whole model with the assumption, oh yeah, maybe there's like a hundred or a few hundred links in there. And then we got this one custom and we like paid really good money. And then it's like, oh, it takes four minutes to load the PDF. What the heck guys? And I looked at it and it was like a 50 ,000 page text Bible from Canada. And it had like... 50 ,000 pages. It had like more than 100 links per page. 500 ,000 links. My data model completely exploded because my assumptions were off by a number of, what, 1 ,000?

24:56But by then you have like a mature product with an API. So like, how do you completely redesign the internal part without breaking things for everyone? Like suddenly everything has to be lazy, but before parsing 101 was easy. but now they were like this was like so difficult to keep it working for people um i think i spent like two months just on that completely redesigning like the internals and like making sure it's still easy for people they don't have to know what we what we load easy what we load lazy or if you copy the thing it still has to like have to keep some connection it needs to keep the references

25:37The Pragmatic Engineer Host:and some of those things. So I love to do support. And I think that was also a confining factor why the company worked. Because if you send a ticket and then the CEO replies and helps you out, that has impact. And my strategy was always like, I always used to list in reverse. Because if you send a ticket and you get a reply within five minutes, that's magical. If you wait one or two days, not much difference. So yeah, this was one of the problems where I worked two months and I finally got it down to almost like this. That must have been satisfying. And it was very satisfying. And you were writing a lot of the code or you were involved in a bunch of the code.

26:22The Pragmatic Engineer Host:Obviously, a big team was now here but you were still kind of overseeing it, right? You were in the details. I mean, of course, I had a really great team and 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. and the marketing side, the business side. I had like Jonathan's help. I had marketing's help. I found good people. The thing is, if you like the blogging and writing about how you solve interesting hard problems will help you hire interesting people that want to solve interesting problems. This is what I remember at PSPDFKit, that your blog was every now and then, it made it to hack and use as well, but it was just interesting to read.

27:03The Pragmatic Engineer Host:And I couldn't name, again, And I'm not one into PDFs, but if I had to say something, a PDF, I would have said PS PDF, because they're the only ones where I read interesting entering blogs about how you optimize or ship. It's still there, by the way. I myself also sometimes ask myself, like, interesting, 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? And by the way, did you ever write this thinking this will be helpful? or you just wrote because you got something out of it, like putting out that you solved this hard problem.

27:39I like sharing and like inspiring people. There was sometimes even conflicts where we were like, should we write about this? Because it's like a little bit of secret sauce. But I just never listened to those voices too much. I just, you know, there's also like when you write something down, it's this principle of like, you understand it, but then if you want to teach it, you really have to understand it. So to me, it was also a little bit like, oh yeah, I worked on this really hard problem and now I want to like preserve it and like help others. So I got a gig of it. Of course, I liked the attention.

28:19But really, it was this. Sometimes I just referenced a year later to my own posts. I get this. This is a this is both company documentation. This is like my own logbook. It's helpful in so many ways. And a lot of the speaker companies, oh, they put on too much red tape. There's a lot of developers who don't really like to write. So I forced everyone once a month, a full day just to write a blog post.

28:48The Pragmatic Engineer Host: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. days is quite much actually i mean when i'm nowadays when i write posts it still takes me a few hours i don't want to dwell too much on like the i think the the the starting time of the company is the most interesting the the the growth phase you get more tape you get more people it's much more gardening your product instead of like doing doing white hacks and more iterative. So it got a little bit less interesting over the years and there was like more people drama because the more people you have, the more issues there are.

29:35And I didn't enjoy it that much and I was really, really burned out. What burned you out, do you think? I was just burning too hard. I was working most weekends. I tried to shuffle all my material needs. And you know, as a CEO, you're basically the waste bin because everything that other people don't manage or can do or mess up, you have to fix. And it's also quite lonely because you can't openly talk about a lot of things. I mean, I structured the company to be quite open, but still, like, you cannot be negative. You have to, even if, like, really bad stuff happens. I know that was, like, there was like one weekend where my my co-founder called me at at 5 a.m and told me like yeah there's this big airplane company and their planes are down because our software is crashing that was a very interesting weekend until i could like i disassembled their their app and did prove that they messed around with our source code to triggering a triggering a license key fallback that eventually like cost you shit ahead but that was like a if the sewers company's gone and more moment um and that's just on top to all the additional stress and there were quite a few of those things you can do that for a while and i also believe like burnout doesn't necessarily come from working too much it it comes more from or at least for me when you when you work on something but you don't believe in it anymore or you have like too many conflicts and we also had a we did fight a lot in the team with like management team and by the time I made this mistake and I thought you have to like lead a company more democratically so that was also something that burned me out I wouldn't want to miss it for the world though

31:28The Pragmatic Engineer Host:So you know from the outside it seems you sold your shares, you made enough money to not have to work again, should you not choose. And for a lot of people, like, you know, people who are starting out their business or one day want to start a business, this sounds like the absolute dream. Like this is, I guess, what we know realistically that most people will not make it. But if you make it, I mean, you've kind of like, I guess, you know, checkbox done. You're kind of, it's a little bit, if you're like climbing on a wall and you ring the bell, you're done. And then what I noticed is from the outside, again, on your blog, the blog has completely stopped for several years.

32:01The Pragmatic Engineer Host:What did you do in this time? And what did you learn in this time, before you came back to where we are now? I needed a lot of time to decompress. I catched up a lot on things I thought I missed. I partied a lot. There were months where I didn't even turn on my computer. And for a while, I just didn't have this feeling of like, what should I do now? Like, I definitely was like, Why border? You know, you're not supposed to retire so early or like have so much, have such a good exit that you never have to work again. That messes my mind quite a bit. That was some hard years. And then in April, I was like, there was this idea that I had years ago and even a side project that I started.

32:55I was like, yeah, I want to continue on that. And then after more than three years, I just sat back to my computer and started hacking again. But the thing was, this was like a Twitter analytics thing and it was written in Swift and SwiftUI. Back then, I already knew this would be so much better if I would build this website.

33:20The Pragmatic Engineer Host:So was this an existing idea that you kind of had at the back of your mind, something Twitter analytic? Yeah, it was just like something I wanted to build for myself because it didn't exist. And then even three years later, it didn't exist. It still doesn't exist. It kind of does, but I got a bit sidetracked. So I went back and I wanted to build it with WebTech. But Web was always, even at my company, the one thing that I looked into the least because I had someone really smart who took care of that side in the company that I brought in, Martin. so I never had to worry about it. That was one of the...

33:57The Pragmatic Engineer Host:You're not hands-on with React or any of that stuff. And when I came back, I was like, what's a prop? You know, that level where you really... And you know, this is like, this is a trap I see with many developers. 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're like, I can program in Apple's tech, I can program blind, But then in that stack, I have to Google the most mundane stuff. And it just hurts. You feel like an idiot again. Yeah. And I guess the more experience you have, it kind of sucks feeling. I mean, I'm sure you say embrace and all that, but it's not great.

34:39The Pragmatic Engineer Host:You're not as efficient. You know that you could be faster, etc. Yeah. So I came back and I was like, gosh, there has to be, there has to be. What is this AI? What is this AI stuff that people are dismissing? Let's look into this. And in April, a lot of us were dispensing it, probably rightfully so. And to a degree, I credit those three years where I basically didn't turn on my computer. Because in those years, you guys checked out AI and learned that it's crap. Yeah, the people who, as I was about to say, so you missed out on, you didn't do the beta of GitHub Copilot, you know glorified autocomplete which is gpc3 or maybe not even there was then of course 3.5 which is a big jump and it got increasingly better than gpt4 and so by the time you came back what tool did you first use when you because you missed out on like two years of like like devs us devs using dismissing finding some niche use cases for it or cloud code so you started with cloud code that i think it just came out it came out of may but there was a beta beforehand yeah as i think They had something, didn't they have something in February already?

35:51The Pragmatic Engineer Host:They had a beta from February, correct. Yeah, so... So ClockCode was your first, you come back after like a, you know, hiatus and you immediately turned on ClockCode and you missed everything else before. And, you know, it was like, I remember I took this big, messy side project that I built and I have this browser extension that converts a GitHub repository into one big markdown. there was like a 1.3 megabyte markdown file and i dragged it into into google ci studio with germina 2.5 or two to something and i typed write me a spec and it generated those 400 lines of spec and i dragged the spec into cloud code and i was like build and then i continue continue continue continue and while i was like working on other stuff you know um and eventually told me like, it's 100 % production ready.

36:47And I started it and it crashed.

36:49The Pragmatic Engineer Host:I'm sure we can all relate to the story of the AI saying the code is production ready and 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 seasoned sponsor, Sonar. So let's look at some data. A new report from Sonar, the State of Code Developer Survey report, found that 82 % of developers believe they can code faster with AI. But here's what's interesting. In the same survey, 96 % of developers said they do not highly trust the accuracy of AI code. This checks out for me as well. While I write the code faster with AI agents, I don't exactly trust the code it produces.

37:26The Pragmatic Engineer Host:This really becomes a problem at the code review stage where all this AI generated code must be regularsely verified for security, reliability, and maintainability. SonarQ is precisely built to solve this code verification issue. Sonar has been the leader in the automated code analysis business for over 17 years, analyzing 750 billion lines of code daily. That's over 8 million lines of code per second. I actually first came across Sonar 13 years ago in 2013 when I was working at Microsoft Skype, and a bunch of teams already use SonarCube to improve the quality of their code. I've been a fan since.

37:58The Pragmatic Engineer Host: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, ensuring it meets your quality and security standards before it ever reaches production. To get started for free, head to sonarsource.com slash pragmatic. With this, 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. I think a player with MCP was already there and it looped a few more hours. And then I had a Twitter login page and it did something. I mean, it was not great, but it did something.

38:37And to me, this was my holy fuck mind-blowing moment.

38:41The Pragmatic Engineer Host:Yeah. And 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. It's like, yeah, this is where it's going. And from that moment on, I had a few months where I had really trouble sleeping. And I... I remember because once on Twitter, I sent you a direct message. I was up early for valid reasons, you know, my kids or something like that. But it was 5 a.m. and I sent you a message on Twitter and you replied immediately. And I was like, why are you up? And it's like, oh, this is usual. Like I usually I'm still usually awake.

39:20The Pragmatic Engineer Host:And I asked like, why? And you said like, oh, I'm just like using Claude and it's really, really addictive. And I was like, really? And you're like, yeah, I'm not joking. Like, it's really good. And I think that was the thing. You said something or wrote something like just one more prompt. Like you told me how, like what made it so addictive or what still makes it so addictive? Oh, it's the same economics as you go to a casino. It's my little slot machines. You know, you press the trigger and it's like, ding, ding, ding, ding, ding. And it's like, nope. You tap in the prompt and it will like, and it does it.

39:54It does crap. Or it does something that actually blows your mind.

39:59The Pragmatic Engineer Host:And it's this. And you're saying it blows your mind as like you're a really experienced developer. like it's not easy to blow your mind, right? Like you've seen good code. You can differentiate like crap code, decent code, good enough code. Like you have a bar, right? It's so funny, you know. In my company, I used to obsess over every detail, every spacing, every new line, the naming. I spent so much time bike-shedding. And in retrospect, I'm like, what the heck? Why did I do that? Like, what's the point? that the customer doesn't see the inside. Of course, like it has to meet certain standards.

40:38It has to work. It has to be fast. It should be secure. But like how much did I bike shed there? It's like a stupido.

40:47The Pragmatic Engineer Host:You say that, but then you also just said that people loved PSPDF because it was the most polished. It worked the best. Do you not think that that amount of carrying, bike shedding as you call it, being obsessed, it sounded like you were keeping tech depth at bay. You know, like being obsessed with white spaces, it's not going to be messy. And we know it's not just the white spaces. We know you're going to care about testing and all that. Like, it sounds to me that PS PDF kit, like, you know, like what I see is you were not just building a product that was great UX, but you built something that had a really good hygiene and that's how it could be high performance and all that.

41:24The Pragmatic Engineer Host:How do you think about it? Yeah, yeah, yeah, to a degree, yes. And even now, my last blog post was a confession that I shipcoded on Read. Yeah, we have to talk about that. And at the same time, I spent so much time restructuring. I mean, even today, I really wanted to get this PR in where it was like 15 ,000 line chains. where in my list for sure I moved everything over to a plugin architecture which I was so excited about and I care a lot about the structure. Did I read all the code? No. Because a lot of code really is just boring plumbing. Well, what are most apps? Like data comes in from an API in one form.

42:11You're like, you parse it, you package it into a different form, you store it in a database as a different form. It comes out again in a different form. Then it's like HTML or whatever. And you're typing something. it's a different form again and all you do is like you're massaging data in different forms throughout your app. This is what most apps are we are pretty chasing printers. And the really the hard part is solved by Postgres 30 years ago by some neck birds. That's really what a lot of software is. Like there's always some interesting parts but I don't have to care how this button is aligned or which Tailwind class is used or like many details are boring and many other details are interesting.

42:53But I think it's much more about system architecture than having to read every single line.

42:59The Pragmatic Engineer Host:Right now, jumping forward, what is your workflow like? When you're working on CloudBot, are you using a terminal, multiple terminals, which tools, and how are you... You said you're not reviewing the code, but you're still thinking about architecture. What does your average day look like in terms of tooling? You have to explain to a developer who might join the team you know at one point you think like what does it look like it's interesting let's let's let's go a little bit we were we were in in in april with cloud code and then i got really hooked and then i did some i had a phase where i did cursor and then i did i i used gemini 2.5 a bit then we had this phase with opus 4 i hooked up a lot of my friends like i know i know both armin and mario from Vienna, they got AI pilled because I was addictive.

43:54My end-of-the-artism was like confusing them and then they tried it out and then eventually they also were up at 5am and I called it like the Black Eye Club. I mean, there's a reason. I started a meetup in London that I called Cloud Code Anonymous because it's a little bit like a drug because it's so it's so much fun. To me, what blew my mind so much was this realization that I can build everything now. Before, you had to really pick which side project you build because software is hard. It's still hard. But now, this friction that I talked about where I'm so good at this technology and I'm so bad at this.

44:37And I'm like, let's make the CLI in Go. I have no clue about Go, but I have a good system understanding. and once you have that it's like you you develop a feeling what's right what's wrong like it's it is a skill in itself i remember there was this tweet where someone said oh when you write a code you you feel the friction and that's why that's how you make good architecture i feel the same friction when i prompt because i i see the code flying by i see how long it takes i see if like 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.

45:18If it takes much longer, I understand that I messed up somewhere.

45:21The Pragmatic Engineer Host:You kind of feel the model. You know how usually it's like this or if it runs. I feel it's very much a symbiosis. I learned to talk, may I even say there, or that language more. So it's like my knowledge, how to use those things improved. And also the models improved. And then like over the time between April and now, I would say that inflection point was summer where it just got so good that you could create software without actually writing code by hand. But the real change that sold it for me was again, GPT 5.2. That was again, I think it's underrated. I don't know why all these people still use Cloud Code.

46:09I kind of get it. It's a different way of working. But whatever OpenAI cooked there is insanely good. Pretty much every prompt I type gives me the result I want, which is insane. Like on CloudBot, my latest product, I use between five and ten agents in parallel. If you're very much cloud code built, you have to forget quite a lot of the silliness, the things that you have to do to create good output with cloud code. I mean, I also met that team and they created a whole new category. Like cloud code is a category defining product and it is amazing for general purpose computer work. And it is really good for coding.

47:00And I still use it almost every day. but for writing code in complex applications, Codex is just so much better because it takes 10 times longer. Cloud would read three files and then be confident enough to just create code. And then you really have to steer it and push it so it reads more code, so it sees a bigger picture of your code base, so it weaves in new features better. And Codex will just be silent and just read files for 10 minutes. And if you only work on one terminal, I completely understand how you find this unbearable. But I rather have something where it's also you don't tell it what to do.

47:45You know, this is also something that people don't get. Like I have a conversation with the model. It's like, oh, let's look at this. What options do we have for this structure? Did you consider this feature? It's like, because every session is like The model starts from having no understanding about your product, and sometimes you have to just give it a little bit of pointers. What about this and this? So it explores different directions. And you don't need plan mode. I'm just having a conversation. Until I say, build this, it will not build this. There are some trigger words, because it is. They all are a little trigger hungry.

48:22But as soon as I say, let's discuss or give me options, they will not build things until I say, build.

48:28The Pragmatic Engineer Host:so a lot of would you say a lot of your prompting or a good part of it is this conversation where you are pretty much planning together with the agent yeah it's like what about you remind them it's like okay we need documentation what would be a good spot it would like give me some recommendations no this should really be its own page do we need a configuration how does this fit into this other feature it's like I am designing the system because I have this system understanding about how is my product, how are the shapes looking? I don't have a line-by-line code understanding. That's what Codex does for me.

49:06But I'm the architect, you know?

49:08The Pragmatic Engineer Host:It sounds a little bit like you're almost, you know, years back, this totally came out, got out of style, but there was this idea that you would have the architect with a capital A, who used to be a software developer, but they're not hands-on anymore because they spend a lot of time understanding the business and they have these developers working underneath them. And some companies still kind of work a little bit like this, but most modern companies don't. But some banks, et cetera, I met people there who are capital architects. They do the system plan. They talk with fellow architects. They have the blueprint.

49:43The Pragmatic Engineer Host:And then they literally pass it down to the team. And everyone hates this model, obviously, because, you know, again, like I think as people, you kind of want more. The architect is never on call for the stuff. And so it just kind of breaks down in practice. and a lot of large companies just moved to the staff engineer model where you're kind of all working together. Of course, there's people who might have more input. But it sounds like it's almost like this world where you are the architect who kind of, you know, you have your little agents who do the code, except in this case, you are, of course, fully responsible because you're still an individual contributor.

50:15The Pragmatic Engineer Host:You're not like, okay, you might say you're a manager of agents or whatnot, but the code is yours. It's your responsibility. You're going to be on call if, you know, if you push out code that takes down CloudBot, which it did just recently, you're on the hook for it, right? And I think the difference in this system when it was in companies, the architect was kind of shielded from the output of their work because there's so much people and so much process, et cetera. Well, I wouldn't say architect. I like the word builder. Builder, yeah. And I think also there's a few categories that I see for people that are highly successful using AI and people who really struggle.

50:54I care more about the outcome the product I very much care about how it feels and everything but how the plumbing works underneath I care structurally but you know not to the not the biggest detail and then there are people who really love to to code on hard problems like think about algorithms don't really like the I'm building a product with like all the marketing all the they more like they like to solve hard problems and those are the people who really struggle and and and often reject AI or get really sad because that's exactly the job where that AI does. Like it solves the hard problems.

51:31Now sometimes I give it some pointers but many times I learned I learned more this year than the last five years around around software architecture and designing. There's so much inside those monsters on knowledge and everything is just a question away but you have to know what question to ask. Of course, I also built this Twitter thing and it's still not done and I really hope I'll get back to it at one time. Everything worked, but if I used it more at some point, things got really laggy and weird and then it worked again. And I just couldn't figure it out. And it was like really difficult to debug because it was not easy to reproduce.

52:08It was just like you use it more and things got really slow. I basically had like software in PSQL, like in Postgres, that would be triggered when certain inserts were doing and then the database would get really busy. And the model couldn't see it because it was so far abstracted from all the... You know, like those models are really good at tracing through. But this was a side effect that was so hard to see because it was only in this one file, a function that had no connection to anything else with a name that was not easy grabable. I just never asked the right question until I was like, do we have any side effects for this and this?

52:47and I found it

52:48The Pragmatic Engineer Host:and I fixed it and it's like but everything is just the right question in a way yeah but you need to have like knowledge expertise yeah experience I mean so these are the people who reject it and then the people who care a bit less about how it's being plumbed internally but are just excited to build things they are really successful and one thing that also helped me is you know when you run a company and then you hire people you can't breathe on everyone's neck and make them have the line of code exactly that way. And there's a lot of people who didn't manage a team and didn't have this experience how to relax a little bit and understand that, yes, this maybe is not exactly that code that I want, but it will get me closer to my goal.

53:35And for anything that is not perfect, we can always make it better and put more time into it. I very much believe in this iterative improvement. I had to learn to let go a little bit of my company. So then when I had cloud code, it kind of felt like I have imperfect, sometimes silly, but sometimes very brilliant engineers that I have to steer and where we work together on a common goal. It felt like being the boss again.

54:04The Pragmatic Engineer Host:Interesting. Now, you built kind of software, I guess, the traditional way, pre-AI for 15 years or even more than 15 years. and you got really good at being also leading a team and how to have high standards. You really cared about the craft there as well. You've now kind of been, I guess, vibe coding or working with agents for a year. You're comparing the two. What do you think really, really changed? And what do you think are things that kind of stayed the same despite all that? First of all, I don't like the term vibe code. All right. How should we call it? I think vibe coding is by now almost a slow.

54:39Oh, yeah. I call it, I tell people, what I do is enchanting engineering with a little star. Vibe coding starts at 3 a.m. Now, because all the mundane stuff of writing code is automated away, I can move so much faster, but also means I have to think so much more. I'm still very much in the flow. It is completely the same feeling for me. I very much get in this flow state, but it is mentally even more taxing because I don't have one employee that I manage. I have like five or 10 that all work on things. And I switch from this one part to this other part, to this other part, to this other part. Mostly because of I'm designing this new subsystem or like this feature.

55:19And then I know that it will probably take codecs like 40 minutes or one hour to build. So like, I want to like have the plan right. And then I build it. And then I'll move on to something else. But then this is cooking. And then I work on this. And then this is cooking. And then this is cooking. And then at some point, this is cooking. And then this is cooking. And then I go back to this one. So I switch around a lot in my head.

55:42The Pragmatic Engineer Host:I wish I wouldn't have to do that. I'm sure this is a transitionary problem. And at some point, we have models and systems that are so fast that I can parallelize a little less. But to stay in the flow state, I need to massively parallelize. So that's how it works. And I go back to there and maybe tweak it a little bit more, but usually just try it out. maybe then this is ready because this only took like 20 minutes so like I constantly jump around usually there's one main project that has my focus and I have like some satellite projects that also need attention but where I can maybe spend five minutes it does something for half an hour and I try it and it doesn't need so much capacity up there this almost sounds you know like two things come to mind one is there's these like games where you have to manage a kitchen with the employee and you see like the recipes or something come out and you need to jump and do it.

56:38The Pragmatic Engineer Host:It's more like StarCraft, you know, they have your main base and you have like your side bases to give you resources. That as well. And also one thing that just came to mind, as you said, like I go there and I watch this and I make a decision, is when I see the chess grandmasters play multiple boards at once, you see sometimes 20 boards and they always all, you know, they go there, they kind of, you can see that they just like see what's on that board, they make a decision and for some boards they stop for longer i guess better players or better opponents it feels you know both they're occupying 100 of their brain you're occupying your brain you're kind of just scaling yourself as long as you can context switch the difference the difference was up until this with cloud code i you have to work a little different because it is much faster but then the output often doesn't work on the first try so like it makes something but then and it forgot to update three other things, it crashes.

57:29Or you give it... The good thing of how to be effective with coding agent is always like you have to close the loop. It needs to be able to debug and test itself. That's the big secret. That's also something I... I think that's part of why I got so much more effective. But yeah, with Cloud Code, I often had to go back and fix up the stuff. Or it just takes a lot of iterations. so in the end it's not that much faster it's just more interactive and these days with Codex it just almost always gets it right my general strategy is always I build a feature and of course you always let it write tests and you make sure that it runs its existence so even when I write a Mac app yesterday I debugged this feature where the Macup couldn't find a remote gateway, but like the same code in TypeScript could.

58:31But Macup is kind of annoying to debug because like it builds it, you have to start it, you have to look at it, you have to like, no, this is not working. So now I just said it like, you know, you're going to build a CLI just for debugging that invokes all the same code paths that you can call yourself and then you just iterate and you fix it yourself. And then it will just cook and it just cooked for an hour and it was done. And it told me like, guy there was a race condition here and here and like a misconfiguration blah blah blah. I was like yeah it sounds sensible. I don't need to see that code.

58:59The Pragmatic Engineer Host:But you don't see it because you set up the validation loops and you trust that because it ran it I mean this is I guess it's not too dissimilar to like sometimes when you work on a large project in a large company when all the tests pass I mean it doesn't mean that 100 % it's there but it's a pretty good and all the new code has tests as well you know someone thought about it and tested it and all that. So even on On the very latest project, we always had bugs. For like anti-gravity has like a certain weirdness with how it takes tool calls in the loop in the format. So you have to do like some filtering.

59:36Yeah. And I broke a bunch and it actually took me way too long to realize like, what am I doing here? I just need to automate this. So I was just going to Codex. It's like design live tests that spin up a Docker container, install the whole thing, spin up a loop, use my API keys from this and this file. and then you tell the model to read an image, create an image before and then look into the image and see what it sees. So I don't just tell the loop, I'll still tell tool calling. Make it work. And then it solved itself. It took forever, but it tested all my API keys like from Entropic over ZAI over GLM, like everything and it fixed all those little intricacies where sometimes the tool calling didn't work or the ordering was wrong because I closed the loop.

1:00:26And that's the secret.

1:00:28The Pragmatic Engineer Host:And closing the loop, you mean just have a way to have the agent be able to validate its work? That's the whole reason why those models that we currently have are so good at coding, but sometimes mediocre good at writing creative because there's no easy way to validate, right? But code, I can compile, I can lint, I can execute, I can verify the output. If you design it the right way, you have a perfect loop. Like even now for websites, I built the core in a way that can be run via a CLI. So it's like I have this perfect execution loop because the browser loop is insanely slow. You want something that loops fast.

1:01:09The Pragmatic Engineer Host:So it sounds like one thing that is not really changing from like before is we had this before, like backend or business logic heavy thing could easily be or more easily be verified that it's correct. Surprise, actually using authentic coding makes you a better coder because you have to think harder about your architecture so that it's easier verifiable because verifying is the way how to make things good. Well, and remember back even before AI, for complex systems, like once you got someone who built these things before, what they started with, how do we make it testable, right? Like you need to design interfaces, classes, testable.

1:01:44The Pragmatic Engineer Host:You need to think about like, am I going to fake things? Will I use mocks? Will I use end-to-end testing, which will be long, et cetera. But these are like really hard architectural decisions. And once you make them, they're, I guess, harder to change. And in your world, you know, like the model would cook a lot longer if you ask it to make a massive refactor. And, you know, if you have tested, I'll get it right. But, you know, we still have these trade-offs. It's still software. I would say I write better code now that I don't write code myself anymore. And I wrote really good code. but like even back at the company sometimes testing was so tedious and you come up with all those edge cases and the branching.

1:02:25The Pragmatic Engineer Host:I mean outside of Kent Beck who I deeply respect he was on the podcast and we talk like he still writes tests first and he tells me he's not mad at me for not writing it but if you want to write like you know poor quality code that's on you but I don't know many developers myself included I never liked writing tests and even when I pretended that I did I just never did it's a little bit like writing documentation and writing tests to me it was never a creative expression. It is so good now like I would say for my last project I have really good documentation and I didn't write a single line myself like no I don't write the test I don't write documentation I explain the model the trade-off so like why we did something like this and then tell it like write that write the entrance section beginner friendly and then add more technical detail at the end and it is so good.

1:03:16I never had a project with that good documentation just by every time we design a feature, this is a part of the process and also like testing. I'm almost like, okay, we built this. How are we going to test this? Yeah, we could do this and this and this. What if we build it this way? Oh yeah, then we can test it better. It's like this is now part of my thinking because I always think like how do I close the loop? How do I, the model always needs to be able to verify the work itself which automatically steers me to better architecture.

1:03:45The Pragmatic Engineer Host:So why do you think there's a bunch of experienced devs who are still pushing quite a bit back on just the idea that AI can do a lot of this? That was a week ago. I stumbled over a blog post by McGullochagher, Coco with Love, that I deeply respect and learned a lot from. And this blog post was just, was a dissing of the current way how models work. And what he did was he tested like five or six models, including some that make no sense, like the OpenAI 120 billion open source one. It's not good enough to write good code, you know? And he just, he wrote a prompt. As far as I understand it, there was not a lot of information on the website, but to me it sounded like he wrote a prompt.

1:04:38he put it on cloud web and he pressed send and then he took the output and ran it and it didn't compile and he was disappointed but he's like of course it will not work do you think I can write bug free code on the first attempt and those little those models are ghosts of our collective human knowledge they work very similar in many ways of course they don't get it right the first time there will be mistakes That's why you have to close the feedback loop. And also, you don't just send a prompt to the model. You start a conversation. Hey, this is what I want to build. He complained that it used old API.

1:05:20Yeah, you didn't specify the Mac OS version. So it made an assumption to default to old API because that information was missing. And it is trained on a lot of data, not just the last two years. And there's just more old data than new data. So this is like, the more you understand how those little beasts sync, the better you get at prompting. And then he spent maybe, I don't know, a day on playing with it and then just decided that this technology is still not really good. But to be effective, you have to spend significantly more time. You know, it's like, you know how to play guitar and I put you on the piano and you try it a bit.

1:06:04It's like, oh, this sucks. I'll go back to my guitar. No, no. It's like, it's a different way of building. It's a different way of thinking. You have no idea how often I screamed at like 3 a.m. to Cloud Code because it did something silly. I slowly started to understand why those things do what they do with like exactly the way I tell it to do things. And sometimes you can literally ask. you can even last like I for this project the last project like CloudBoard I feel like a human merge button because the community is like blowing off and all I do is like reviewing PRs I have very little time to actually write code myself anymore and in the beginning it would often like just cherry pick things and would close the PR and I was like so annoyed so I'm like why are you doing this yeah when you say this and this I interpret this this and this it was like ah like I learned the language of the machine a little bit more, I tweaked my prompting and now I get exactly what I want because it's a skill like any other skill.

1:07:06The Pragmatic Engineer Host:Yeah, and this is like Simon Willison has been saying the same thing even though he's been using it for years. And I think everyone, I think once I start to use it, I also realize like I'm not, I'm okay at it, but I could do better. What if we put this to a real test? Because I think it's fair to say that right now you're building CloudBot, which is a, you know, it's not something that generates revenue. There's a lot of users and it's blowing up and it's a really cool tool, but it's not PSPDFKit, which is a business that it's a lot of revenue is hinging over it. If today, you know, we just wiped PSPDFKit does not exist, you need to rebuild PSPDFKit.

1:07:41The Pragmatic Engineer Host:You now have these agents. How differently would it look? How much would you trust it? What would you delegate? What would you validate? And when, you know, you built up a team around it because now it's a profitable business, at the very least, you need to hire salespeople, whatnot. How do you think the team would look different today? that same product because you you know exactly what it took to build it and you also know what these tools can do today 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 you want you want to have really senior engineers that really understand what they build but that are also comfortable in in delegating and know which parts are actually important to work on and which parts I can vibe.

1:08:31That's still something I don't see. I don't see a lot. Like, especially in the AI world,

1:08:37The Pragmatic Engineer Host:there is so much crap on Twitter. There's so many people that are loud but clearly have no clue what they're doing. There's so many dumb concepts around. like I'm sorry but the Ralph Wiggum one ugh like this is again another silliness people use to work around model limitations of Opus you don't even need when you use codex there's there's maybe a few cases where you have a really long list of individual tasks that can be automated but that's usually not how software building works so there's these people who I see so many people building up this elaborated orchestration layers and then you have like Like Beats that ultimately creates tickets and then your agent does tickets and then your agent emails the other agent.

1:09:27And then you build up this elaborate mess. What for? Oh yeah, they design the spec for like a few hours and then it just like the machine builds it in a whole day. I don't believe this works. Like this is the waterfall model of software building. We learned long ago that this doesn't work. Like, yes, people work differently and maybe it does work for some. I just, I just, I don't see how this, how this could work for me. Like, I have to start with an idea and often I purposefully under prompt the agent so it would do something that would give me new ideas. You're like, maybe like 80 % of the things I assume are like crap.

1:10:14But like, there are like two things are like, oh, I didn't think about that way. and then I iterate and shape the project and I have to click it. I have to feel it. I feel to make good software. One thing that those things often lack is taste. I have to feel like, how does this feature feel? And the beauty now is that features are so easy. I can just throw it away or reprompt it. My building model is usually very much forward. it's very rarely that I actually revert and have to go back. It's just like, okay, no, then let's change this. No, no, let's do this. And it's like, it's like shaping. I love how this like, you start with a rock and then you like sizzle away at it, like pick different areas.

1:10:59And then slowly like this statue emerges out of marble. That's how I see, that's how I see building something.

1:11:07The Pragmatic Engineer Host:I guess reflecting on how software engineering is changing, this seems like a change because before, we had AI or these agents, upfront planning did make a difference. At PSPDF, you insisted, I think, to have a proposal where people put a lot of thought up front to specify and do all that. Because it was expensive to, I guess, to build. Do you think this has changed because of the cost of just writing code is going down? I still plan. You still do, yes. but I don't put as much into it because it's now so much easier to just like try and look at the results and then see if, oh yeah, this shape could work or now we have to like, the tweaking and even like, oh no, we have to like do it a completely different way.

1:11:56It's not so much cheaper that it's, to me, it became much more playful.

1:12:00The Pragmatic Engineer Host:Yeah, I guess because like, you know, when you're working, even if you have like a new grad on the team or an intern, you know, you give them something, they're working for a day or two. Now you give them another, it's not a day or two, And we're not talking days here, we're talking minutes, or like if it's a long-running task, like 10, 20 minutes at worst. Plus, you're not just waiting on that thing, you have parallel things running, so it's not that much of a waste, if you will. In Claude, but at the beginning I had this assumption of like one agent, and then eventually changed to multiple agents.

1:12:30And there was an assumption of like one provider like WhatsApp, and now it's multiple ones. And changing that was like such a pain. would have been such a pain if I would have written it myself because you have to weave in literally everything through the whole logic of the application and yeah it took codex like three hours it would have taken me like two weeks you know so so that upfront planning I could have realized that in the beginning but now I I know that like I can just change things and it's it's much it's much easier to work down your technical depth or your you know you evolve how you think about a project as you build a project.

1:13:09That's why I don't believe in, I don't know, things like Gastown where like you write up the spec and then it builds itself and then it's done. How can you even know what you want to build before you built it? You learn so much in the process of building it that will go back into your thinking of how the system actually will end up being. To me, this is very much a circle until I... You don't walk up the mountain like this. you go around and sometimes you like you stray off a little bit of paths but eventually you reach the top.

1:13:40The Pragmatic Engineer Host:That's how I feel in Australia. Then you know you've been building Cloud for what like two months three months non-stop ish or like how long Let me let's switch a little bit here. So one of the ideas that got me back was even even in in April May was I I wanted to have this hyper personal assistant and not like not like one that sends you a good morning email oh these are your three tasks no one that has a really deep understanding of me and doesn't just i don't know i meet a friend and then when i go home it would ping me hey how was how was that meeting or one that would wake me up one day and say hey you haven't texted thomas in three weeks and i noticed he's in town right now because I checked his Instagram account they want to say hi or something that says hey I noticed every time you meet that and that person you're sad why is that like something that is deeply personal like almost the anti-ORM it's kind of like the movie Her but that's where the technology is going those models are really good at understanding text the bigger the context is the more patterns they see and even though they are like matrix calculation without a soul it very often feels different so this was like one of these ideas and I even created a company I called Amantos Maschina like the loving machine but in summer when I explored it the models weren't quite there yet I got some results that was like okay this is like I'm a little too much on the edge of what I need right now Which was very exciting because I know that the state of AI goes so fast that, oh, I can just revisit that in like a little later.

1:15:35And one of the ideas also was that I assume that all of the big corporations right now are very much working on personal assistance. In the future, everyone will have, you will have your best friend who is a freaking machine that will understand you, that will know everything from you, that will can do tasks for you, that will be proactive, that will require a lot of tokens. but everyone who can afford it will have one. And of course, this will democratize and trickle down to like more and more people as we learn how to build more efficient systems and hook up on chips. No question, this is where the things are going.

1:16:18You see like the first things with like OpenAI who launched Pulse with some proactivity, but we just don't have enough compute yet to offer this as a feature. And also it's quite difficult. My idea was, I kind of want something that runs on my computer and where the data is actually mine. And it's also quite scary that you give OpenAid and Drop it access to your email, your calendar, your dating apps. I don't know if you talk to your normie friends, but a lot of my friends in that room, they use that a lot to basically have a therapist. And it does work incredibly well. Like, it's a really great listener.

1:17:02It understands your problems. And unless, like, some of the versions of 4.0 that are like, sure, this is a great idea. I want to put french fries into a salad. It works really well, and I did that too. I mean, part of it just is like the act of reflecting already is helping you. So it would even work if the machine would only repeat exactly what you wrote to a degree. But it actually gives insightful questions. And it's actually, it got really good. So I had this idea of this like assistant, but the tech wasn't there. So I did the other part and I built a whole bunch of fun stuff. Of course, like a bit of a tunnel in your career to become like an authentic engineer, you have this phase.

1:17:45It's a trap phase where you're looping and building your own tools to like optimizing your own workflow. But this idea of like this hyper-personal agent stuck a little bit and then over the last few months I really started I built it but finally initially I didn't even had the scope that it has now like I called it WhatsApp relay I just I just wanted to do to trigger stuff on my computer with WhatsApp so I built like a WhatsApp relay where I had an agent that could do stuff with my computer and then I 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.

1:18:32And I was kind of hooked. It was guiding me through the city. It was making jokes. It could text other friends via WhatsApp from me. And I remember I was blown away because in the beginning the tech was very scrappy. but I built in something where I could send it an image. Didn't even use the proper thing to send an image. I just gave the LLM a string and it could use the read tool to like read the string. And then I was in Morocco and was just like, just like not thinking and sending it a voice message, but I didn't build that. And then like 30 seconds later, it replied to my voice message. I'm like, how the, did you do that?

1:19:15Oh yeah, you sent me a file and then I looked at the header and I found that it's OGG so I used FFMPAC to convert it and then I looked for VISPA on your computer but it's not installed but I found the OpenAI key so I did a curl to OpenAI server let it translate and I'm like holy cow like this was Opus 4.5 and it's so incredibly resourceful like you just did this other people say oh you need a skill or some system No, just like it just figured it out. I slowly got hooked on the thing. I used it to wake me up. And it was running on my Mac studio in London and was connecting OSSH to my MacBook in Morocco and was turning on the music and making it louder and louder because I didn't reply.

1:20:08And to make that work, I added a heartbeat. So which in a way is insane from a security perspective. you have a model that you prompt with do something cool and surprise me that you send every few minutes to make it proactive and like go through your task list like probably the most expensive alarm clock ever but it was just hilarious and also the text it sends like because I was I had a balloon for it and it knew that I had to wake up very early and I didn't reply and it was like you could see the reasoning Peter's not responding

1:20:41The Pragmatic Engineer Host:but Peter has to wake up no no no no no sleep it was bitching to me and then I showed it to the friends I was with and everybody was like hooked, this is something magical and I was hooked too and then I I went on Twitter and I got the most muted responses because nobody would get it I feel it's somewhat of a new category of products that a little bit like your story with like you know when you didn't get the iPhone from the marketing campaigns on TV and anywhere, and then you had to use it. Yeah, so I worked on it, but only the last two months. And the name changed from Val Relay to, at some point, a Claude.

1:21:27What is this name? It doesn't fit the feature set anymore because I had Telegram in there and other features. So I renamed it to Claudius because it's an inside joke because I like Doctor Who. I felt CloudBot is a better name, has a better domain. and explain the product better. So it had done on the domains. And then I also quietly built up my army because to make this work, you want everything to be a CLI. So I was just building CLIs for everything, like for Google, for my bed,

1:21:59The Pragmatic Engineer Host:for lamps, for music. Why CLIs? Why not MCPs? And what do you think about MCPs anyway? It's a crutch. I think that the best thing that came out of MCPs is that it made companies rethink to open up more APIs. But the whole concept is silly. You have to pre-export all the functions of all the tools and all the explanations when your session loads. And then the model has to send a precise blob of JSON there and gets JSON back. But surprise, models are really good at using Bash. and like imagine imagine you have a weather service so the model could ask for a list of available cities and then get like 500 cities back and then it has to pick one city out of 500 cities but it cannot filter that list because that's not part of how MCP works and then it says okay give me the weather for London and you would get like the weather temperature, wind, rain and like 50 other things that I'm not interested in because I just want to know is it raining or not?

1:23:07Probably raining because London But the model needs to digest everything, and then you have so much crap in your context. Whereas if it's a CLI, it could use GQ and just a filter for exactly what it needs.

1:23:19The Pragmatic Engineer Host:But does it not seem like a limitation that everything is loaded around an MCP in the context? That seems a problem. It sounds like it could work if MCPs were not in the context and there was a way to discover or decide which one to use. Yeah, that's what companies are building now. But there's still the problem of that I cannot chain them. I cannot easily build a script that says, hey, get me all the cities that are over 25 degrees and then filter out only that part of information and pack it in one command. It's all individual MCP calls. I cannot script it. Yeah, but I guess this is just a matter of time because if we think about when I'm building a weather app right now, I know that even without AI, I know I need to build up this thing.

1:24:04The Pragmatic Engineer Host:I need to fetch the data, So I will search what kind of APIs are available, which one do I like, what kind of trade-offs for pricing, for covering, et cetera. And then I choose that API. And I could chain APIs because I could get that result and look up, et cetera. So I guess this is, you know, like, it sounds pretty much, we've solved this. So as free AI, we're going to solve it. It'll just take some time. And who knows what the format for it will be. I mean, I built MacPorter, which is a small TypeScript thing that converts an MCP to a CLI. So you can just package it up. Basically, you're saying CLIs right now are a lot more efficient.

1:24:42Yeah, yeah. So in CloudBot, I don't have MCP support, but you can, via MacPorter, you can use any MCP. You can literally be on your phone and say, hey, use the Vercel MCP to do this and this, and it will go on the website, it will find the MCP, it will load it, and it will use it all on demand. even right now if you use mcp you have to restart cloud code which is like very user unfriendly so i quietly built up my army to like automate everything which was a lot of work i think teo did a video a few days ago where he told me like this guy is insane because the list is really long by now but like i i as i was playing with my my my agent i just i wanted him to do more and more stuff you know i felt it really hard to convey what it does still hard to me.

1:25:31In January January 1st? Just a week now? I did okay. Let's try something. Let's do the really insane thing of making a Discord and then adding my agent to Discord. There was somebody who contributed Discord support to it and even though I wasn't sure if I should merge it, then I actually did. So I put on my agent who has full read-write access to my computer in a public Discord.

1:26:00The Pragmatic Engineer Host:What could possibly go wrong? Yeah, it's like, this is absolutely insane. And then, of course, some people turned to Discord, and then they saw me using the full power of this thing, like checking my cameras, doing home automation, it playing DJ for me. I was in the kitchen, and I told them, look at my screen, and are my agents done? Because it has full access of my clean, and it can click. So it can actually click into the terminal and type for me, and it can tell me, your codex say this and this, because it just sees the screen. I mean, I'm working on optimizing that. Like I actually want to stream out it because it would be much better if it's text.

1:26:37But it works already. Like it's in the background. It's I'm looking at my screen and like make some rants if I do some shit. And everybody who experienced it for a few minutes got hooked. Like this was the craziest blow up from 100 stars to like what? 3 ,300 stars in a week. And I think I merged 500 podcasts already. that's why i feel like a human merge button so that's why that's why i'm a little i'm little all over the place these days because this project is blowing off and and and you know the beauty of it is the technology disappears you just you just talk to a friend on your phone that is infinitely resourceful has access to your the email your calendar your files can build websites for you can like do administrative work can scrape websites can call your friends or can call a business i'm just about to to merge the call feature it literally can call a business and like make a reservation for you and you don't have to think about compactation or or in all of that context blends away i have like a have a memory system that will remember um not perfect nothing's perfect yet but it's already feels magical because all because because now i i walk around i see like this event i i send claude a picture it will it will not only tell me the reviews of this event if there's a conflict in my calendar if like friends talked about it or you know it has so much context that it the responses that it can give me are like so much better than like what any of the current tools that live in their own little box can give me.

1:28:20The Pragmatic Engineer Host:Well, sounds like you built whatever Apple was hoping Siri to do, but they've been unable to. Honestly, I built the best marketing tool for Entropic to sell them more subscription. I don't know how many people signed up for the$200 subscription because of CloudBot. And like many people already had one and used a second subscription because of that, because it's so token hungry. It's not that it's token hungry, it's just that people love it so much that they use it all the time. And because the technology blends away, they don't see that it spawns sub-agents and does a whole bunch of things in the background to just make it feel easy.

1:28:58But there's some actual engineering and there's a lot of work in the back to make it feel easy. You know, this is the hard part. You hide complexity to a degree that it feels magical.

1:29:11The Pragmatic Engineer Host:So, oh, but yeah, but this is interesting because like I can sense from we're talking, you know, you put so much thought into architecting this thing. And right now, like you've been building this for a few months and yes, it blew up. But in your head, like, do you have a structure of how CloudBot is structured? Like what parts you need to modify? You know, like, like you kind of you can get your mindset into it and you know where modification needs to do. You know what you want to refactor because it's not going to be efficient. are you thinking about like things like memory consumption token consumption efficiency those kind of things i mean token consumption is more like how do how do structure the prompt and memory it's it's typescript that shows jason around in the end let's be honest yeah like like like i get text from from an llm i save text to to disk i send text to whatsapp or to now we have like msteams slack discord uh signal imessage whatsapp and there's there's two more that are landing like metrics that will will expand this thing even further it's like it's it's really poorly by now but but mostly i i again i i move around text in different shapes and maybe maybe it goes to different providers or there's like now it's different agents and there's like the agenting loop and there's like a lot of configuration and there's it's a lot of plumbing but nothing's there's nothing in there that is really difficult yeah well but it's a lot of small things right like i i feel in software right like we we know for software even before ai there was not much difficult of course you need to learn and understand the language and all that but the difficulty is how do i how do i make it so that it feels magical so so what i worked on a lot is now you have this one-liner that you type in, that you paste in your command.

1:31:03I will check if you have known installed, homebrew installed. I'll install the npm package. I'll do some check if you have any existing stuff. Just to make it work simple even if you already used an older version and everything. And then I'll guide you through setting up a model. But again, I will pre-find if you have Codex or Cloud installed. So you can just press enter. So you don't have to think about it. Mostly just press enter. And then you want to WhatsApp, you type in your number, it will just work again. And then I'll ask you, do you want to hatch your bot? And you can press yes. And then like a TUI comes up because you're still in the terminal, right?

1:31:47You want a good experience? So just a TUI basically for that and where you just see, wake up my friend. And then I programmed the model, I added a bootstrap file and to explain the model that it is now being born, to create an identity and a soul where the values of the user are in. And then the model will be like, hello, like, stretches. Who are you? Who I am? What's my name? You know, and this is this, like I watch people do it and that's where the magic starts. That's where they are like, they no longer think about, I'm talking to GPD 4.2, No, I'm now talking to my friend created Vahorn, like a unicorn with part of his name, or like I'm talking to Claude.

1:32:36And then it's like, what's important to you? What do you do? It's like curious. I programmed it to be like curious and then go through this bootstrapping phase and then it will actually delete the bootstrap file and create a user.md with like information about you, a soul.md with like all the core values and an identity with the, like what's his name, what's his core emoji, what are the things that are like inside jokes but it's like evolving documents that it will maintain and like tweak as you interact with it and then it will just like send you a message on WhatsApp and you just like suddenly you talk on WhatsApp like making this flow easy, that is hard also like even coming up with the idea of you're not editing the configuration because the agent can edit its own configuration, you don't have to update anything because the agent can update itself.

1:33:28You can literally ask your bot update yourself and it will fetch itself and update itself and come back and say, hey, I have new features. Blending the technology away so far, that's the magic. That's why I...

1:33:39The Pragmatic Engineer Host:But it feels pretty similar to what you would with PSPDFKit, right? You kind of blended away the complexity of a PDF so it was just there, you could rotate, you could do... Yeah, even at the API level back then. But it's a bit bizarre. Like what you described reminds me of this Black Mirror episode I just watched, which is called Play Thing, where it's a digital little creature that creates, of course, a Black Mirror, so it has a bit of a dark ending. But it was also a game. It also kind of feels, you know, we talked about how you don't play as much games because you like, but this also feels a little bit like a game, right?

1:34:15The Pragmatic Engineer Host:But it's kind of like more connected with reality. Just fascinating how we're here. Pulling back into the realm of software engineering, So you built this product and it's now it's a production software. You're merging port because people are using it. Now, thinking back to PSPDF and companies that are like that, which which have, you know, like tens or hundreds of developers working on production software. Knowing what you know with how you're building CloudBot and the tools that you're using. How do you think software engineering at those larger companies could change? Because one thing I see is for individual people like you, it's like AI is really, really hitting a fit.

1:34:55The Pragmatic Engineer Host:Like you're making you way more productive. You're in control. At teams or at companies that are, you know, have existing code, it's just a lot kind of slower. It's not really, okay, people use it for this or that. But it seems a huge divide between the two worlds. And you've kind of been the CEO for this company. What might that be? Or is it just more of a timing thing where every new technology often comes with hobbies, you know, pick it up earlier? I think companies will have a really high time adopting AI efficiently because this also requires to completely redefine how the company works. You know, like at Google, they tell you you can either be an engineer or like a manager, or you want to also like define how the UI looks.

1:35:38That role doesn't exist because either you build it or you design it. But this new world needs people that have a product vision. that can be able to do everything and you need like far fewer of them but ultimately just very high agency and high competency people but you can probably like

1:36:02The Pragmatic Engineer Host:trim the company down to like 30 % which is very scary because like I mean economically this will all lead into a fiasco and a lot of people will like have trouble finding a place in this new world but I'm not the least surprised that current companies cannot very successfully use AI. I mean, they do to a degree, but you have to do a big refactor first, you know, like not just on your code base, but also on your company. I design, even on the code bases, I design the code base not so it's useful. It's easy for me. It has to be easy for the agent. I optimize for different things, not always the things that I prefer, but the things I know work the best and have the least friction for those models because I just want to move faster.

1:36:53And ultimately, they have to deal with the code, not me. I deal with the overall structure and architecture, and I can still do that in the way that I like. Everything has to be resawed. You know, pull requests. I see them more as prompt requests now. Like, somebody opens a pull request, I don't, a lot of do I say thanks, and I think about the feature. And then with my agent, we start off with the PR, and then I'll design the feature as I see fit. The agent rarely reuses, like maybe I reuse some code, but it's more like it gives the agent a good understanding of what the goal is. And sometimes it's very useful because it's tricky bugs, right?

1:37:31But I basically rewrite every pull request and weave it in. Also a lot of people, let's just say the overall code quality of PR is run down a lot because people vibe code and building a successful feature still needs a lot of understanding of your overall design. And if you cannot do that, you will have a harder time steering your agent and the output will be bad.

1:37:55The Pragmatic Engineer Host:Yeah, and if you don't have the feedback loop to close it, et cetera. Yeah, so I found it highly effective. Like at PS3DFKit, sometimes a pull request was like a week in the work and you comment on it and then somebody has to context switch and you wait for CI for 40 minutes. No, I have the discussion. I say, okay, how would this affect something? like I let the model review it. It will already bring something up. I have some ideas as well. We're going to reshape it into a form that fits my vision. And then we weave in the code. It's literally, there's so many new words I use for like writing code now with those models, which is so funny, like weaving in code into an existing structure.

1:38:32And sometimes you have to like change the structure

1:38:33The Pragmatic Engineer Host:so it would fit. Now, imagine that you would hire one or two people to make it a small team. How do you think in this world, and you want to keep doing what you're doing, How do you think things like code review, CI, CD would change? I don't care much about CI. Why? Why not? You used to care a lot. Like a PSP, you used to care a lot, right? And I still do this. There's value. But I have local CI. I'm a little bit of DAH pill now. Because the agent runs the test, right? Yeah, and it's just way faster. I want to push back on the PR and wait for 10 minutes to wait for CI. Because you've waited 10 minutes on the agent already.

1:39:17If the test passed locally, we merge. And then, yes, sometimes main slips a little bit, but it's usually very close because maybe sometimes I forget. And the agents call it gate. I don't know where that's coming from. Should I run full gate? So now I call it gate. Full gate is like linting and building and checking and running all the tests. And I almost think it like, because it's a wall, you know, like it's like, he calls the linter and like the builder and the tester. It's almost like a gate before my code goes out. So I know I always like, okay, once you're done, like commit this, run full gate.

1:39:52Like I'm slowly adopting their language.

1:39:54The Pragmatic Engineer Host:But, and if you hired like one more person to work on this, you probably wouldn't do code reviews either. That's what I'm sensing. You would, you'd probably trust this person to run, like pick up your working style, right? Even in Discord, we don't talk code, we talk about architecture, like big decisions. You still need to have style. There was this one pull request that adds voice calling. So now, literally, I can tell Claude, hey, can you call this restaurant and reserve your seats? And it can do that. But it's quite a big new module that touches a lot of places. I'm like, you have to have this feeling.

1:40:33It's like this ick. like I got a little bit of this ache it's like I want to merge this but oh this is becoming bloatware so I I had this idea of like let's my typical way let's make a CLI out of it and I already had a project where I tried to solve something like this but I'm finished so I opened up Codex and said hey look at this PR look at this project could we weave this feature in I again say weave I'm like so no let's keep it could we weave this feature into the CLI what are the up and downsides and then it would like tell me like oh yeah I could do this and this and this to give me an honest opinion, to me, it sounds like it would fit into the project.

1:41:09It was like, yeah, you would get this and these benefits that we cannot do if we're next on CLI. Okay, but I don't like this. This is getting blood. Could we build a plugin architecture? And you know, one of the secret hacks on using AI effectively is you reference other products. Like I constantly tell it, look into this folder because I solved it there and I solved it there. and all the previous thinking I did to solve the problem well, the AI is so good at this still to read the code and understand my ideas. I don't have to explain it again. Or if I explain it again, I might make mistakes that wouldn't get across exactly the idea that I have in my head.

1:41:49So in this case, I know that Mario, who does shitty coding agent, which is actually very much not shitty coding agent. It's called Pi. I know that he had this plugin architecture that would load code via GT and because it's all TypeScript. So it was like, can you look into this folder and this folder? And then it just came up with this really insanely good plugin architecture, again, by like being inspired by other people. And then that's why, you know, I have this feeling. And then I came up with, yeah, that's what I built last night, basically.

1:42:17The Pragmatic Engineer Host:I mean, it sounds like this is going to be completely different. Like, you know, PRs are like in your workflow. You're not using PRs that much. CI is just different. It's tests are still doing. There's a more important feedback loop. You're using things more like weaving. instead of code, you're talking more about architecture and tastes. It sounds like a pretty big shift to me. In this world, let's assume you get to the point where you're going to hire the next one and two and three developers on this team. Let's imagine that this thing gets a life of its own and maybe it's a business as well.

1:42:49The Pragmatic Engineer Host:What skills would you look for and what would you advise an experienced engineer right now? Who would you be excited to work with? what kind of either expertise projects would you look for for someone who sounds like who can work in this way or can pick up this way of working someone who is active on github and does open source and and someone where i have the feeling that they they love the game the way you learn in this new world is by like trying stuff and it very much feels like a game where you improve your skills as you get better like like like a music instrument you have to like keep trying and i and i that i'm now this efficient and this fast and i don't know like i i think like the other day i had like 600 commits in a single day this is like completely nuts and it works like it's not it's not like there was there was a somebody did a code review and said like oh this is actually not slop and i'm like yeah yeah there's a lot of skill that went into it yeah it's it's it's it's a lot of hard work but you need to play with the technology and learn and then you will get in the beginning it might be frustrating i don't know kind of like you you know you start going to the gym it's gonna suck it's gonna be painful um but very quickly you like you get better and you and you feel that that your workflow gets faster and then you feel the improvements and then you get hooked.

1:44:13But yeah, play and also work hard.

1:44:19The Pragmatic Engineer Host:Yeah, I mean you're putting more hours into this thing. I've never, right now I've never worked more, even when I had my company, 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. But also because right now I'm like using the moment where this has traction and there's a lot of people who like are pushing me um and i i feel could it be because i think you have a pretty good business sense not not not not necessarily in the business business but seeing when there's an opportunity there is an opening for to get traction right like what you said for people to work in the open right now it seems novel you're telling me you don't think you could even if you wanted to hire you don't think you could hire people because there's not many people working in the open clearly using these things fast forward two or three years from now once a bunch of people start to do it and everyone does it, it's kind of like moot a little bit.

1:45:14The Pragmatic Engineer Host:So there's also that. A group that a lot of people are worried about is the new grads, the people with no experience who are either in school or about to graduate, because of course, you've been an experienced engineer. By the time this came around, you have a lot of things to build on. Putting back yourself into shoes of someone like that and knowing what you know now, what would you recommend of activities that they do, things that they build or try? And, you know, like, would you recommend focusing on the fundamentals of software engineering, on this, on the agents, kind of mixing the two? I would recommend them to be infinitely curious.

1:45:50Yes, it's going to be harder to enter this market. It's absolutely going to be harder. And you need to build things to gain experience. I don't think you need to write a lot of code, but you need to, I don't know you know there's a lot of open source that is complex that you can like check out and learn and you have an infinitely patient machine that is able to explain you all the things so you can ask you can ask all questions why why was it built this way to like gain system understanding but it requires real curiosity and I don't think universities right now are set up to teach you that in a really good way this is usually something you discover through pain it's not going to be easy for new people but they have they have the benefit that they are not tainted by all the experience like they would they they use agents in ways that we don't even think about again because they don't know that it doesn't work and by then it probably does and also their friends use it all the time like the other day i i have this little menu bar app for cost tracking on on cursor and and cloud code and everything and it was a bit slow so i was like okay let's do let's do performance measurement and my old way is like i open instruments and click around and it would just call x just and do everything by the terminal it blew me away it's like i didn't even have to open instruments anymore it just like made it faster and then did like some recommendations i'm like all of that sounds good do it yeah i think we might be

1:47:16The Pragmatic Engineer Host:underestimating both like how resourceful people entering tech have been also how young people if I think about some of the great companies started. They were very young and obviously very inexperienced, but had a lot of passion. So that's there as well. Yeah, it's a big opportunity. I'm especially taking, I have to take it in, but all the things you mentioned about just your way, weaving code in, not carrying out PR, not carrying out code reviews. It's a big change because these things have been us with, again, for 15 plus years of your life, they have been. In fact, a lot of it has been kind of you know solid building blocks that pspdf get right yeah we need we need a lot of new things even you know even when i get a pr i'm actually more interested in the prompts than in the code i i ask people to please add the prompts and some do and i i read the prompts more than i read the code because to me this is this is a way higher signal of like how did you get to the solution what did you actually ask how much steering was involved then the actual to me this gives me more idea about the output I don't have to read the code or like if someone wants a feature I ask for a prompt request like write it up really well because then I can just point my agent to the issue and we'll build it so because because the work is the thinking about how it should work and what the details are and if someone else does it for me I can literally say build and it will work and then yeah of course I think about it but it will really or if someone sends me a PR that are just a few fixes, I told people, please don't do that.

1:48:52It takes me 10 times more time to review that than just type in fix in codex and wait a few minutes. So there's all these insane things that would have been completely different even in the beginning. Now we have a one-liner, but for the last two weeks, when it got really traction, I told people to just point an agent at the repository to configure it. So I didn't have an onboarding, but we had cloud code-based onboarding where cloud would like check out the good repository, read the things and write the configuration for those people and set everything up. So it works like set up a launch agent that didn't have the manual setup because it was not a priority anymore because agents can now do that for you.

1:49:32And since the product was built by agents, they structured it exactly the way agents expect things to be named and saying there's certain ways that are encoded in the weights. how they expect things to be named and everything exactly like how they expect so they are really good at navigating their product. So it was not a priority to work on onboarding as much. I mean, eventually I wanted this magical experience, but it was more important to like make sure that your message arrives and that things don't explode. So onboarding was literally like, type this prompt into your agent, which is, would have been mind-blowing even a year ago.

1:50:10The Pragmatic Engineer Host:All right, so to wrap up, we'll do some rapid questions. so I'll just ask and you tell me what's on your mind. What's a tool that is not a CLI, not an ID, it can be physical, that you use, you like, you would recommend? I buy a lot of gadgets and many of them dust away. But there's this one kind of crappy thing that was not expensive that gives me almost unlimited amount of joy. And it's like this Android-powered photo stand where I can upload pictures and where like it has an email address and friends can send pictures and it will just show pictures. And I put a few in my house again. And I mean, even the animations are a little croppy because it runs Android and it's terrible for my technology.

1:50:55But it gives me infinite number of joy because it is low tech that just shows pictures and reminds me of happy moments in my life. And it was like 200 bucks. And I don't know. To be honest, it gets me more joy than the latest iPhone. I bought the iPhone 17. I still haven't unpacked it because I just, in my head, I wanted it, but then I couldn't get around to it because it's just a hassle to like move the sims around. And I said like basically no feelable benefit.

1:51:21The Pragmatic Engineer Host:But like this little device gives me infinite joy. What's something that helps you recharge outside of tech or just moving away from tech and screens? What keeps me sane, even if I work crazy hours, is going to the gym even better. working with a coach and leaving my phone in the locker. And then I really have like a good hour where I just feel me and I'm like in the moment and I'm not distracted by notifications or tempted to like touch my phone. Like we need more time for this. Or even sometimes I go for a walk and I leave my phone at home and it feels very scary. It's almost like an organ by now, you know?

1:52:14It's like your body knows where it is. And if you don't know where your phone is, you freak out.

1:52:18The Pragmatic Engineer Host:I'm having a blast. Love it. This is great, Pete. Thanks very much. 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 to what we've been used to. One thing that really caught my attention is how Peter thinks in prompts and not pull requests, and how he weaves in the code and no longer merges the code. He doesn't find pull requests all that useful and would rather get prompt suggestions even on GitHub. I do think we might have to rethink the importance of prompts, or at the very least sharing of prompts in software development, the more we use AI and AI agents.

1:52:54The Pragmatic Engineer Host:Another thing that struck with me was Peter's emphasizing how important it is to close the loop. As Peter explained, the reason AI is so good at coding, but often mediocre at writing, is because you can validate code. You can compile it, run tests, check the output. So the secret to making AI system development work well is to design your system to close the loop and have the AI run the tests. Finally, I was wondering if Peter is in the flow as much even when he's not writing code. Turns out he is. He's in the flow more than ever, and he told me that it's mentally more exhausting to juggle several AI agents in parallel than it was just to write code.

1:53:26The Pragmatic Engineer Host:My feeling is that someone who was a great developer without AI can be an excellent kind of code architecture or card-ordering person with AI. This is just a gut feeling I've had so far, but Peter seems to prove it. Finally, we should note that CloudBot is more of a YOLO project than most production apps. So take the approaches that we discussed with a grain of salt. At the same time, I do think that a lot of what Peter does could well spread to building production code, except review and validation will become a much more important step in those projects. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.

1:53:58The Pragmatic Engineer Host:A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.