Building Pi, and what makes self-modifying software so fascinating

What if I told you that one of the most influential AI coding agents of 2026 was built by a single developer in Austria who got frustrated with existing AI coding agents? This is Pi, a minimalist, self-modifiable coding agent, which has quietly become the engine behind the wildly popular personal AI assistant, OpenClaw. Mario Zechner is the creator of Pi, and joining him today is Armin Rohnacher, the creator of Flask, and now an early adopter and contributor to Pi. In today's episode, we cover the backstory of Pi and why self-modifying software is much easier to do with AI agents, what Armin learned interviewing 30-plus engineering teams about how AI agents are changing how they work, and why software quality feels like it's trending down, the case against MCP, and why CLIs are becoming so popular, and many more. If you want to hear from two very grounded voices in the industry honestly talk about what's working and what isn't, and why we need to slow down as an industry, this episode is for you. This episode was presented by StatSig, the unified platform for flags, analytics, experiments, and more. This episode was brought to you by WorkOS. Engineers love to build. Today's episode will be a great example of this. We'll get into why and how Pi was built from the ground up. But when you're shipping a product, some problems are better solved with trusted infrastructure built for scale. Enterprise features like SAML, Directory Sync, and Audit Logs are some of those. WorkOS gives you APIs to add them in days, not in months. Ship faster without reinventing the wheel. And now let's get into the episode. Mario and Armin, it's so good to have you here on the podcast. Thanks for having us. Thank you. So as a kickoff, Mario, how did you get into tech and eventually into building AI stuff? Oh, well, that's a long story. How much time do we have? So I'm a kid of the 90s, actually, and I got my first PC in 1996. And the trigger for that was that I loved computer games. We were kind of working poor, so we couldn't afford any of the Game Boy and NES, Super NES stuff. But I had an uncle who had an Amiga 500, and I would go to his place every second day and just play games there. And eventually my parents told me, if you work, you can save up and buy yourself a computer. And in reality, my dad would do, what's it called? Well, you're not necessarily paying your taxes on it. Yeah, so he would do his normal job, and after his normal job, he would go fix cars and work at construction sites. Yeah, it's very common in Europe. I know everyone did that. And after two or three years or so, they just said, it's time, and took me to a computer shop in the nearby big city and bought me a 486. And that's how it started, basically. Antium 486? Yeah, an Intel 486 DX 40 megahertz with turbo button. And that's where I started. And I've always been into games a lot, which also led to graphics programming. And through sheer luck, I got a job while I was studying at university at the Applied Science Organization, who was doing NLP stuff, machine learning, applied machine learning, basically taking research results and trying to stuff them into industry applications. And that's where I learned the ropes of machine learning. That was all before deep learning became a thing. And I actually quit that kind of domain in 2010, 11-ish, because I joined a startup in San Francisco. And then later came back and joined another startup with two friends in Sweden, where we did an ahead-of-time compiler for Java bytecode to iOS that got sold. And since then, I have a little bit more time. And I've always kept up with machine learning stuff, because obviously it's super interesting. And yeah, and then GPT happened. That's the story. Yeah, and here we are. And Armin, where were your roots? My roots are definitely not working poor, but because my parents run an architectural office, where they kind of adopted computers for CAD drawing, my first computer was like old computers that they recycled. So my first computer, even though I'm younger, was in 386. I'm so sorry for you. And so basically none of the computers that I ever had were capable of playing computer games properly. Because one, they used Windows NT, which at the time didn't do anything. So you had to sort of build your way through it. And the only way you could actually get them to run was, because before it didn't know yet how to get the Windows 95 or Windows 3.11. That was before it booted into either one of those, you could boot it into DOS, like the really old DOS games at the time, when you could already get better stuff. But because it was sort of this kind of thing, I started playing around with Quick Basic a lot, with Turbo Pascal, I bought a bunch of books on that. And that was my roots of learning how these things work. And I wasn't ever really good at this, but I found it really interesting. This idea of like, no, for sure. We call it a Tiefstab. to this. And especially after Christmas, I would guess like in more than half the companies I talk to after Christmas, it really exploded. And it, it exploded in all the ways I would expect it, where like all of a sudden the quality drops. And, and it, it doesn't necessarily drop because like people want to make worse code, but because it actually takes some effort to, to stay within this. And we, we have seen this in the startup ecosystem already in the summer last year. Like if you, if you pay attention to like the, the YC startups, a lot of them, some of them have the stuff on GitHub for some period of time on GitHub and you can look at it and like at the time because like plan MD files checked in and like everything attributed to cloud. So like that vibe coding kind of thing was, was for like prototypes and whatever. And like that built that out. It was already out there to see. But then gradually a small version of this has like been code bases with a little bit of vibe slop on top. And, and the interesting sort of part of this was like how engineering teams and companies are now responding to that. With all kinds of like different findings, but a lot of it has been challenged to review PRs. They’re getting larger and larger and they're becoming like more psychological taxing. So like the like engineers specifically are having a hard time keeping up with the, the longer PRs that they're more frequent. Yeah. And they're also there a lot of the code in those PRs is how an engineer wouldn't do it. Because as an engineer, you sort of get a really bad feeling committing certain code because you think of your future self. And the agent really does not care. This is, I will retell this story over and over, but like I, I worked for an Xbox one game at the time, right around the Xbox one launch. So that was like a fixed day. It has to release on that day. So I worked on the Halo Master Chief Collection. And there was a game where it had like a matchmaking component, and you had to like start this thing and whatever. And you know, it was like, it was an all hands on deck kind of situation where people had to go in and unslop the human made slop that was the matchmaker. And it was like, it was, it was a system with like way too many states. We call it an emergent state machine because it was like 16 bulls on one massive thing. And like in theory, about only six valid states, but in reality, it was a geometric explosion of possible states. And that's how a genty code feels like. Where it really should only be like a very clearly defined system, but in all reality, they're like, oh, we can, config doesn't load, let's catch it down and load the default config. So instead of actually failing, it now recovers. But now your code is way more complex than it should be because instead of failing properly, it is now recovering and entering these many more failure states. And that makes it much harder to work with this code because you can also not really ask the agent to reflect. So if the application is like, oh yeah, this could be possible. So we need to maintain this variant. I think it's kind of even worse what you described about your human-made complex system, because there are moments of brilliance in agents where they spit out perfectly fine, simple code. Exactly the amount and type of code you didn't need for that specific thing. And you as the steering engineer looking at that are like, wow, this is amazing. I can just sit back and not care because it's obviously doing the thing, like two minutes later you have another agent running in this window and it spits out the worst, horrible garbage because, but you might not notice because now you have fallen into automation bias and think your, your, your agent is doing the job well. Do you think this might be a bit of a human bias because You know, like typically like onboarding a new engineer, you have a new joiner, a new grad, you review their code. And if it's terrible code, you will review the next one thoroughly until they get to the point that, oh, it writes the code that I do. And then it typically takes, you know, six months or a year or something like that. But then, you know, I can trust this person. Yes, but you don't have anything like that with agents. Like agents don't learn. You can put as much stuff in the agents and do, build a memory system, but that's not the same type of learning than a human does. Obviously humans are available as well, no, no, no matter, but they have some capability of learning. And retaining that learning, right? Yes. And they also feel pain. And I think that's one of the defining things about humans. It's kind of ties back to what you said. Eventually, if the pain gets too big, you as a human are incentivized to fix the cause of your pain. And in a code base, the cause is usually terrible interfaces, terrible complexity that you want to get rid of because you can no longer maintain that system. Isn't this why just scrolling on to the, you know, like senior engineers are always in demand because from the CEO sees a senior engineer as like, they just get it done. But in reality, a senior engineer, most senior engineers who are effective, they've had battle scars. They've been burned. They felt the pain. They saw what happened when they left tech death spiral. So they now make all these decisions. Have they have non-deterministic parts, but all the deterministic parts should be as stable as possible, and that was just not the experience with Cloud Code around summer 2025. So I kind of soured on that real hard. What was it? Was it bugs? Was it unexpected behaviors? It was like, so they take away your control of the context. They would inject stuff behind your back, which is bad. And then your workflows that used to work stopped working because there's now a system reminder that you don't even see in the UI, that will modify the behavior of the model. They would also do this to the system prompt. I reverse-engineered. I mean, I wouldn't call opening an obfuscated JavaScript file and un-obfuscating it reverse engineering, coming from a more low-level background, but I reverse-engineered Cloud Code during the summer of 2025 and built a little service where I can track the progression or evolution of the system prompt and tool definitions in Cloud Code, and it's like every release, it was like messing with stuff. cchistory.mariosechner.at if you want to see that. And yeah, that that just messed with my workflows, and I don't appreciate that. If I commit to a development tool, I want it to be a stable, reliable thing, like a hammer. I don't want my hammer to break a different spot every day. That's terrible. So that's what happened with cloud. But again, I'm this is not like I'm not roasting the team. I think there some of them are really nice people. I got to know on the internet. They're just dog fooding, and that's perfectly fine. We need somebody who, like, goes to the full velocity kind of way. But I don't want to work with a tool like that. Yep, because it can get worked out. It sounds like the move fast and break things to break things was not for you. No. And then I looked into alternatives and Amp Android came out around that time, I think pretty early in 2025. I don't remember. It was very early. Yeah, I think they sort of spun off from the same experience of taking because I think Amp was around when Cloud Code came out. Pretty sure. Around that time. Yeah. In any case, I looked into those harnesses and they were super good. They were just super expensive as well because none of them could basically use what made Cloud Code enticing on top of it being a cool tool on the subscription. And that works in an enterprise setting where you're paying by token anyways, but it doesn't work for the small tinkerer in the garage. While I'm not a small tinkerer in the garage in a financial sense anymore, I kind of still relate to that community and I would like to use my subscription with something. So I looked into open source alternatives and found OpenCode. But while that kind of wipes with my OSS roots, it too did stuff to the context I didn't appreciate behind my back. Training tool results after a certain amount of tool result token output or asking an LSP server after every single edit the model makes if there is an error. Yes, there will be an error because the model isn't done yet with its work, so the code doesn't compile, so the LSP server will So like reaching out to LSP, the language … The Language Server Protocol server, yes. So when you go into VS Code and you type some TypeScript, you have like in the bottom some error diagnostics, and that comes from an LSP server for TypeScript. And OpenCode runs an LSP server on your behalf in the background and feeds the model with diagnostics from that server on every edit. We as programmers, how do we work, right? We go into one more files. We edit line after line after line, and only then look at the errors that resulted from that. In OpenCode’s case or in other harnesses cases that also support LSP, the model calls an edit tool to change lines. And they would inject the diagnostics after every edit call. And that's just not smart because now you're confusing the model with “You have an error, you have an error, you have an error” and the model is like, “Yeah, I know, I know. I'm not done yet”. It's not great. Anyways, TL;DR OpenCode wasn't for me either. It was also I had to fork it to modify it, which I don't think should be necessary. So then I just thought, how hard can it be? I built my own little thing. And then your own little thing is pretty minimalistic. What does it use? What's the basics of Pi? The basics of Pi are my own abstraction over all the LLM provider APIs, because I didn't like the Vercel SDK, the Vercel AI SDK for various reasons. Armin kind of wrote a blog post eventually about that as well. It's obviously good to use. Lots of people use it. It just didn't fit my old man sense of abstraction. This is the beauty of software and especially open source. You can build your own always. Yeah. And now with agents, you can even do it faster and produce terrible complex software. No. So I built an abstraction over that. Then I built a little abstraction for a generalized agent loop with tool calling and streaming, all of that. I built a bespoke little tool that doesn't flicker or not a lot. And then I tied it all together into a coding agent that looks like Cloud Code or Codex or whatever you have. That's it. And the extensibility comes from the fact that this minimal core has so many hook points that you can basically hook. Build a tool for open core ones, which embeds issue and pull request into a 3D space so I can see the clusters of similar things that agents would have sent to the repository. And then I can bulk select things and close them out in… Oh really? So you actually have a 3D like visualization. Yeah. OpenClive for context, I think it's less crazy now, but end of December to I think mid-February, like I mean it was exploding obviously, but like this explosion almost like directly translated to, I was on this repo refreshing pull requests and the number went up. Yeah. We actually tried to contribute and help out Peter a little bit, but I immediately gave up. I didn't know how to do anything useful there. I was looking at this and I was like, this is a type of software engineering I'm just not used to. Yeah. I would fix two things and spend an hour on them and then five minutes after I committed and pushed it, some clanker comes along and just reverts my fixes. And this is not how I work. Can we talk about the name of the name clanker? Oh, sure. So Clone Wars, Star Wars. I actually never watched it, but kids of friends of mine watched it a lot while we were visiting them. So I kind of through osmosis got the lore. And there is an army of robots and the jedis would call them clankers or people who call them clankers because when they moved, they clank, clank, clank. Yeah, that's the origin of that. So an AI, a droid. Yeah, exactly. Yeah. But coming back to the, how do you deal with the influx of agentic pull requests and issues, I just auto close every pull request. Human agent doesn't matter. What I do is if I haven't had contact with you previously, my GitHub workflow knows about this because if you had, you're in a file in my Git repository, your account name. So if you're not in there and you send me a pull request, your pull request gets auto closed. And then my little workflow posts a comment under your pull request that says, Hey, thanks so much for contributing. Really appreciate it. Could you please open an issue in a human voice, no longer than a screen's worth of text. And if I like it, I type looks good to me. And then that account name gets put into the file. And the next time this in the pull request, they pass. And it turns out agents don't receive the comment my GitHub workflow posts underneath the pull requests. So this is a great filter for filtering out agents and keeping the humans safe more or less from. That's interesting. I wonder if this might be the, like an unavoidable future where like we just need, we need a way to separate, is this coming from a human with an intent or an AI? I don't necessarily care if, if it were actually a good PR, then if it came from a machine is it's actually fine-ish. I think what's interesting in PAI is like an OpenCL even more so is like it accumulates pull requests. Well, actually there was no intentionality behind it at all. And so the, the person that dispatched the machine didn't actually care that much about it or didn't even know about it or didn't even know about it. And I've done open source for many years and there was also, there was a, there was a big difference between someone sending a pull request up or like an issue. I was like, hey, please fix this. But actually didn't care enough to even reply to questions anymore. Like this is, this is not uncommon. And then you don't actually have to fix that. But you have to close it out because like maybe it's still useful input, but like it, clearly that person wasn't caring enough. And with the pull request is even worse now because they come in so quickly, that many of them cannot be merged anyways without manual resolution of the conflict. And there's a lack of back pressure mechanism. Because even I as a human, if I see there's like 500 pull requests open, I was like, I probably will not contribute to this thing now because at the worst I will make it worse. And I think previously in open source, you had the people who would just send issues and be very entitled and say, you're the worst person on the planet if you don't fix my little issue, but that's fine. That can be handled. And pull requests were kind of special because it needed a human to invest quite a bit of time to produce them. And you don't have that anymore. You just have people, oh, this should be easy. Agent, please do this thing. Make no mistakes. Send it to this repository. And that's just not going to happen. So basically what we need are bottlenecks. I'm not necessarily, I don't necessarily need human verification or a verification that you're a human. I just need a bottleneck that allows me to process the amount of incoming things as a human. Because in order for PAI to not deteriorate into a pile of garbage, I still believe that it needs me and other capable people reviewing at least the important code. And for that I need bottlenecks because otherwise I can't deal with it. It's the second law of thermodynamics, right? It's like everything degrades towards chaos and you have to put extra energy into, to keep it away from this. But you mentioned friction in the software. You didn't say tech debt. You didn't say complexity. What is this friction? Because I don't remember us talking about this pre-AI at all. So I found this ironically kind of funny. And it's kind of sad because I will not name any names, but there was a, what I assumed was an incident related at least in part to the engineering on a company where they shipped out a configuration change that ultimately resulted in a security issue. And look, things happen. But the link that I saw on this had the social preview of that company's tagline. And the tagline was ship without friction. And that really gave me pause because I know as an engineer, like we used to talk about like, you've got to get rid of like all the things in the way so that you feel happy shipping stuff. But there, there always were changes where you really wanted to think, like, do you want to drop the database? Like, do you wanna merge this migration, which might take a table lock that could potentially take you down, right? It's like there's, there's these moments every once in a while where you really, you are really supposed to think and people created checklists or people created, like, like mechanical gates that would, where you would have to confirm something. Like there's, there's certain things that we used to put, particularly if you run a SaaS company, did you put stuff in so to slow things down. Or in, in in some of the best engineering teams, in order to mature a service, you have to define an SLO. You have to define like expectations. And like, if, if your service is supposed to be critical, but like there's some other stuff that unlocks on the sort of tree of requirements. And a lot of engineers feel like, oh, this is all this bureaucracy. But like the reality is like, if you do this correctly, then it saves you time and it's like, it makes you happier. You're not waking up at three o'clock in the morning. Like all of this is useful. It's like friction injected to deliberately slow things down. Like it's the easiest example in any decent sized company. You have services based on tier, based on criticality. The highest tier software now needs to have, let's say two or three code reviews or an approval from a director to do a configuration change, which again, all slows down, but it's kind of like, we know that this is on purpose. Like by adding this friction, we want you to think, do I want to pursue this friction in terms of time invested or effort or having to justify things, et cetera. It makes you think about, do I really want to add this to the code base if I know that the end effect will be that it has to go through this entire chain of queries. So it would be coming back to saying no to yourself to avoid pain going through that process. And then taking on the pain when you know that you have the conviction, you have the backing. You have the confidence as well, right? Like, so typically when it's a higher friction thing, let's say a tier 1 service or a highest tier service where a director have to sign off. When you're a new joiner on the first day and you don't know the context, you probably know that that's a pretty large ask and you'll probably socialize, get buy-in from a, from an experience and say like, oh, this is the right thing. You'll go with them, right? Back to human dynamics a little bit. And you see, the thing is, like you see, there's a, there's a very delicate balance in the whole thing because like you don't want the friction to be just an accident of having created bad developer experience, right? But some things look the same. And, and, but they, but they were deliberate, but they were maybe not sufficiently documented. But, but there's this feeling now, like get rid of all the friction so that the agent can be very autonomous so that they can run many of them simultaneously. A lot of it comes from that. It's like, I, it's like it, it, these things are actually rather slow. And the only real time saving that you get from it is parallelism. And so somewhere there is, is this trap. I feel like a little bit more experienced now in managing the trap, but I, I don't have the solution for that either. And I, I will not like say that is an example codebase where I felt like really, really great about the stuff that I built, except for pre-existing libraries from before a Gantic days where, where I still feel like a strong emotional attachment to them. And I'm much more careful about doing them than, than any of the code that we, other empire, to which I don't have access. Oh no, there's, there's still no write access. Um, there, there's a lot of slop in Py, but I try to avoid it in the, in the bits and pieces where I know that's important code. Like we have an HTML export functionality where it takes the current session and just spits out an HTML file that you can then host on GitHub and whatever. I have not looked at a single line of code for that function. I don't care if it's broken, if it looks right when it comes out. But then, then there is the, the agent loop itself or the, the extension loading mechanism and all of that stuff. And that's important. And the way I deal with. Because if you compose it together there, and I think like one of the things is also like kind of underappreciated and sort of if you see, particularly if you see Pi do this stuff, because it's kind of transparent of the tool cost that it does, it's kind of magical at times, like how creative agents get large outputs. Like for instance, Pi, when it runs a program in BASH and it produces too many lines of code, it actually only reads, I don't know what the cutoff is, but it reads the first couple and it's like, oh, if you want the rest of the file, it's 20 megabytes large and it's in this file. And then the agent is like, oh, 20 megabytes, that's too much. I'm going to grab on that file. Right. And they get really ingenious in how they're interacting with it. And like, and MCP takes that away. The question is like, how how would you define MCP in a way where it wouldn't take that away, where it still has all of that magic and, and capability and, and I don't really know the answer because I think it's hard, but off needs solving and and composability needs solving. And I think there is a bright future of that kind of stuff. And also like what Mario said, if coding agents wouldn't have become so popular, then the idea of code generation, code running for like non-code related problems probably wouldn't have taken off quite as much too. But like the most capable personal agents, OpenFlow being a good example of it, they're just coding agents hidden from you. And then that just naturally, some random person who is not a programmer is going to say, how am I going to do this? And the model doesn't say like, install this MCP. The model says like, okay, I can write a Python script that does it. And so you naturally have this in the sort of the crazy space. You have the adoption of, of more code execution and the compliant enterprise space. You, you don't have that. That's a different path that case. And I personally don't think that models are going anywhere else other than code generation going forward for any kind of a genic task. I think that's, that's mostly a function of there being a lot of training data for code generation and code generation being a very easy means to control computers. So I don't see a different paradigm there coming out of the model labs anytime soon. So I think taking that as the assumption where the future is going, we just need to figure out how to make code generation kind of work within an enterprise setting with all of the other enterprisey things that entails. So let's do a fun trying to predict a year out, which is hard, but in 2027, knowing some of these basics, just again, from first principles, where do you think these coding agents might be and the software engineering workflow might be? You know, basically this is just like, again, speculation. We know we cannot predict the future, but where do you think that there'll be a lot of focus in the coming year? And we might in an optimistic case, see some results and, and tools and how we work and what's working, what's not working. I have no idea. Honestly, I have no idea. I could make up something that's probably not gonna happen. I think the self-mailability thing is obviously something I believe in. I think we will see more of that. Including the tools themselves with which we build the software. And I think that will expand, not only to the tech sector, but also to non-tech applications of e-agentic tools. Is it dog years with your time 7? Is that how it works? So that's, that's basically the model I have right now of like how this stuff works. It's like when you ask me like, what's going to be in a year, it's like seven years, right? And to me, that makes it incredibly hard to have any sort of predictions about the future because like, it's still not one year. Maybe now it's one year from like people starting to use in cloud code, but it feels like it is much, much longer, much more, more time behind. And more time has passed. And, and I think like right now that the closest that I can imagine is going to be like, we, we, we know that code execution and code generation and like this harnessing around it. This is, this is going to be it because reinforcement learning gets more of that data. And my, my strong hypothesis is that as more and more people are starting to wake up to this, you can do interesting things with agents. There will be a societal recognition also of how much more dependent you are on basically two companies. And I think we'll have a conversation about that part. We should have a conversation about that part, particularly as Europeans, because we don't really have these labs over here. And so I hope we have that conversation, but like my, my best guess is that we'll wake up to the fact that we are now, I mean, engineering teams already now telling me that they have code bases that they think they couldn't maintain any more with a hot machine. My guess is that one of those companies will be public and, and expensive. And I think that might actually dominate or at least become a conversation that's much bigger than the question of, are you using Pi or using cloud code?