Presenters
Source
🚀 Beyond the Slop: Why I Built Pi and Why We Need to Slow Down
Hey there, I’m Mario Zechner. Recently, I’ve been wearing a t-shirt covered in paid ad space to raise money for charity, but when I’m not being a human billboard, I’m thinking about the “tragedy” of modern AI development. We are currently living in a world of slop, and I’m here to tell you how I built Pi to escape it.
🏗️ Act 1: The Rise and Fall of the “Magic” Coding Tool
In the beginning, there was Cloud Code (and tools like it). It felt like catnip for developers. The team behind it is brilliant, but eventually, what I call token madness took over. As the velocity increased, so did the features I didn’t need—and the bugs I couldn’t ignore.
When your hammer breaks every day on a construction site, you get mad. When your development tools flicker and break daily, you lose your mind. 🤯
The Problem with “Black Box” Context
The real issue isn’t just bugs; it’s that Cloud Code controls your context behind your back.
- System Prompts: They change on every release, modifying or removing tool definitions without telling you.
- System Reminders: The tool inserts random reminders into the context, often telling the model: here is some information that may or may not be relevant. This confuses the model and breaks workflows.
- Zero Observability: You have no idea what the agents are actually doing.
- Zero Extensibility: Most hooks are shallow and inefficient, spawning a new process for every single trigger.
The Thesis: Less is More
I looked at Terminal Bench, a leaderboard for coding agent harnesses. The top performer in December 2025 wasn’t a complex, feature-heavy beast. It was a minimal harness that simply gave the model a tool to send keystrokes to a T-Max session.
My conclusion? We are in the around and find out phase of coding agents. Their current form is not their final form. We need self-modifying, malleable agents that adapt to us, not the other way around. 🛠️
🥧 Introducing Pi: The Agent That Evolves
I stripped everything away to build Pi, a minimal core designed for extreme extensibility.
The Technical Stack 💻
Pi consists of four core packages:
- AI Package: An abstraction across providers (Anthropic, OpenAI, etc.).
- Agent Core: A simple while loop and tool-calling mechanism.
- Bespoke UI Framework: A toy framework I built (drawing on my game dev roots) that doesn’t flicker.
- The Coding Agent: The actual logic.
Minimalist by Design
Pi’s system prompt is tiny. Why? Because these models are reinforcement trained to be coding agents. You don’t need 10,000 tokens to tell them they are coding agents—they already know! 🧠
Pi ships with only 4 tools:
- Read
- Write
- Edit
- Bash
Self-Modification via TypeScript 🔄
The magic of Pi is that it can modify itself. I ship the documentation and code examples directly to the agent. If you want Sub-agent support, Plan mode, or MCP support, you don’t wait for a release. You tell Pi: Here is the documentation; write an extension to add this feature.
Extensions are just TypeScript modules that hot-reload instantly. No silos, no proprietary marketplaces—just NPM and GitHub. 🌐
🤖 Act 2: OSS in the Age of “Clankers”
As Pi grew, it ran into a new predator: Clankers. These are AI agents that autonomously roam GitHub, opening low-quality, “slop” pull requests and issues.
Fighting the Noise 🛡️
To save my sanity and my project, I implemented a few “anti-clanker” measures:
- The Human Voice Filter: I auto-close PRs with a comment asking the user to describe the change in a “human voice” within a specific text limit. Clankers don’t read comments; they just post and move on.
- Vouching: If a human responds correctly, their account is added to a vouch file, and future PRs are allowed through.
- OSS Vacation: Sometimes, I just close the issue tracker entirely. I want my life back! 🏖️
⚠️ Act 3: Slow the F*** Down
We’ve reached a dangerous point where people brag that their product was 100% built by agents. Usually, that just means the product now sucks.
The “Booooo” Compound Effect
Agents are compounding boooooos (my term for serial errors).
- The Ouroboros Problem: You use a coding agent to write code, then a “review agent” to check it. Both learned from the same source: the internet, which is 90% old garbage code.
- Local Success, Global Failure: An agent makes a “correct” local patch that breaks the global architecture because the codebase is too large for its context window.
- Delayed Pain: Humans feel pain when code is bad, so they refactor. Agents don’t feel pain; they will happily pile abstraction upon abstraction until your codebase is a hyper-complex nightmare. 📉
How to Actually Work with Agents 🎯
Don’t let the agent make the big decisions. Use them for tasks that are:
- Scoped: Where the agent can find all necessary context.
- Verifiable: Where you can give it a function to evaluate its success.
- Boring/Non-Critical: Reproduction cases for bugs or “rubber ducking.”
The Golden Rule: If it’s critical, read every line. If it’s important, write it by hand. ✍️
✨ Final Thoughts
Friction is actually a good thing. The friction of writing code is what builds the mental model of the system in your head. If you outsource all the thinking to a “clanker,” you lose your ability to fix the system when it inevitably breaks.
Build your own tools. Take back control. Enlighten your users, not your token-maxing desires. Slow down and build something that matters. 🚀💡🦾
Q&A Highlights
- Audience: How do we know what’s critical?
- Mario: You read the code. There are no shortcuts to understanding. If you don’t read it, you don’t own it. 🎯