Pi Coding Agent: Building Flexible AI Tools for Real Workflows

Introduction

Code is never free. That is the central argument Mario Zechner, creator of Pi, makes when discussing the state of AI-assisted development in 2026. While agents can generate vast amounts of code quickly, the consequences of that code eventually catch up with you. Pi exists because Zechner found that existing coding agents did not fit his workflows, and rather than adapt, he built a tool that adapts to him instead.

This conversation covers why workflow stability matters more than feature velocity, how to actually work with coding agents without burning out, and why the industry may be repeating a 30-year-old mistake with spec-driven development.

Why Pi Exists: Workflow Flexibility Over Stability

When Claude Code first launched, Zechner was happy with it. Over time, however, the tool’s high-frequency release cadence became a problem. Claude Code receives one to three updates per day, and with each release come changes to tool definitions, system prompts, and underlying behavior. For someone who builds custom prompt templates, slash commands, and workflow descriptions, these invisible changes break things.

The model itself seemed to behave differently day to day, even though the model version remained the same. Zechner attributes this partly to changes in the “harness”—the infrastructure and system prompts that shape how a model responds. Testing the effects of harness changes on output quality is difficult because there is no deterministic way to measure it. The result is that developers like Zechner cannot rely on the tool to behave consistently, which defeats the purpose of building custom workflows around it.

Pi was born from this frustration. It is a minimal, extensible coding agent that can modify itself to fit your workflows instead of forcing you to adapt to its constraints. The underlying architecture abstracts away LLM providers, includes a terminal user interface library, and provides general agent loop abstractions. But the key difference is control: Zechner dictates the design and can change it without waiting for a vendor’s release cycle.

How Pi Actually Works: Parallel Processing and Manual Review

Zechner’s day-to-day workflow with Pi is methodical and deliberately low-tech. He does not run an army of agents in parallel. Instead, he uses a caveman approach: queue up multiple sessions, each analyzing a different issue from the tracker, then review and iterate on each one.

For bug fixes and feature implementations, the process starts with an issue description. Zechner feeds the issue to an agent with a custom prompt template that says: pull all relevant information, ignore the analysis in the issue, and do your own analysis based on what we want to achieve. This analysis step takes about five minutes per issue. He opens a second session for the next issue, a third for another, creating a parallel pre-processing pipeline.

Once the agent finishes analyzing an issue, Zechner reviews the suggestions, checks the code himself, and reproduces problems manually if needed. He uses the agent as a rubber duck—a thinking partner—until he agrees with himself on the implementation approach. By the time he tells the agent to implement, the context contains so many guardrails that the agent knows exactly which interfaces to modify, which modules to touch, and how tests should work.

Implementation takes another 10 to 30 minutes. When the agent signals completion, Zechner pulls up a diff viewer and annotates individual lines with feedback. He clicks finish, the feedback feeds back into the agent automatically, and iteration continues until the code is good. For core mechanics, he reviews every change as he would with a human. For other pieces, he approves without deep inspection.

This workflow works because Zechner has 10+ years of experience in code bases. He knows what works and what does not. For new developers or those without that experience, the approach would be different—and riskier.

The Reality of Spec-Driven Development

The industry is repeating a 30-year-old mistake. Waterfall development was proven to be ineffective decades ago, yet with AI agents, we are back to hyper-waterfall: writing detailed specs and having agents implement them. The only difference is that now you do not even write the spec yourself—you vibe prompt an agent to write a very detailed spec, which then another agent implements.

The problem is fundamental. A complete spec is essentially the program itself. If you write a spec in natural language prose, you are leaving gaps. The agent fills those gaps with whatever patterns it learned from 20 years of code on the internet—much of which is garbage. The result is a code base that looks like vibe-coded software, because it is.

There is a counter-argument: code is now cheap, and iteration is fast. Previously, a waterfall spec might take months to implement. Now it might take a day. You can test your way through it manually. But Zechner has yet to see evidence that this actually works for production software. He suspects that eventually, developers will wake up at night realizing everything is broken.

That said, there are constraints where agent-driven development makes sense. Bun’s rewrite from Zig to Rust worked because the project had an extensive test suite. The agent could verify its own work to some extent. In those cases, tools like this are genuinely useful. But for most software, the approach is risky.

Managing Open Source at Scale: The Clanker Problem

Before agents, a successful open source project might receive one or two pull requests per week. Pi now receives 50 to 60 pull requests per day—all from agents (Zechner calls them “clankers”). Each PR has a description like a full Harry Potter book and includes 10 to 1,000 file changes.

The default position is to declare every agent-generated PR garbage and auto-close it. But Zechner found a solution: require people to first write an issue in their own voice, no longer than a screen, explaining exactly what they want to do and why. If the issue is good, he approves it and the person can send a PR. This proves they are human, they understand the problem, and they understand the solution.

Once approved, meaningful PRs come through. The clanker PRs stop appearing. Issues still flood in, but Zechner triages them manually. He reads through 30 to 60 closed issues per day, identifying which are legitimate and which are garbage. In his last triage run, 50 issues came in and 2 survived. It takes about 30 minutes because most are quick to identify as noise.

For projects at the scale of OpenClaw, this manual approach does not work. Peter Steinberger’s token consumption reached 1.3 million dollars per month partly because automating issue and PR filtering at that scale requires sophisticated infrastructure. Zechner wrote some visualization tools to help cluster similar issues, but even that was not enough. The volume is orders of magnitude larger.

Local Inference and the Future of Smaller Models

Zechner is optimistic about running capable AI models locally on consumer hardware. For his robot project—a toy with a smartphone as the microcontroller running a coding agent—he uses Gemma 4 and Qwen 3.6, smaller mixture-of-experts models. They are more than adequate for a chatbot with motor and camera control, and they are fast.

The setup is affordable. Speech-to-text with Parakeet takes about 10 gigabytes of unified memory. Text-to-speech with Qwen TTS takes another 10 gigabytes. Qwen 3.6 takes 4 gigabytes. Total: 14 gigabytes of unified memory on macOS or an equivalent NVIDIA setup on Windows. That is affordable for many people, not the entire world, but a significant portion.

Denise Asaves from DeepMind has suggested that current giant models do not need all their parameters and can be distilled down to much smaller models without losing much output quality. Zechner’s hope is that the future involves distilling large models into smaller ones that retain most capabilities, rather than training specialized models for specific tasks. Antirez from Redis has started working on a custom inference engine for DeepSeek V4 called ds4, running it on a 128-gigabyte laptop. It is a really capable model that could handle 60 to 70 percent of the issues Zechner handles with Pi.

The Cost of Code and the Discipline of Craft

Zechner has seen people generate 500,000 lines of code via agents in a week. The outcome is always the same: disaster. Code is never free because the consequences eventually hit you. If you think any amount of code is good now, you have just delayed the punishment.

The real bottleneck in software development is not typing speed or code generation. It is thinking, designing, and exploring the solution space. Agents are genuinely useful for that phase—you can tell multiple agents to explore different approaches and see the results faster. But the output of those explorations is not automatically reusable. You still need to understand it, refactor it, and maintain it.

For Zechner, the biggest productivity increase from agents comes from the asynchronous nature of work. He can give an agent a task, go to a meeting, and come back to results. But he does not believe running 10 agents in parallel will 10x his output. The context switching alone is exhausting. He has done it once or twice a month, processing 30 issues in a day, and his brain is mush afterward.

The collaborative aspect is what he values most. Having an agent as a pair programming partner—asking questions, proposing options, explaining code—is like a bicycle for the mind. It helps him think through problems better than sitting alone. But that requires discipline: not delegating everything to the machine, because every time he does, he ends up in a corner crying because nothing is good anymore and everything falls apart.

Refactoring Pi: Building for the Future

Pi has accumulated historic baggage. Parts of it predate Zechner’s use of agents and are solid. Other parts, like the HTML export, he has never looked at and does not care about as long as it renders. Some pieces are vibe-coded.

The refactoring effort has several goals. First, expand into other types of user interfaces more easily—web, native, whatever—without breaking existing extensions. Second, enable remote ability: run one Pi session on one machine and connect to it from another, with proper durability and observability. Third, make Pi’s SDK deployable on Cloudflare Workers, Vercel, and other environments, not just local computers with bash.

Zechner is refactoring on the main branch because he does not care about stability in the traditional sense. He is doing it piece by piece, starting with the lowest-level packages that talk to LLM providers. The coding agent itself will still look and work the same, but all the underlying infrastructure will be clean and reusable. He hopes to finish that phase in a week or two, then spend a few more weeks on the new extension mechanism where extensions have server-side and UI-side components.

Why Pi Runs in YOLO Mode by Default

Pi does not ask for permission before executing code. This is intentional. By telling people that YOLO mode is dangerous and they should think about it, Zechner actually makes people think about security. He wants them to look inside themselves for security awareness and decide how to safeguard agentic work in their own environment.

The answer is usually containerization. If you do not want the agent to break your computer, containerize the agent or the tools it uses—file read/write, bash, whatever. That solves the problem. But Zechner cannot decide this for you. He could bundle Anthropic’s sandbox or bubble wrap, but these are incomplete solutions. In an enterprise environment with specific infrastructure constraints, a built-in sandbox might not work at all.

What exists in Claude Code is mostly security theater. Claude Code now asks an LLM if a bash command is safe before executing it in auto mode. Zechner does not think that is good. An LLM cannot reliably determine if a command is safe—it can only guess based on patterns.

Conclusion

Pi represents a different philosophy: build tools that developers can own and modify, not tools that own developers. The success of Pi is not measured in features or benchmarks, but in whether Zechner can keep a small team alive and continue exploring applications of agentic work—from coding to robotics to local inference.

The broader lesson is that workflows matter more than hype. Stability, predictability, and the ability to customize your tools are worth more than the latest feature. And code is never free—the consequences of your actions will eventually catch up with you.