Building pi in a World of Slop — Mario Zechner

Mario Zechner’s case for pi begins with genuine enthusiasm for Claude Code. He describes its early appeal as a combination of simplicity, predictability, and compatibility with his workflow. As the product accumulated features, however, he encountered more breakage and a deeper problem: the harness, rather than the developer, controlled what entered the model’s context. Changing system prompts, shifting tool definitions, and inserted reminders could alter behavior across releases and disrupt established workflows. 0:15

For Zechner, context ownership is inseparable from reliability. He argues that unexpected reminders can confuse the model, while limited observability makes it difficult to understand what an agent actually sees or does. He also objects to restricted model choice and shallow extensibility, noting that command-based hooks launch separate processes rather than offering deep, integrated control over the harness. These criticisms are presented as reasons the tool no longer matched his needs, not as a dismissal of the team that created it. 0:15

Examining alternatives reinforced the same concern. Zechner describes Open Code conditionally pruning tool outputs, which he argues removes information the model still needs. He also criticizes automatically injecting language-server errors after every edit: intermediate code often remains invalid until a larger change is complete, so surfacing diagnostics too early can distract the model. His broader point is that helpful-looking harness features can become harmful when they intervene in context without regard for the actual task. 3:16

Zechner points to Terminal Bench as evidence that a coding agent does not necessarily need an elaborate harness. He describes a setup that gives the model a way to send keystrokes to a terminal session and read the output, without dedicated file tools or sub-agents. In the December 2025 leaderboard he discusses, this minimal approach often scored above more elaborate harnesses, including some native harnesses for the same model families. The example supports his narrower conclusion that the current design of coding agents remains unsettled. 4:18

From that observation, Zechner develops two connected ideas: coding agents are still in an experimental phase, and developers need better ways to experiment. His answer is a minimal, malleable core that both the user and the agent can modify. Rather than requiring developers to reshape their work around a fixed product, pi is designed to adapt to the workflow already in front of them. 5:13

The system is organized into four packages: an AI abstraction for providers and context handoff, an agent core built around a tool-calling loop, a custom TUI framework, and the coding agent itself. Its built-in tools are limited to read, write, edit, and bash. Zechner argues that models already understand the basic role of a coding agent from their training, so a large system prompt is unnecessary; support for Skills adds some prompt text, but the underlying preference remains brevity. 5:13

He reports that pi reached sixth place on a Terminal Bench leaderboard from October, before it had compaction. That result is offered as an example that a small core can still perform competitively, not as proof that every minimal harness is superior in every setting. The larger lesson he emphasizes is that developers should reclaim control over their tools and workflows, whether or not they choose pi itself. 10:10

Pi’s central mechanism for self-modification is deliberately direct: it ships documentation and extension examples, then makes those materials available to the agent. Extensions are TypeScript modules, potentially as simple as a single file on disk, that pi loads into the harness. When a developer needs a new capability, the agent can inspect the documentation, write the extension, and revise it against the user’s specifications. 6:21

The extension API reaches across the harness rather than being limited to isolated callbacks. Extensions can define tools, slash commands, and shortcuts; react to events; save state in sessions; implement custom compaction or providers; and modify the TUI. Session state can optionally be exposed to the agent or retained for organizational tools that analyze sessions. This breadth is what makes the core small without requiring every advanced capability to be built in. 8:16

Hot reloading closes the loop: an extension can be developed inside an active session, reloaded immediately, and evaluated without restarting the workflow. Zechner gives examples including a side conversation with an agent during its main task, a customized chat room connecting multiple pi agents, and interfaces capable of running NES games or Doom. He also notes that capabilities such as sub-agents, plan mode, and MCP support can be added as needed rather than imposed universally. 7:21

The same philosophy applies to distribution and security. Zechner favors publishing extensions through npm or GitHub instead of creating another proprietary marketplace. Pi also runs without routine approval prompts by default because he does not consider repetitive bash confirmations a sufficient universal security model; instead, he expects users to construct controls appropriate to their own requirements. That flexibility comes with an explicit tradeoff: the user is responsible for deciding which safeguards their situation demands. 7:21

The second part of Zechner’s argument concerns the maintenance burden created when agents operate at scale. After Peter placed pi inside OpenClaw as its agentic core, Zechner says his open-source project began receiving unwanted attention from OpenClaw instances, including low-quality issues and pull requests. His concern is not simply that generated contributions contain mistakes; it is that automation can produce enough unsolicited activity to consume a maintainer’s time and attention. 10:10

To restore a human bottleneck, he describes automatically closing initial pull requests and asking contributors to first write a short issue in their own voice. Once he approves that interaction, the contributor’s account is added to a repository file and later pull requests can proceed. Zechner says automated agents generally do not return to read the closure comment, making the extra conversational step an effective filter for the behavior he wants to discourage. 11:11

He supplements that gate with other maintenance controls: deprioritizing issues associated with OpenClaw interactions, embedding issue and pull-request text into a three-dimensional space to identify clusters, and temporarily closing the tracker when he needs a break. His assessment is qualified rather than absolute: these measures work to some extent, but they do not eliminate the broader tension between automated contribution volume and finite human capacity. 11:11

Zechner argues that unrestricted agent use can compound errors while delaying the moment when anyone experiences the consequences. More agents can generate more code and more defects than a team can realistically inspect, while a separate review agent may catch some problems without resolving the underlying imbalance. The practical constraint is not how much code agents can produce; it is how much resulting behavior humans can understand, evaluate, and maintain. 12:22

His explanation centers on local optimization. Models learn from existing internet code, which he characterizes as containing substantial mediocre or poorly designed material, and they make decisions based on the context available for the immediate task. When a codebase is too large to fit into context, an agent may add abstractions, duplication, backward-compatibility layers, or defensive complexity without understanding how those choices interact across the whole system. A detailed specification helps only to the extent that it actually resolves the important decisions; remaining blanks are still filled by the model’s learned patterns. 13:19

Humans, in his account, provide two properties that agents lack: a natural limit on how quickly mistakes accumulate and the ability to feel the maintenance pain those mistakes create. That discomfort can motivate learning, collective refactoring, or other corrective action. By contrast, Zechner argues that agents will continue generating changes without acquiring the same durable understanding, and that elaborate memory systems do not substitute for human learning. 14:15

The danger becomes most visible when a team stops reading its own code. If users encounter a failure, neither the humans nor an overwhelmed agent may possess enough system-wide context to diagnose it confidently. Zechner warns that larger context windows and agentic search are not guaranteed remedies, and that locally plausible patches can introduce broader regressions. Trust erodes further when the same agents that produced the implementation also generated the tests used to validate it. 15:24

Zechner’s proposed alternative is not to abandon coding agents but to assign them work with a well-defined scope. A good agent task is bounded tightly enough that the agent can find all the relevant information needed to complete it. Modularizing the codebase makes those boundaries easier to establish, and an objective evaluation function improves the setup further by allowing the result to be assessed against a clear target. 15:24

He identifies several productive applications: optimization or research loops with measurable feedback, noncritical work, repetitive tasks, and constructing reproduction cases from incomplete user reports. Agents can also serve as a substitute conversational partner when no human collaborator is available. The workflow still ends with human evaluation: examine what the agent produced, retain what is reasonable, and finalize the result deliberately. 16:31

His closing prescription is to slow down, decide what is worth building, and resist adding features merely because an agent can generate them. Teams should limit generated code to an amount they can actually review, use agents to polish the features that matter, and distinguish between disposable or noncritical work and code whose failure would matter. For critical code, Zechner insists on reading every line; for important decisions, he argues that humans should write the code themselves, using agents as assistance rather than as the final authority. 16:31

The apparent friction in that process is part of its value. Working through the details builds a mental model of the system and creates opportunities to learn, while delegating every consequential choice undermines both understanding and agency. Across pi’s architecture, open-source maintenance, and coding practices, the same principle recurs: useful automation should expand human control without displacing human judgment. 5:13