Pi Building Pi — Openclaw's Minimalist Coding Agent

Mario Zechner traces an unconventional path through tech: from writing computer games to machine learning research, through startups, building compilers for iOS (RoboVM, later acquired by Xamarin/Microsoft), and eventually landing in the AI agent space.

The turning point was discovering GPT's capabilities and realizing that a minimal coding agent could be built that leverages the model's existing knowledge rather than wrapping it in heavy tooling. This led to Pi — a deliberately minimalist coding agent built under the Openclaw umbrella.

"I've been doing this long enough to know that the simplest thing that works is usually the right thing."

Mario identifies two camps in the agentic coding world: the "dark factory" vision of fully autonomous agents, and the human-in-the-loop approach where agents serve as powerful tools under human oversight.

He's firmly in the human-in-the-loop camp, and lays out why dark factories fail in practice:

• Errors compound — each autonomous step has a failure probability that multiplies across steps
• Code on the internet is generally not high quality — models trained on it inherit that mediocrity
• Specifications always have blanks — only a human can fill in the gaps of intent

"Slow the f*** down. We're not there yet. And pretending we are is how you end up with a codebase you can't maintain."

Mario draws a sharp distinction between building a product (heavy frameworks, MCP integrations, complex tool registries) and building a harness — the minimal scaffolding that lets the model do what it already knows how to do.

Pi's philosophy:

• Four core tools: bash, read file, write file, edit file — that's it
• No MCP — GitHub CLI works perfectly fine and wastes zero tokens on protocol overhead
• Models already know what a coding agent is — they've seen every coding agent tutorial in training data
• Self-modifiable — any missing feature can be added in 10 minutes via the extensions system

"Why would I build an MCP integration when the model can just use gh cli? Zero wasted tokens. Zero extra abstraction."

Mario does a live demonstration of Pi fixing its own bugs — the namesake concept of "Pi building Pi." The workflow showcases several key features:

• /issue prompt template — fetches and analyzes GitHub issues, auto-assigns labels
• Multi-session workflow — custom UI extension shows issue metadata across parallel sessions
• Bug analysis — Pi identifies bugs in both compaction implementations, runs npm checks
• /wrap prompt template — one command to commit, push, update changelog, and post a GitHub comment

The demo illustrates how prompt templates replace complex tool integrations — they're just structured prompts that chain existing bash tools together.

A nuanced discussion on when to let the agent run autonomously vs. when to review every change. Mario's framework:

• /wrap (fire-and-forget) — for simple, well-scoped bug fixes where the fix is obvious
• /implement (review first) — for refactoring, new features, or anything touching architecture
• Gut feeling from experience — knowing that GPT sometimes over-engineers simple fixes

Mario describes "caveman mode" — actually reading the code the agent produces, not just the summary. He catches unnecessary abstractions and function extractions that the model adds "for cleanliness" but which actually hurt readability.

"If the model extracted a three-line fix into a helper function and two constants, that's not cleaner. That's the model performing for you."

Mario walks through Pi's AGENTS.md file — the system prompt that defines how Pi should behave in the codebase. Key design choices:

• Star Trek computer style — communicate like a helpful computer, not a chatty assistant
• Adversarial model — "roast me" section instructs the model to challenge questionable user requests
• Code quality rules — no inline imports, consistent naming, but these are suggestions the model often ignores
• npm run check after every change — models never forget this because it's RL-trained behavior (deterministic checkpoint)
• Security section — dependency pinning rules, no wildcard versions
• Git rules — conventional commits, branch naming
• User override with confirmation — if the user asks something that violates AGENTS.md, confirm first

"Style guidelines? The model ignores those half the time. But 'run npm check'? Never forgotten. Because that's a concrete, verifiable action — it's RL reward territory."

Mario raises an alarming observation: 100 agents in 3 months can generate 1 million lines of slop compared to 100,000 lines from human developers in the same timeframe. The 10x throughput increase is real — but it's 10x volume, not 10x quality.

He describes friends who are deeply unhappy with their codebases after three months of heavy agentic coding. The solution isn't to stop using agents — it's to:

• Refactor ruthlessly — treat agent output as a draft, not a final product
• Use agents to help refactor — they're excellent at mechanical restructuring under human guidance
• Set architectural boundaries before the agent starts — containment beats cleanup

A fun tangent: Mario built a physical robot using Pi as the brain. The hardware setup is charmingly scrappy:

• $9 toy robot — with "violence applied" to rip off its original head
• Phone as sensor — camera, microphone, accelerometer
• Pi as the brain — voice control, photo taking, 360° environment scanning

The entire project took 12 hours and was 100% vibe-coded — Mario never wrote a line by hand. He demos the robot responding to voice commands and scanning its surroundings.

"$9, some violence, a phone, and Pi. That's the whole robot."

The robot's codebase is the perfect case study for refactoring agent-generated code. The client is a 1,300-line single file — pure vibe-coded slop.

Mario demonstrates a methodical refactoring approach using Pi:

• Code structure analysis first — ask the agent to map dependencies before touching anything
• Dependency analysis before refactoring — understand what's coupled to what
• Propose modularization — split into robot-server, tool modules, shared types
• Custom /comment extension — opens the agent's last response in an editor, lets Mario annotate inline, feeds annotations back as the next prompt

This demonstrates the collaborative exploration pattern — human and agent iterating together rather than the agent working autonomously.

Mario explains Pi's extensions system — the mechanism that makes the agent self-modifying. The /comment extension is the running example:

• 50 lines of code — opens the last response in the user's editor, user adds inline annotations, feeds them back
• Built by Pi in 5 minutes — Mario described what he wanted, Pi implemented it
• Mario never looked at the code — it works, that's enough for a workflow tool

The deeper principle: "I don't always know what I need, so the agent can write me that feature." Extensions turn Pi from a fixed tool into an evolving workflow that adapts to the user's emerging needs.

"If you realize the models can modify the software they're running in, you will have a lot of fun."

Mario shares two distinct strategies depending on codebase familiarity:

• If you know the codebase: tell the agent exactly which files and functions to look at — don't waste tokens on exploration
• If you don't know the codebase: use the agent as a "research intern" for initial exploration — progressive context gathering with follow-up questions

The key technique is session tree branching:

• Open one session branch for exploration/analysis
• Summarize findings at the end of that branch
• Take the summary to a fresh implementation branch with clean context

"It's the caveman version of sub-agents. But I can see everything, and I can ask follow-up questions."

A pointed critique of the sub-agent pattern that many coding frameworks are adopting. Mario's objections:

• Can't see what sub-agents are doing — opaque execution is the opposite of human-in-the-loop
• Can't verify what they ingested — you don't know what context influenced their decisions
• Can't ask follow-up questions — the conversation is one-directional

Instead, Mario uses collaborative exploration in the main session, then branches off for implementation. It's more manual, but fundamentally more transparent and more controlled.

Mario's view on what engineering looks like in the age of coding agents — it's about taste, boundaries, and knowing where NOT to trust the model:

• Don't let non-experts ship code — a product manager with Cursor is not a software engineer
• Define module boundaries upfront — even if the modules contain garbage internally, isolation makes replacement easy
• Architecture is the irreducible human skill — models can't see the whole system and make coherent trade-offs

"Don't let it happen in the first place. It's way easier to define boundaries than to untangle a codebase that grew without any."

Mario closes with characteristic humility and enthusiasm:

"I also don't know what the best way is. This is the way that works for me."

He encourages experimentation — there's no single correct workflow for agentic coding. The field is young, the tools are evolving, and the best practices haven't been written yet.

On model preferences: GPT 5.5 for code (95% of the time), Claude for prose, with open-weight models like Qwen and DeepSeek becoming increasingly viable alternatives.

"This is an amazing time to be a technologist. If you realize the models can modify the software they're running in, you will have a lot of fun."