# Building pi in a World of Slop Mario Zechner | AI Engineer Europe 2026 | 18:25 Source: https://www.youtube.com/watch?v=RjfbvDXpFls Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/building-pi-in-a-world-of-slop Published: 2026-04-16 Tags: agent-skills, agents, coding-agents, harness-engineering, open-source ## TL;DR - Mario Zechner built pi because existing coding-agent harnesses controlled his context, limited model choice, and offered too little extensibility. - Pi uses a small agent core with four tools, TypeScript extensions, hot reloading, and documentation that lets the agent modify its own workflow. - Agents can quickly add complexity and errors to a codebase, so humans should scope their tasks, review critical code, and slow down development. ## Summary Mario Zechner explains why he stopped using established coding-agent harnesses and built pi, a small agent core that he can inspect and change. He objects to hidden context changes, injected reminders, limited model choice, shallow hooks, and automatic edits that interrupt the model's work. Pi has four built-in tools, a short system prompt, and TypeScript extensions that can add tools, commands, event handlers, custom compaction, providers, and session state. Zechner also describes the effect of agents on open source, where automated issues and pull requests force maintainers to create filters. His larger concern is software built by many agents with little human review. Agents learn from existing code, including its accumulated errors, and can produce tangled abstractions, duplication, and excessive compatibility layers. He recommends narrowly scoped tasks, evaluation functions, human review, and hand-written decisions for important code. ## Key ideas ### Existing harnesses took control of the context he needed to own [01:46](https://www.youtube.com/watch?v=RjfbvDXpFls&t=106s) Zechner says Cloud Code initially fit his workflow because it was simple and predictable, but its growing feature set brought bugs and hidden behavior. The harness changed its system prompt and tool definitions between releases, inserted reminders that told the model information "may or may not be relevant," and gave him no way to observe all of its work. He also objected to having no model choice and only shallow hooks, with each hook spawning a new process. Open Code had different problems: it could prune tool output, inject LSP errors after individual edits, and expose a server to browser requests under certain default settings. ### A minimal harness can outperform a feature-heavy one [04:44](https://www.youtube.com/watch?v=RjfbvDXpFls&t=284s) Zechner points to Terminal Bench as evidence that coding agents do not need a large collection of built-in features. The benchmark gives the model a tool for sending keystrokes to a tmux session and reading its output. It provides no file tools or sub-agents. In the December 2025 leaderboard he shows, Terminus scored highly across model families, sometimes above the native harness for the same model. His conclusion is that current coding-agent designs are still in an experimentation phase. He wants better ways to test different designs, including agents that can change their own behavior and adapt to a developer's workflow. ### Pi keeps the core small while making the workflow changeable [05:35](https://www.youtube.com/watch?v=RjfbvDXpFls&t=335s) Pi consists of an AI package for provider abstraction and context handoff, an agent core with a while loop and tool calling, a terminal interface, and the coding agent itself. Its system prompt is deliberately short. The built-in tool set is read, write, edit, and bash. Pi also includes documentation and extension examples, which give the agent enough information to modify itself. Zechner describes this as an agent that adapts to the user's workflow rather than forcing the user to adapt to the harness. ### Pi treats security choices and features as extensions [07:27](https://www.youtube.com/watch?v=RjfbvDXpFls&t=447s) Pi uses a "YOLO" default because Zechner does not consider repeated approval dialogs for bash commands to be a good security mechanism. He prefers giving users enough control to build a security setup that fits their situation. Features he does not need, such as sub-agents, plan mode, or MCP support, can be added by asking Pi to build them. Extensions are TypeScript modules that can add tools and slash commands, listen for events, save session state, customize compaction, define providers, and change tool behavior. They can be published through NPM or GitHub, and changes hot reload during a session. ### Self-building extensions can turn a prompt into a working tool [09:03](https://www.youtube.com/watch?v=RjfbvDXpFls&t=543s) Zechner gives examples of pi extensions made by asking the agent to implement them. One extension lets agents talk in a custom chat room, including its user interface. Other extensions let the user play NES games or Doom. He says a developer does not have to fork the project or wait for a built-in feature. The developer can describe the desired behavior, let Pi write the TypeScript extension, and iterate while the session hot reloads changes. Existing packages can also be found through NPM or a search interface built on top of it. ### Automated open-source activity forces maintainers to add friction [10:46](https://www.youtube.com/watch?v=RjfbvDXpFls&t=646s) After Peter put pi inside OpenClaw as its agent core, OpenClaw instances began posting to Zechner's repository without their users knowing. He says about half of the tracker activity became garbage from those instances. His response was to close pull requests unless the author first wrote a short issue in a human voice, then allow the account through if it followed that instruction. He also used labels, deprioritized interactions associated with OpenClaw, clustered issue and pull-request text in 3D space, and closed the tracker when necessary. The approach worked "sort of," while also giving him back control of the repository. ### Unreviewed agent output compounds errors into complex systems [12:03](https://www.youtube.com/watch?v=RjfbvDXpFls&t=723s) Zechner argues that teams are adding agents faster than they can understand or review their output. Models learn from the internet, which contains useful systems alongside a large amount of mediocre and old code. When an agent makes local decisions in a codebase too large for its context, it can add abstractions, duplication, and backward compatibility that interact badly. Zechner says two humans and ten agents can produce "enterprise-grade complexity within 2 weeks." A review agent does not solve the problem because it catches only some issues. The people responsible may also stop reading the code, leaving both the code and its tests difficult to trust. ### Good agent tasks have narrow scope and a way to judge the result [16:12](https://www.youtube.com/watch?v=RjfbvDXpFls&t=972s) Zechner recommends giving agents work where they can find all the information needed to do it well. That may require modularizing the codebase. A function that evaluates the result makes the task more suitable for hill climbing or automated research. He is comfortable assigning non-mission-critical work, boring work, and reproductions of user issues. A human should then evaluate the output, keep what is reasonable, and finalize it. He advises capping the generated code that requires review, reading every line of critical code, and writing important decisions by hand. The friction helps the human understand the system. ## Notable quotes - "Pi is an agent that adapts to your workflow instead of the other way around." (05:59) - "Clankers are destroying OSS." (10:59) - "Enterprise-grade complexity within 2 weeks with just two humans and 10 agents." (14:10) - "Slow the fuck down. Think about what you're building and why, and don't just build because your agent can do it now." (17:02) - "If you do anything important, write it by hand." (17:46) ## Tools & references mentioned - pi - OpenClaw - Cloud Code - Open Code - Amp - FactoryDroid - Anthropic - Terminal Bench - Terminus - TypeScript - NPM - MCP - tmux - LSP - Doom - NES ## Who should watch - You are building or choosing a coding-agent harness and want direct control over context, tools, providers, and extensions. - Your open-source project is receiving automated issues or pull requests and you need practical ways to filter low-value activity. - You are using multiple agents on production code and need a stricter method for scoping tasks and reviewing their output. ## Related talks - [Software Development Agents: What Works and What Doesn't](https://aietalks.com/talks/software-development-agents-what-works-and-what-doesnt) (Robert Brennan, OpenHands, 16:46) - [Containing Agent Chaos](https://aietalks.com/talks/containing-agent-chaos) (Solomon Hykes, Dagger, 23:48) - [A Piece of Pi: Embedding the OpenClaw Coding Agent in Your Product](https://aietalks.com/talks/a-piece-of-pi-embedding-the-openclaw-coding-agent-in-your-product) (Matthias Luebken, Tavon, 20:42) - [How We Build Effective Agents](https://aietalks.com/talks/how-we-build-effective-agents) (Barry Zhang, Anthropic, 15:09) - [The Emerging Skillset of Wielding Coding Agents](https://aietalks.com/talks/the-emerging-skillset-of-wielding-coding-agents) (Beyang Liu, Sourcegraph / Amp, 35:06)