Building pi in a World of Slop — Mario Zechner
Summary
Mario Zechner, creator of the LibGDX game framework, delivers a provocative three-act talk about building a minimal coding agent called Pi, defending open-source software against AI-generated noise, and arguing forcefully that the industry needs to slow its adoption of agentic software development.
Act one details Zechner's disillusionment with Claude Code and Open Code as daily coding tools. His central complaint with Claude Code is context opacity: the system prompt changes silently on every release including tool definitions, system reminders are injected mid-context with language like "this may or may not be relevant," there is zero observability into what the agent is doing, no model choice, and hooks spawn separate OS processes rather than providing deep integration. Open Code fares no better under scrutiny — it prunes tool outputs past a token threshold (which Zechner calls "lobotomizing the model"), polls an LSP server for errors after every single edit tool call rather than at task completion, stores each conversation message as a separate JSON file on disk, and shipped with CORS headers permitting any website to access the local server by default.
This led Zechner to study Terminal Bench, a benchmark that provides only two tools — sending keystrokes to a tmux session and reading its output. Despite this extreme minimalism, Terminal Bench consistently outscored richer harnesses on the December 2025 leaderboard, sometimes even outperforming the native harness of a given model family. Zechner's thesis: current coding agents are in the "around and find out" phase and their present form is not their final form; the correct response is to build self-modifying, malleable harnesses rather than larger ones.
Pi's design reflects this philosophy. Its system prompt is a single sentence. It ships four tools: read, write, edit, bash. A YOLO security mode skips per-command approval dialogs entirely, giving users rope to build their own security controls. Extensibility is via TypeScript modules — single files pointed at Pi at startup — that can hook into any event, define new tools, add slash command shortcuts, perform custom context compaction, and swap providers. All extensions hot-reload within a live session. Pi placed sixth on the Terminal Bench leaderboard in October before compaction was added, and Zechner frames it less as a product and more as a call for developers to reclaim ownership of their tooling.
Act two addresses what Zechner calls "clankers" — automated agents, primarily Open Claw instances, flooding his GitHub issue and pull-request trackers with machine-generated garbage. His defenses include: auto-closing PRs with a human-voice challenge comment that clankers never respond to, a whitelist file ("vouch") for verified humans, issue clustering by embedding PR text into 3D space to surface duplicates, and simply closing the tracker whenever needed.
Act three is the sharpest section. Zechner argues that unfettered agent use compounds errors with zero learning, no natural bottlenecks, and delayed pain. He illustrates the problem with a thought experiment: a codebase built by one human versus one agent versus ten agents — reviewable code shrinks toward zero while bugs-per-day compound. Review agents create an "ouroboros" that catches some issues but fundamentally fails because agents learned from the internet, which is predominantly poor-quality legacy code. Every agent decision is local; when context overflows, agents patch locally while breaking things globally. The result is enterprise-grade complexity within two weeks: redundant abstractions, defensive duplication, backwards-compatibility layers. Long context windows (1M tokens) are described as a hack that most teams will discover is insufficient this year.
His prescriptive framework for safe agent use focuses on task scoping — only assign work where the agent can guarantee it has all required context, the task is well-defined with a measurable success function, and the work is non-mission-critical or purely mechanical (reproduction cases, boilerplate, rubber-duck debugging). Critical code must be written by hand, read by humans, and understood structurally. Generated code volume should be capped to what the team can actually review. The closing argument: the friction of writing code by hand is the mechanism by which engineers build mental models of their systems, and outsourcing that friction to agents means nobody understands the system when something breaks.
Key Takeaways
- •Benchmark evidence (Terminal Bench, December 2025) shows minimal two-tool harnesses outperform feature-rich ones including native model harnesses — fewer tools often means better agent performance.
- •Context ownership is the most critical property of a coding agent harness; systems that silently modify the system prompt, inject mid-context reminders, or prune tool outputs undermine model reliability.
- •LSP error injection after every edit tool call (as in Open Code) mirrors an unnatural human workflow and confuses models — check errors at task completion, not after each line.
- •Build coding agent extensions as TypeScript modules with hot-reload so you can iterate on harness behavior within a live session rather than restarting.
- •Unfettered multi-agent development compounds bugs with no natural bottleneck — ten agents can generate more booboos per day than any human team can review, leading to unauditable codebases.
- •Agents fill underspecified requirements with patterns learned from the internet, which is predominantly low-quality legacy code; a sufficiently detailed spec is essentially a program.
- •Only assign agents tasks where they have guaranteed access to all required context, a measurable success function exists, and failure is not mission-critical.
- •Write mission-critical code by hand — the friction is the learning mechanism that builds the systemic understanding needed to debug production failures.
- •"Vouch" patterns (requiring a human-voice response to a challenge comment) are an effective automated filter for distinguishing human contributors from AI agents in OSS issue trackers.
- •Cap the volume of generated code to what the team can realistically review; treat any code that cannot be reviewed as a liability, not an asset.
Transcript
[music] >> Hey there. I'm Mario. I built pie in a world of slop and this is a tragedy tragedy in three acts. Just to talk about this real quick. Bunch of people on the internet gave me money for ad space on my torso and all of that goes to a charity. So, yeah, thanks guys. So, act one, building pie. In the beginning there was cloud code and it was good, right? We all got basically catnipped by that thing and stopped sleeping. Um bunch of stuff before that, but cloud cloud code was the one thing ...
