Conference talk by Mario Zechner about building "pi", a minimal, self-modifying, extensible coding agent. Covers his frustrations with existing agent harnesses, why context management in tools like Cloud Code and Open Code fails, the value of minimal harnesses and a "Terminal" benchmark, pi's design (TypeScript-based extensibility with a permissive security philosophy, plus example extensions), and a broader argument about how AI agents affect open source software — including "enterprise-grade complexity", humans remaining the bottleneck, and practical advice for integrating agents into developer workflows. # Channel Identity Observations — "Building pi in a World of Slop — Mario Zechner" ## Speaker & Context - The presenter identifies himself: **"Hey there. I'm Mario. I built pie in a world of slop"** — indicating a conference-style talk (audience reactions: *laughter*, *cheering*, *gasps* present in the transcript). - He presents himself as an experienced developer: **"this is just me, an old man, telling you why I stopped using cloud code"**, and references prior work: **"I have history in OSS"**, **"I come out of game development"**, **"I used to work at construction sites."** ## Intended Audience - **Developers using or evaluating AI coding agents** — the talk assumes familiarity with Claude Code, OpenCode, Amp, Factory Droid, Terminal Bench, MCP, and sub-agents. - The audience is addressed directly and repeatedly: **"some of you might have written some hooks for Claude Code"**, **"Who has seen that in the output of their agents?"**, **"How much of those booboos do you think you'll find?"** - **Open-source maintainers** are an implied audience segment — Act Two covers agent-generated spam in issue trackers: **"Half of that is Open Claw instances who post garbage."** - A **live conference audience** is evidenced by laughter, cheering ("Yes, we know it sucks now. Congratulations."), and cross-references: **"See the keynote after me for more info on that"**, **"go to this talk, please." ## Claimed Scope & Self-Description - He positions himself as a **tool builder and OSS maintainer**: creator of "pi," described as **"an agent that adapts to your workflow instead of the other way around."** - Describes pi's architecture: **four packages** (AI abstraction, agent core, TUI framework, coding agent), **four tools** ("read, write, edit, bash"), and extension-based self-modification. - Explicit philosophy claims: - **Minimalism**: "I stripped away all the things, built a minimal core, but made it super extensible." - **Security stance**: "my security needs are different than yours… I don't think a little dialogue that pops up every time you call bash… is a smart security mechanism." - Claims benchmark evidence: **"terminal bench leaderboard from October before Pi had compaction… It scored sixth place."** - He cites his own blog as the origin of an argument: **"I wrote this on my blog a while ago, but the basic gist is…"** ## Demonstrated Presentation Patterns - **Opinionated, humorous, blunt tone**: coinages like **"compounding booboos"**, "enterprise-grade complexity within 2 weeks with just two humans and 10 agents. Congratulations." and the closing refrain **"Slow the [f***] down."** - **Opinionated but explicitly non-hostile framing** toward other tools/teams: "I love the cloud cloud team. They're brilliant people… this is not a roast." Similarly praising Amp and Factory Droid ("the Porsche and Lamborghini of coding agent harnesses") and OpenCode ("brilliant team"). - **Detailed technical critique with specific evidence**: context handling ("my context wasn't my context"), OpenCode's LSP-based error injection, per-message JSON storage, CORS issue, Terminal Bench minimalism. - **Prescriptive advice to the audience**: scoping agent tasks, "Cap the amount of generated code that you need to review", "Critical code, read every line", "if you do anything important, write it by hand." - **Charitable gesture mentioned**: "Bunch of people on the internet gave me money for ad space on my torso and all of that goes to a charity." ## Channel-Level Signals (from this video alone) - The video demonstrates a channel/venue featuring **practitioner-led technical talks on AI coding agents**, with critique, tool-building narratives, and prescriptive engineering guidance. - No curated metadata was provided; identity signals are limited to the talk itself. No explicit channel self-description (e.g., "this channel is about…") appears in the transcript. # Delivery Observations: "Building pi in a World of Slop — Mario Zechner" ## Overall Tone - **Conversational, humorous, blunt.** The talk is framed as entertainment with critique: "this is a tragedy tragedy in three acts," "this is not a roast. This is just me, an old man, telling you why I stopped using cloud code." - Frequent **casual profanity and slang**, apparently partially censored/softened in the transcript: "slow the down," "refactoring the out," "what the is going on here," "booboos." - Self-deprecating asides: "I'm a heathen. Because this is how I do it." ## Structure Habits - **Explicit three-act framing**, announced up front: "act one, building pie," "this is act two, OSS in the age of clankers," "which leads me to act three, slow the down." - **Thesis statements delivered explicitly:** "The form two thesis is... second thesis is we need better ways to around." ## Recurring Vocabulary & Phrases - **Neologisms/nicknames:** - "clankers" for agent bots ("rage against the clankers," "Here's a clanker") - "booboos" for errors: "agents are actually compounding booboos, which is my word for errors" - "slop" (from the title) and "five slope ahead" (uncertain transcript rendering) - **Repeated contrast pattern:** praising teams before criticizing their tools — "I love the cloud cloud team. They're brilliant people, talented, super high velocity... this is not a roast"; "brilliant team, super high execution velocity." - **Repeated "Congratulations" as sarcastic punchline:** "Congratulations" after "enterprise-grade complexity within 2 weeks," "We know it sucks now. Congratulations," "Congratulations. Something is broken." ## Teaching Habits - **Analogies from physical trades and gaming:** - > "I used to work at construction sites and if my hammer breaks every day, I'm getting really mad." - > "Amp and FactoryDroid, the Porsche and Lamborghini of coding agent harnesses." - References to game development: hot reload and "very low iteration speeds." - **Rhetorical questions to the audience:** "Who has seen that in the output of their agents?", "So, who you going to call?", "So, how do you know what's critical? Any guesses?" - **Direct address and audience interaction:** the transcript shows audience [laughter], [cheering], [gasps] responding to his punchlines. ## Repetition Patterns (well-evidenced) - "zero" as an emphatic quantifier: "zero observability," "zero model choice," "almost zero extensibility," "there's absolutely zero chance." - "brilliant" applied to multiple teams (Claude team, open code team) — a stable verbal tic. - Dismissive imperatives: "Come on, people," "let it wipe," "So, good game." ## One-off / Uncertain Moments - The disclaimer about torso ad sponsorship appears once — an isolated opening aside, not a pattern. - Verbal disfluencies ("um," "uh") and transcript-visible repetitions ("the the the effects") suggest an informal, semi-improvised delivery, but transcript quality limits certainty on exact manner. ## Communication Pattern Summary The speaker consistently **softens technical criticism with humor and compliments**, delivers opinions in short declarative punchlines, and lands each section with a memorable coined phrase ("slow the down") — observable throughout the transcript rather than an inferred trait. # Position Record: "Building pi in a World of Slop" — Mario Zechner ## Speaker - **Mario Zechner**, sole speaker (self-identified in transcript). Talk framed as "a tragedy in three acts." --- ## Act One: Building pi ### On Claude Code (positive, then critical) - Started using **Claude Code in April 2025** after "Peter" told him agents were working; it was then "simple and predictable and fit my workflow." - Explicitly praises the Claude Code team: "brilliant people, talented, super high velocity... This is not a roast." - Stated criticisms: - **Velocity and more features bring more bugs**; analogy: a hammer that breaks daily at a construction site. - **"My context wasn't my context"** — the core problem: Claude Code modifies context behind the user's back (changing system prompts and tool definitions per release, removing/modifying tools, inserting "system reminders" at inopportune places). - **Zero observability**, **zero model choice** ("it's the native Anthropic harness"), **shallow extensibility** (hooks spawn a new process each trigger — inefficient). ### On alternatives - Praises **Amp and Factory Droid** ("the Porsche and Lamborghini of coding agent harnesses... if you can afford them"). - Gravitated to **Open Code** but found issues under the hood: pruning of tool outputs ("lobotomizes the model"), LSP-error injection into edit results (confuses the model because humans don't check errors line-by-line), one JSON file per message, and a default server configuration allowing any website to access the Open Code server. ### Terminal Bench observation - **Terminal Bench**'s Terminus harness — minimal (only tmux keystrokes/output) — outperforms native harnesses irrespective of model family (leaderboard from December 2025). - Inferences he draws ("theses"): - We are in the "around and find out" phase; current agent form is not final. - We need **self-modifying, malleable agents**. ### pi's design (his project) - Minimal core, super extensible; agent adapts to your workflow, not vice versa. - Four packages: AI abstraction (providers + context handoff), agent core ("just a while loop and tool calling"), bespoke TUI framework, coding agent. - Nearly empty system prompt; skills support added "begrudgingly." - Self-modification via shipped documentation + code examples; agent told how to write extensions. - Only four tools: **read, write, edit, bash** — models are already "coding agents" post-training, no need for 10,000-token prompts. - **Yellow by default**: no approval dialogs ("I don't think a little dialogue... is a smart security mechanism") — instead gives "so much rope" to build fit-for-purpose security. - No built-in sub-agents/plan mode/MCP — ask pi to build them. - Extensions are TypeScript modules; hook into everything; full control; distributed via **NPM/GitHub** ("we don't need... marketplaces"); hot reload for fast iteration (game-dev influence). - Examples: someone built an Anthropic-style "slash" interject in 5 minutes; Nico's agent chat room; NES/DOOM. - "How do you build a pi extension? You don't. You tell pi to build it." - **Terminal Bench, October (pre-compaction)**: scored sixth place. - Framing caveat: "none of this is actually about pi... I want you to retake control of your tools and workflows. Build your own." --- ## Act Two: OSS in the age of "clankers" - Peter put pi inside **Open Claw** as agent core → his OSS project became a target of many Open Claw instances "unbeknownst to their users." - Claims: "Clankers are destroying OSS" — cites Tauri(?) ("Till Draw") closing its tracker, Open Claw's trackers, and his own tracker, "half of that is Open Claw instances who post garbage." - Countermeasures he took: - Auto-close PRs with a comment asking for a human-voiced issue; humans get vouched into a file; "clankers don't read that comment... perfect filter." Mitchell later turned this into "vouch." - Deprioritizing issues from accounts that interacted with Open Claw; 3D embedding clustering of issues; closing the tracker "whenever I want, so I have my life back." - Verdict, with qualification: "Does this work? **Yes, sort of.**" --- ## Act Three: "Slow the f*** down" ### Diagnosis - "Everything's broken"; mocks claims like "our product's been 100% built by agents" ("we know it sucks now"), agent-built C compilers/browsers, "SaaS is dead," "my grandma built a Spotify." - **Agents compound "booboos" (errors) with zero learning, no bottlenecks, and delayed pain** — the pain is yours. - Review agents = "ouroboros": catches some issues but agents "learned complexity" from the internet, "90% of code on the internet is our old garbage." - Agent decisions are local; big codebases → abstractions, duplication, backward compatibility, defense in depth — "enterprise-grade complexity within 2 weeks with two humans and 10 agents." - Rebuttals to anticipated objections: - "But my detailed spec" — a sufficiently detailed spec is a program; blanks get filled with internet garbage. - "But humans also [err]" — humans learn, are bottlenecks, and feel pain (quit, blame, or collectively refactor); agents "will happily keep [pooping] into your code base." - Agent memory systems won't save you; agents don't learn as humans do. - If you don't read the code, when things break you rely on overwhelmed agents; **long context windows are "a hack"**; agentic search fails; agents patch locally, not globally. - Can't trust the codebase or the tests ("your agent wrote your tests"). ### Prescriptions (good agent tasks) - Scopeable tasks guaranteed to contain needed context; modularized codebase; an evaluation function; hill climbing / auto research; non-mission-critical work; reproduction cases for user issues; rubber duck when no human nearby. - Workflow: **evaluate → take what's reasonable → finalize** ("most of it isn't" reasonable). ### Closing advice - Slow down; think about what and why you're building. - **Learn to say no** — "your most valuable capability." - Fewer features, polished with agents; cap generated code requiring review. - **"Non-critical code, sure, five slop ahead. Critical code, read every line."** - To know what's critical, "you read the code." - Anything important: write by hand; a clanker may help but must not make decisions. - Friction builds understanding and is where you learn. - "All of this requires discipline and agency... and still requires humans." --- ## Preserved Qualifications & Tensions - Praise for Claude Code team coexists with strong criticism — explicitly framed as "not a roast." - Clanker countermeasures: success stated only as "Yes, sort of." - Open Code flaws noted with a qualification: "this happens to all of us, no blame there." - Benchmark results cited with specific dates (Oct 2025 pre-compaction, Dec 2025 leaderboard) as presented; not independently verified. - Strong normative claims ("everything's broken," "long context windows are a hack") are his expressed opinions, several explicitly flagged "in my opinion." # Speaker Attribution Record — "Building pi in a World of Slop — Mario Zechner" ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Mario Zechner** | **Creator / sole presenter** | Opens with self-introduction: "Hey there. I'm Mario. I built pie in a world of slop" | - No other speakers; the talk is a single-presenter format structured as "a tragedy in three acts" (Act 1: building pi; Act 2: OSS and clankers; Act 3: working practices with agents). ## Third Parties Referenced (not speaking) - **Peter** — credited with introducing Mario to Claude Code agents ("thanks to Peter… the agents are working now"); later "put pi inside of Open Claw as its agent core." - **Tariq** — quoted/commented that "cloud code is now a game engine" (per Mario, a running gag). - **Mitchell from Ghosty** — rebuttal quote: "No, it's not"; later "turned that into vouch" (vouching tool). - **Nico** — described as "one of the most prolific extension writers"; built a chat room UI for pi agents. - **Till Draw** — cited for closing down issue/PR trackers (act two context). - **Anthropic / Claude Code team** — referenced as product authors, not speakers. - **Kerbal** — referenced as "building a browser" with agents. ## Referenced Sources & Products - **Tools/platforms:** Claude Code, Amp, FactoryDroid, OpenCode, Open Claw, pi (Mario's own agent), Terminal Bench (benchmark), NPM, LSP servers, tmux, vouch. - **Benchmark claims:** Terminal Bench leaderboard (December 2025; October 2025 before pi compaction — pi scored sixth place). - **Personal blog:** Mario states he "wrote this on my blog a while ago" regarding agent working practices (no URL given). - **Twitter/X post:** a joking prompt Mario posted, which someone built as an extension in 5 minutes. ## Promotional Segments - **Torso ad-space sponsorship (opening):** "Bunch of people on the internet gave me money for ad space on my torso and all of that goes to a charity." — flagged as **promotional/sponsorship disclosure**. - **Recommendations of Amp and FactoryDroid** ("the Porsche and Lamborghini of coding agent harnesses… if you can afford them, please use them") — promotional in tone; recorded as stated. - **Self-promotion of pi and extensions ecosystem** (NPM packages, search interface, cross-promotion of a follow-up talk about pi and Open Claw). ## Provenance & Availability Notes - **No curated metadata supplied** — no verified speaker identity, affiliation, or venue beyond the transcript itself; identity "Mario Zechner" comes from the video title only. - **Comment availability:** not stated in source. - **Quotes from third parties** (Tariq, Mitchell) are relayed by Mario, not verifiable primary quotes. - **Quantitative claims** (leaderboard ranks, benchmark dates, "90% of code on the internet is garbage") are Mario's assertions; no external citations provided. \>\> 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 that kind of clicked with me the most. And to preface all of this, I love the cloud cloud team. They're brilliant people, talented, super high velocity. So, uh they also created the entire game. Major props to them. So, this is not a roast. This is just me, an old man, telling you why I stopped using cloud code and built my own thing. Um in 2025 I started using cloud code in about April, I think, thanks to Peter uh because he told us the agents are working now. And back then it was simple and predictable and fit my workflow, but eventually the token madness got hold of them, I think, and the team got bigger and they started uh dog fooding that stuff and built a lot of features. A lot of features I don't need, which is fine. I can just ignore them. But with velocity and more features come more bugs and that's bad because I used to work at construction sites and if my hammer breaks every day, I'm getting really mad. And if my development tools break every day, I'm also getting mad. So, there was this. It's just a running gag and here's Tariq telling us that cloud code is now a game engine. And here's Mitchell from Ghosty telling us, "No, it's not." And eventually they fixed the flicker, but then other stuff broke and I think they're now in the third iteration of a tool renderer. Yeah, but that's just a symptom. The real problem is that my context wasn't my context. Cloud code is the thing that controls my context and behind my back cloud code does things uh to the context. So, you have the system prompt which changes on every release, including the tool definitions. They would remove tools, modify tools. It's not good. They would insert system reminders in the most inopportuned place in your context telling the model, "Here's some information. It may or may not be relevant to what you're doing." That actually says it may or may not be relevant what you're doing. And that kind of confused the model and that kind of broke my workflows. On top of all that, there's zero observability because that's how the tool is constructed and I like knowing what my agents are doing. There's zero model choice which is obvious. It's the native Anthropic harness, so it makes sense for them to want you to use Claude, right? And there's almost zero extensibility and some of you might have written some hooks for Claude code, but I'm telling you the number of hooks and the depth of those hooks is very shallow. Um and every time a hook triggers, what actually happens is a new process gets spawned. Basically, the command you specified for that hook to be executed and I don't find that specifically efficient. So, I uh took a step back and looked around for alternatives and I'd like to especially call out Amp and FactoryDroid, the Porsche and Lamborghini of coding agent harnesses. So, if you can afford them, please use them. They're at the frontier. They're really good and the teams are fantastic. And there's a bunch of other options and I have history in OSS, so naturally I kind of gravitated towards open code. And again, brilliant team, super high execution velocity and they don't sell you hype. They sell you tools that work for the most part. I started looking under the hood of open code uh with respect to context handling as well because that's the most important part for me and I found a bunch of things like given some conditions, open code code would just uh prune tool outputs after a specific minimum amount of tokens. And that basically lobotomizes the model. Uh there's also LSP server support, which means every time your model is calling the edit tool, open code goes to the LSP server that's connected, asks, \[snorts\] are there any errors? And if so, injects that as part of the edit tool uh result. Which is bad, because think about how you are editing code. You're not writing a line of code, checking the errors, writing the next line, checking the errors. You don't do that. You finish your work and then you check the errors. This confuses the model. There's a bunch of other things like storing individual messages of a session in a JSON file. Each message message is a JSON file on disk. Uh there was this, and this happens to all of us, no no blame there, but it's not great if by default a server spins up, course headers are set in such a way that any website you open in your browser can now access your open code server. That's yeah. And uh entirely unrelated to all of this, I started looking into benchmarks for coding agent harnesses and found uh Terminal Bench, um which is a pretty good benchmark, all things considered. And the funny part about it is that it's the most minimal kind of thing you can think of. All it gives the model is a tool to send keystrokes to to a tmux session and read the output of that tmux session. There's no file tools, no sub-agents, none of that stuff. And it's one of the best performing harnesses in the leaderboard. Here's the leaderboard from December 2025. Irrespective of model family, Terminus scores higher, mostly high even higher than the native harness of that model. So, what does that tell us? The form two thesis is we are in the around and find out phase of coding agents, and their current form is not their final form, right? So, second thesis is we need better ways to around. And for me, that means self-modifying malleable agents. Things that the agent itself can modify, and I can modify, depending on my workflow. So, I stripped away all the things, built a minimal core, but made it super extensible, and made it so that the agent can modify itself. With some creature comforts, it's not entirely bare-bones. Uh so, that's Pie. It's an agent that adapts to your workflow instead of the other way around. It comes with four packages, uh an AI package, which is basically just an abstraction across providers and context handoff between providers, an agent core, uh which is just a while loop and the tool calling, a bespoke tweezer frame work. I come out of game development, so I built a thing that actually doesn't flicker too much, and the coding agent itself. Here's Pie's system prompt. \>\> \[laughter\] \>\> That's it. Eventually, the industry created a new standard called skills, which is basically just markdown files. So, we added that as well, and that needs to go in the system prompt. So, begrudgingly, we had to add a couple more lines. And finally, here's the magic that makes Pie able to modify itself. We ship the documentation, which was handcrafted by me and an agent, um and code examples of extensions. And \[clears throat\] all we need to do for the agent to modify itself is tell it, "Here's the documentation. Here's some code that shows you how to modify yourself by writing extensions." It comes with four tools. That's all it has, read, write, edit, bash. Here's the tool definitions. Don't read the the text, just look at the size. That's it. Here's what happens when you start a new session in one of these tools. So, the thing is, the models are actually reinforcement trained up to a zoo. So, they didn't know what a coding agent is, because the coding agent harness is basically what they're being trained when they are post-trained. You don't need 10,000 tokens to tell them, "You're a coding agent." They know, because they are coding agents now. Pie is also yellow by default, because my security needs are different than yours, and I don't think a little dialogue that pops up every now every time you call bash, asking you to approve, is a smart security uh mechanism. So, instead, I give you so much rope that you can build anything that's fit for your specific security needs. There's also stuff that's not built in. I'm a heathen. Because this is how I do it. But if you don't like that, then you just ask Pi to build you sub-agent support on plan mode or MCP support, whatever you need. Extensibility comes with a bunch of table stakes and then with the extensions itself. And extensions in Pi are just TypeScript modules. In the simplest case, a TypeScript file on disk. You point Pi at that. Here's an extension, load that as part of the harness. And with that, you get a basically an extension API that lets you hook into everything and define stuff for the harness to expose to the to the model. And that includes tools, slash command shortcuts. You can listen in on any kind of event and react and then save state in the session that's optionally provided to the agent as well or stored there for tools that analyze sessions as part of your organizational workflows. You can do custom compaction, custom providers, and you have full control over the tools. So, you can modify everything in Pi. And you can then bundle all of that up and put it on NPM or on GitHub because I think we don't need to reinvent another bunch of silos called marketplaces. We already have package managers managers. And all of that hot reloads. So, if you develop an extension for Pi, you do so in the session and you hot reloads changes and see the the the effects of that immediately, which is very great and that's also game development thing is in game development, you want high very low iteration uh speeds and that's great. So, a couple of examples. Cloud or Anthropic ships the slash, by the way, which lets you talk to the agent while goes on its main quest. I posted this little prompt on Twitter jokingly and somebody built it in 5 minutes with more features. And they didn't have to fork or clone it just let the agent write the extension based on the prompt. Here's Nico as one of the most prolific uh extension writers. I don't know what the is going on here. It's a chat room for all of his Pi agents and they talk with each other. I would never use this, but all of this is custom including the UI. Or you can play NES games. Or you can play Doom. And there's a bunch of other examples I'm not going to talk about. So, how do you build a Pi extension? You don't. You tell Pi to build it for you based on your specifications and then you just iterate with it on that and hot reload during the session. Going to skip that example as well. And if you don't like building things yourself and I hope you do like building things yourself, but if you don't you can look on NPM or our little search uh interface on top of NPM to find packages for sub agents, MCP, and so on. So, does it actually work? Well, here's the terminal bench leaderboard from October before Pi had compaction. I added that for Peter's claw thingy. It scored sixth place. Uh but none of this is actually about Pi. If you want to read I basically want you to retake control of your tools and workflows. So, build your own. Um and if you want to know more about Pi and Open Claw, go to this talk, please. Yeah, and then eventually Peter happened. He put Pi inside of Open Claw as it's a gent core, which meant my open source project became the target of a lot of Open Claw instances unbeknownst to their users. So, this is act two, OSS in the age of clankers. Clankers are destroying OSS. Here's Till Draw. They closed down the issue and pull request tracker. Here's Open Claw's uh trackers. Here's mine. Half of that is Open Claw instances who post garbage. So, I started to rage against the clankers. Um if you send a pull request, it gets auto closed with a comment that asks you to please write a nice issue in your human voice no longer than a screen worth of text. And if I see that, I write looks good to me and your account name gets put in a file in the repository and the next time you send a pull request, it's let through. Clankers don't read that comment. They don't go back once they posted a pull request. So, that's a perfect filter. Uh Mitchell eventually turned that into vouch. Here's a clanker. Uh I also labeled them. If you had interactions with open claw, your issues get deprioritized. I also built tools where I embed uh issues and pull request texts into 3D space, so I see clusters of issues. Uh I also invented OS certification. I just close the tracker whenever I want, so I have my life back. So, does this work? Yes, sort of. \>\> \[laughter\] \>\> Which leads me to act three, slow the down. Everything's broken. And then there's people that say, "Our product's been 100% built by agents." Yes, we know it sucks now. Congratulations. \>\> \[cheering\] \>\> And I'm hearing this from my peers, and this is entirely unhealthy. Um so, here's how we should not work with agents and why, at least in my opinion. I wrote this on my blog a while ago, but the basic gist is we're having army of agents in your using beats on and you don't know that it's basically uninstallable malware, and Entropic built a C compiler. It kind of works, but actually doesn't, and we're hoping the next generation of molds will fix it. And here is Kerbal building a browser, and that's also super broken. Uh but the next generation will fix it. And SaaS is dead software is often 6 months, and my grandma just built herself a Spotify with her open claw. Come on, people. So, agents are actually compounding booboos, which is my word for errors, with zero learning and no bottlenecks and uh delayed pain. The delayed pain is for you. Here's your code base on a human, on one agent, and 10 agents. How much of the agent code can you review? Here's the same code base, but expressed in number of booboos per day. How much of those booboos do you think you'll find? Then you say, "Oh, I have a review agent." Let me introduce you to the wonderful world of the ouroboros. Doesn't work. It catches some issues. Um the problem is that agents and merchants have learned complexity. Where did they learn that complexity from? From the internet. What's on the internet? All our old garbage code. There are some pearls on the internet, really well-designed systems, but 90% of code on the internet is our old garbage. And that's what the models learn from. And every decision of an agent is local, especially if the code base is so big that it doesn't fit into its context. And if you let it go wild and add abstractions everywhere that are and intertwined. Um so that leads to a lot of abstractions and duplication and backwards compatibility. Who has seen that in the output of their agents? It's annoying. Or defense in depth. So yeah, you get enterprise-grade complexity within 2 weeks with just two humans and 10 agents. Congratulations. And then you say, "But my detailed spec." Yes, sure. You know what we call a sufficiently detailed spec? It's a program. So if you leave blanks in your spec, what do you think happens? How does the model fill in the blanks? And with what does it fill that in? It fills it in with the garbage that it learned on the internet from our old code, which is garbage from mediocre. And then you say, "But humans also." Yes, humans are horrible, failed fallible beings, but they can learn. And they are bottlenecks. There's only so many booboos they can add to your code base on a daily basis. And humans feel pain. Which is a very interesting property because humans hate pain. And once there's too much pain, the human has a bunch of options. It can quit their job. It can uh blame somebody else and make them fix it. Or everybody bands together and starts refactoring the out out of the garbage code base, right? Agents will happily keep into your code base. And now your agents and their super complex memory systems will not save you. Agents don't learn the way we learn. Those are my most most beloved people. I don't even read the code anymore. Congratulations. Something is broken and your users are screaming. So, who you going to call? Not yourself, because you haven't read the code. So, you're relying on your agents, but they are now also overwhelmed because the code base is so humongous that there's absolutely zero chance they can get all the context they need to fix the issues. And long context windows are a hack, as most of you will find those this year as everybody's switching to 1 million tokens context windows. And agentic search is also failing. So, the agent patches locally and up globally. If you see this in your code base, you're So, you cannot trust your code base anymore and also not your tests because your agent wrote your tests. So, good game. So, here's how I think we should work. Um there's a bunch of properties for good agent tasks. That means scope. If you can scope it in such a way that the agent is guaranteed to find all the things it needs to find to do a good job, you're done. That means modularize your code base. If you can give it a function to evaluate how well it did the job, even better. Hill climbing, auto research. Uh anything non-mission critical, let it wipe. Boring stuff, let it wipe. Reproduction cases for user issues, which are usually only partial in information, perfect. I don't spend any mornings anymore doing that. Or if you don't have a human near you, rubber duck. So, lots of tasks you can use them for and save time. At the you evaluate. You take what's reasonable, most of it isn't, and then finalize. My final slide, more or less. Slow the down. \>\> \[gasps\] \>\> Think about what you're building and why, and don't just build because your agent can do it now. That's stupid. Uh learn to say no. This is your most valuable capability at the moment. Fewer features, but the ones that matter, and then use your agents to polish the out of that. Enlighten your users, not your uh token maxing desires. Cap the amount of generated code uh that you need to review. And non-critical code, sure, five slope ahead. Critical code, read every line. See the keynote after me for more info on that. So, how do you know what's critical? Any guesses? Well, you read the code. \>\> \[laughter\] \>\> Uh if you do anything important, write it by hand. You can use a clanker to help you with that, but don't make let it make the decisions for you because we've learned all the decisions it makes are learned from the internet. And that friction is the thing that builds the understanding of the system in your head, which is important. And it's also where you learn new things. And all of this requires discipline and agency. And all of this still requires humans. Thank you. Woo!