Pi has launched a brand-new Agent Harness, and has integrated the MCP that it has been criticizing for a whole year into its core.

Pi has received its largest update of the year: the project has been upgraded to version 1.0, with Code Mode and native MCP officially entering the stable release. On the same day, the team also launched a brand new Harness called Pi Durable.

These changes have been in the works for some time. Over the past year, the MCP protocol has gone through six or seven rounds of adjustments, gradually evolving to a truly usable stage; the architecture of Pi Durable has also undergone eight iterations in total. A protocol that was once publicly rejected by Pi has entered the core, and a repeatedly polished long-running Agent framework has been unveiled at the same time, marking that Pi has begun to extend from a terminal programming Agent to a complete Agent infrastructure.

For developers, the most intuitive value of Pi Durable is that it eliminates a large amount of duplicate code. In the past, when building personal assistants, Slack Bots or other Agent applications on Pi, developers needed to design their own databases to store messages, and then handle Agent startup, task scheduling, process crashes and state recovery. Some developers estimate that Pi Durable can directly replace half of their code, as all these peripheral details are taken over by the framework.

This also explains why some people believe that Pi Durable will become the foundation of many Agent workflows and applications. In the past, every company was repeatedly implementing conversation records, task persistence, fault recovery and session branching, and Pi Durable exactly fills this gap. It saves user messages, model responses, tool execution results and task status; after a process crashes, the Agent can continue from where it was interrupted. Operations that can be safely replayed will be re-executed, while operations that may produce duplicate side effects will not be rashly re-run.

Mario Zechner summed it up very simply: the Agent starts, calls tools, and the process suddenly crashes; after restarting, it should continue exactly from the original position, without the user needing to type "continue" again, and tool results and streaming output must not be lost. Armin Ronacher pays more attention to the reliability behind it: the model itself is already unpredictable enough, and when the Agent starts to break away from real-time human monitoring, the outer layer of task orchestration and fault recovery should at least be stable and understandable.

Another controversial change comes from MCP.

Over the past year, Pi founder Mario Zechner and Flask founder Armin Ronacher have been the most outspoken critics of MCP. Pi's official website even once proudly stated that "MCP is not supported". They publicly criticized MCP for being bloated and wasting Tokens, and argued that Agents using Bash, CLI tools and code are often more efficient.

Now that models have received more MCP-related training, and MCP Server and the protocol have gradually matured, Pi has finally decided to officially integrate it. Instead of stuffing all tool names, parameters and descriptions into the context at once, it loads them on demand through tool search and progressive disclosure.

Code Mode, which entered the stable release together with MCP, allows the Agent to write and run a piece of JavaScript program in the QuickJS sandbox. It can call tools in parallel, filter data, deduplicate and perform calculations, and finally only send the truly useful results back to the model. A large amount of intermediate data remains in the sandbox, thereby reducing Token consumption, operating costs and context burden.

Code Mode also has a very interesting capability: it can directly call the System 1 model, such as Jev, inside the JavaScript loop. Suppose Pi obtains 200 GitHub comments through MCP, Code Mode can pass them one by one to Jev to judge whether the user is dissatisfied, whether the problem is urgent, and which category it should be classified into. GPT or Claude only needs to see the classified and summarized results in the end. MCP is responsible for acquiring data, Code Mode is responsible for orchestration and processing, Jev undertakes a large number of quick judgments, and cutting-edge models focus on high-level reasoning.

But some Pi users are not happy. One person commented: "So Pi is starting to pile up junk now." This sentence represents the concern of the minimalist camp: as MCP, Code Mode and more capabilities enter the core, will Pi slowly become the bloated Harness that it tried to avoid in the past?

Armin responded that the content loaded by Pi by default has not increased compared to before. Code Mode is not "Bash in a roundabout way": Bash runs Shell tools, while Code Mode allows models to directly search, combine and orchestrate tools inside the Harness. Pi has embraced the MCP ecosystem, while still controlling the burden it brings to the context.

Interestingly, while the Pi team is letting Agents use more tools and run for longer periods, they still do not dare to hand over all the work to it. Mario admitted frankly that Agents can fix many small problems, but when it comes to design and architecture, they often only stack code locally, "dropping a pile of shit into your codebase and making the situation worse".

When Agents can finally cross crashes and run continuously for hours or even days, new problems also emerge: they will not stop easily, but who will guarantee that they do not turn the codebase into a mountain of shit along the way?

Recently, Mario Zechner and Armin Ronacher talked in detail on a podcast about the design of Pi Durable, the capability boundary of AI programming, and why Pi does not want to only be a programming Agent in the future. InfoQ translated and organized this conversation, and the following is the edited full content.

TL;DR

Q: Why not let Coding Agents fix bugs?

Armin: Because it is almost impossible for them to solve the problem without touching the code. The more you trust the fully automated process, the more the codebase will grow naturally with each bug fix.

Q: Is the code written by AI usable at all?

Mario: It depends on the level. A lot of stuff in Pi's TUI library is pure slop, and I haven't read a single line of code for the markdown component and text component to this day. I don't care, as long as the tests pass and the rendering is correct. But when it comes to design or architecture, humans still have to take charge, because Agents will only "drop a pile of shit in place" in the codebase and make things worse.

Q: Has the model's architectural capability improved at all?

Armin: No, it might even have regressed. The outputs they produce are getting more and more complex, the way they speak is getting weirder, and they are full of technical terms pulled out of the thesaurus.

Q: Why can't models learn architecture?

Mario: Because architecture is the only part of programming that has not been encoded into text, so LLMs cannot learn it. You can easily build training data for cybersecurity, building websites, and front-end development, but the process of "building" itself, that is, the process of designing and architecting something, has no training data.

Q: So what tasks can models do exceptionally well?

Mario: Tasks that have an Oracle, are binary, and can be fuzzed. If you have an Oracle that can tell the LLM whether what it did is right or wrong, you basically win. The Rust rewrite of Bun was done exactly this way, just get the test suite running.

Q: What exactly is Pi Durable?

Mario: The Agent starts in the process, calls tools, the process crashes, restarts, and continues exactly from the breakpoint. But Pi Durable does not do event sourcing, it uses an "intent, execution, result" effect sandwich, plus versioned document storage to hold application state.

Q: Is the personal Agent thing reliable?

Armin: Millions of people are using things like Grok Bot, logging everything into machines, and I think that's a disaster, all these companies are heading for a disaster.

Q: What does Earendil want to do next?

Armin: We don't want to be a Coding Agent company. There are two lines: one is to build products that even non-engineers can have fun with; the other is to build infrastructure that allows everyone to build their own Agents.

Q: What is the future direction of Pi?

Mario: I've been working on PIM (Pi Mobile) on my phone recently. It's no longer just "me and Clanker", but many Clankers on many machines, talking to many people.

Agents Can Fix Bugs, But They Also "Drop a Pile of Shit" Into Your Codebase

0xSero: Why did you decide to bring Pi on board?

Armin: Actually, before we brought Pi on board, we tried for a long time to bring Mario in. After the OpenClaw craze, the opportunity came, and Mario became open to it. We are working on "malleable software", and Pi is a very good version of early experiments in this area, so it makes perfect sense to bring it in.

Mario: I'm an idiot for building Pi, now I'm stuck here farming.

0xSero: Do you really feel trapped by this project? It's so successful, it doesn't make sense to shut it down.

Mario: Like Armin, I also have a long open source history, we just come from different fields. Once an open source project I made has users, I will foolishly maintain it for everyone, even if they don't pay a penny. Sometimes, the negative feedback is really draining.

However, my current goal is not to hand Pi over, but to get more people involved in Pi's development, so that the "must have me present" factor is reduced. We have achieved this goal quite well so far, even if I die tomorrow, Pi will still be in reliable hands.

0xSero: Speaking of finding contributors, what changes have there been in this area? More and more people are starting to use AI. I know you used to dislike people slapping together a bunch of AI code casually. How is the experience now?

Mario: It's bad. To put it another way, if I hadn't spent most of my time from February to around July maintaining Pi, checking and fixing issues, Pi Durable could have been released much earlier.

The problem is that Agents can't help you fix issues right now, at least not for my project. I don't trust Agents enough to let them judge which reported issues are really worth our time and need to be fixed. So at the very least, I still have to go through all the submitted issues myself.

Can Agents fix issues? Of course they can. The key is how well they fix them. Many problems can indeed be handed over to Agents, especially very small ones. But as long as design or architecture is involved, human participation is still required, because Agents often only drop a pile of shit in a local part of the codebase and make the situation worse. Right, Armin?

Armin: The problem with Agents is also that they will definitely solve the immediate problem, but it is almost impossible to fix it without adding code. This is actually very strange, because after many problems are fixed, the net amount of code in the codebase should not increase.

Of course, it's ironic coming from me, because I often submit PRs that modify 200 files at a time and add 20,000 lines of code, which is terrifying. I myself am a victim of abusing "clanker" (a nickname for AI). But software should not evolve like this. Especially a codebase that is fully automatically maintained, it will almost inevitably keep bloating with every bug fix.

When Is AI Slop Code Acceptable

0xSero: DHH has completely dived into this way of working of "AI slapping code together". I call my own work "slop operations", because I basically use models for everything. To some extent I do feel much dumber than before, but on the other hand, the efficiency is extremely high. If your job is not to build something that will be copied and used by millions of people, I don't think there's any harm in slapping a script together. For example, what I've been doing recently is creating Docker containers for specific hardware combinations, so that the model can run optimally on some random VRAM and RAM configuration. This trick works really well, design and architecture are not that important, as long as the result can run and do what it's supposed to do. But you guys don't have that privilege, you're building things that will be used by millions of people.

Mario: Of course we do. A lot of stuff inside Pi is pure slop. The only difference is at which layer you let humans intervene, at which layer you trust the Agent to produce usable things, and don't care how exactly it implements it.

For example, Pi's TUI library, the original design was handwritten by me for another project in early 2025. That design was quite robust and minimalist, I knew it would most likely hold up to real world contact, even if it wasn't perfect, it was good enough. But when I actually started building Pi, I didn't go in and say "write me a markdown component, write a text component, write an editor component", I directly told the Agent: here's the API, write against this API, build all these components for me. I don't care what they look like, as long as they run, and there are a bunch of tests to ensure correct rendering, I don't care about the rest.

To this day, I haven't read a single line of code in the markdown component or text component. I don't care, it's not important. The only time I care is when performance drops. And at that point, Agents are very good at identifying a bunch of problems, but they are very bad at coming up with a generalized solution. They will go in and fix a local thing, making that one edge case perform better, but they won't think from the big picture, they won't identify the fundamental problem in the architecture itself that makes the whole thing slow, which in turn gives rise to that slow edge case. I think that's roughly where I still have value right now.

0xSero: I remember your process, like creating interfaces, playing with APIs, trying to build a feel for what you're going to build first. Has that process changed?

Mario: No.

0xSero: Models have gotten a lot better at doing things overall, but at the architectural level it's still messy and no progress, have you noticed anything different?

Armin: Sometimes I even think they've gotten worse. More precisely, they might actually be a little worse at architecture. The end result getting worse could also be because we're giving models more control. Almost every time a new model comes out, I build something with it, and I'm getting less and less satisfied with the results of them working independently, mostly probably because I trust them more than before.

The models themselves might still be improving, but when you factor in my expectations and usage patterns, the net result has actually gone down. Every time I make the model write a game in C, because I used to love writing C, that's my standard test. I feel like they're getting worse. It could also be that I'm putting less attention into it, but at the very least, the results are not getting noticeably better.

0xSero: It's not the way they build things, but the way they communicate with us has gotten weirder: the way they speak is getting more and more complex, using way more technical terms, and drilling into all kinds of weird niche technical topics in their responses.

Armin: But Opus has definitely gotten better.

Two Codex Accounts Cracked My Software

Mario: Fable 5.x versions, and the previous Opus, I completely stopped using them for a while because of the way they spoke, every word looked like it was freshly pulled out of a thesaurus, it was unbearable, Astra was bad too. But I'm pretty happy with Sol 6.1 and Opus 5.5, they toned that vibe back down, now they're acting like normal machines.

There is one improvement I did feel, in cybersecurity. Last year, I used Clanker to harden some desktop software, and it didn't work at all back then, it had no idea what was going on.

This year, a Chinese person used two Codex accounts to crack this piece of software. Then I used a "reverse engineering clanker" to replay the attack and figure out how he broke through the software's defenses. The whole process was absolutely astonishing. No human reverse engineer on earth could go that deep, let alone finish it in that short amount of time, it's crazy.

To get a little more low-level: