A Year of Agents: Armin Ronacher on Psychosis, Friction, and Staying in the Loop

🎙️ The Setup: A Year of Agents, No Hype 0:16

Armin Ronacher — the creator of Flask and Jinja2, two of the most-used Python libraries on earth — opens with a poll that makes his point before he's said a word: nearly everyone using agents describes themselves as a programmer, and only "quite a few, but not that many" don't. The technology of agents is still mostly sitting with engineers — but it's increasingly leaking into places where non-engineers are involved, and "quite a bit of what I'm going to talk about is about this."

Last year he left Sentry (10 years there, an 18-year-old pre-AI company) because it was clear "something is changing" — and the thing that made the change was Claude Code. The framing for the whole talk: he now builds agents at Earendil — and he builds them using agents. "This talk is one topic from different angles: what we've learned using them, and building them."

🧩 What an Agent Actually Is 3:54

LLMs have been around a while, but in late 2024 he told an investor he'd be "challenged if it's more than 10%" more productive as an engineer using AI. Four months later, in April, he fell into "the Claude Code trap" and that number was "completely invalidated." The difference between an LLM and an agent is one thing: an agent is an LLM with a tool loop — produce output, need more information, the harness runs what the agent wants, repeat. It's a loop with an LLM, tools, and a defined world (usually your computer).

😵‍💫 Agent Psychosis 6:44

He asks who's heard of "LLM psychosis" — very few. The idea: some people develop unhealthy relationships with their chatbot (there's a subreddit, he notes, called roughly "my boyfriend is an LLM"). He's been in the weeds: people who know nothing about him email him because the LLM told them to. Why him? The early OpenAI engineers used Python, so a lot of the initial code generation in the weights used Flask — his own library. People hit problems, kept asking the LLM, and eventually got pointed at the human who supposedly could solve it. "Most people would not send that email. The ones that do have an unhealthy relationship to the LLM."

He admits he developed an unhealthy relationship with his coding agent too — "it is incredibly addictive," and "a lot of people barely sleep." Then the concrete cost: Pi is open source and sits on GitHub, which is now "a place of collaboration of people that have authentic psychosis." One example, happening multiple times a day: a GitHub account committing 450 individual commits of complete randomness into a PR titled "pid to bash execution exec return type" — changing 664,000 lines of code, which he back-of-the-envelopes at about $1,200 in API tokens. Another simply rewrote Pi to a competitor's SDK. Why? "Because it can" — the machine has permissions and decides to throw work into someone else's turf.

🏢 The Enterprise Fallout 11:40

The sharpest observation: "just because you can produce a lot of output doesn't mean you develop a lot of understanding." He doesn't mind a sales engineer building a prototype to show a customer — that's empowering. What he increasingly objects to is core infrastructure written with AI and no human who understands it anymore. And there's a hard dependency lurking inside that: if those organizations lose access to the tokens, they "wouldn't even be able to maintain their own stuff anymore."

His own happiness curve over the year is the through-line: ecstatic in June and July (all-nighters, "super happy"), until roughly October — then something changed, "particularly Christmas." People used free/subsidized tokens over the break, discovered their powers, and came back to the office with "I built an entire product over Christmas — we should all adopt this and ship code like crazy." The expectation flipped, and "the entire industry is completely mad with tokens," believing all engineering problems are solved.

🧑‍💻 Organizations Are Not Ready 14:28

The stories from inside companies are the funniest and most uncomfortable part. A sales engineer made a sales demo demonstrating a feature that didn't actually exist. Junior engineers, who used to learn from seniors what not to do, now "argue with the Claude curator about how to convince their senior to ship this" — someone who shouldn't have that leverage suddenly has a huge one. And on a recent call, asking about a system's behavior, the person who built it said he'd need to ask his machine to answer, because he doesn't actually know.

Then the well-known line, with a new sting: "code generation is cheap now. Code review is not." CI passing is "just a suggestion"; a lot gets merged without review; many companies did away with their engineering process entirely because "otherwise you can't get the benefits of the speed." All of it goes to main.

💻 Code Is All You Need 17:35

Part two is the constructive half. "Code is everything you need." A coding agent writes and runs code — obvious. But it's true of every agent: Claude CoWork manipulates spreadsheets and presentations, Claude Design does Figma-style work, a medical agent still programs — under the hood, all of it is code execution. The reason code is the glue goes back to training: as people used coding tools, the traces went back into training to improve agent interactions. What makes programming uniquely tractable is that it's measurable — an engineer puts in a task and there's a clear reward signal: did we commit or throw it away? Text quality, by contrast, is nearly impossible to score at that scale (occasional A/B prompts, engagement metrics).

The practical upshot: give an LLM a calculator — a calculator is basically a programming language — and it can sum the largest numbers correctly, instead of being "the world's most inefficient calculator" that uses a lot of electricity and isn't verifiable. "That's where the value comes from. This is why increasingly every single problem seems to be an agent problem" — tiny programmable worlds.

🛡️ Gondolin: The Sandbox 22:53

If an agent has power, it will "do things it shouldn't be doing — unsurprisingly, because these models are capable of anything." So you need guardrails. Gondolin, his open-source sandbox, takes a Linux VM and puts it in a micro-VM (QEMU by default, with an optional krun backend), then keeps network and filesystem access under host-side policy control.

The design detail that matters: secrets are injected at the network edge, not into the agent. When the agent sends an HTTP request out, the agent itself never holds the token — so it "can't do anything stupid. It can still do a lot of stupid stuff, to be clear — but less stupid stuff, because it can't retrieve the token." That's one example of a "programmable world": the agent sits there and executes, but everything it does runs inside a sandbox.

👥 Human-Friendly Agent Code Bases 24:50

There are plenty of talks about "agent-friendly" code bases. His inversion: with a modern model, you don't need an agent-friendly code base for the agent to program in it — you need it to understand what the hell the agent is doing in there. We're shipping at inference speed and losing the ability to understand, so we need a way back in. (The principle generalizes beyond coding: even deep-research with ChatGPT requires you to think, because at the edges of a model's capability it draws wrong conclusions.)

Concretely, context-window limits mean a left-alone agent writes duplicated code left and right — it's "incapable of finding if it has done something before." Linters help (their team enforces everything through a DB layer and unique function names), but "the closer you get to the red-hot center of AI engineering, the weirder it gets." His exhibit: Anthropic bought Oven (Bun) and rewrote 600,000 lines of Zig into Rust in 7 days — "there's no way they're going to fully understand what the hell is going on. If you want to see what this looks like once people are completely out of the equation, that exists already. And that might very well be the future."

🔁 Staying in the Loop 28:31

So how do you stay in the loop? His team built a code-review extension for Pi in a two-pronged way: if something is genuinely mechanical — a missing semicolon, a compiler error — the LLM judges it mechanical and just fixes it. But there are specific call-outs for humans: a dependency was added, an SQL migration changed — the things they want to be involved with, "so that a reviewer, when they reduce the review extension, is at least kicked back into gear and starts to think about this."

One unlock he genuinely loves: a crappy, indecipherable bug report with no repro case — the kind that would have taken a day or two to recreate — the machine can now build the repro case for him. "It's code that never has to be seen again, because I just need this repro case once, and then I do something myself." That's the good side of the tool: "get this crappy out of the way, and then let me be the judge."

🧭 Friction: Without It You Can't Steer 31:57

The closing idea is the thesis of the whole talk, and it reframes a lifelong engineering instinct: "without friction, you can't steer." Engineers hate friction — but "once the friction is gone, you'll hate it even more," because the volume of AI-generated stuff flowing into public and internal code bases needs something pushing back. The real skill is separating bad friction (manually recreating repro cases) from good friction (review call-outs, SLOs).

His SLO example is the concrete mechanism: a service-level objective is "basically a checklist" that forces you to ask how critical a service is and whether it'll wake you at 2 a.m. — people hate filling them out (some now use an agent to fill out the form), but the act of filling it out is the point, because it makes you think. And the Twitter stories of "the agent threw me into the production database" are exactly backwards as brags: "something went wrong in your process if the agent had the power to do that." There has to be friction — and figuring out where to put it, and where to remove it, is the engineering work left to do.

💡 Key Takeaways

1. An agent is an LLM with a tool loop. The infrastructure that runs it is better called a harness — and agency should rest with the human, not the machine.
2. Output ≠ understanding. "Just because you can produce a lot of output doesn't mean you develop a lot of understanding." Core infra with no human who understands it is a liability — and a token dependency.
3. Agent psychosis is real and visible. 450 random commits, 664K changed lines, ~$1,200 in tokens — into someone else's open-source project, "because it can."
4. Expectations flipped after Christmas. Free tokens + holiday time turned "I built a product over break" into "ship code like crazy," and the industry went mad.
5. Code review is the new bottleneck. Generation is cheap; review isn't — and killing the review process to keep the speed is how you lose the ability to maintain your own stuff.
6. Code is all you need. Every agent is code execution under the hood, and code is measurable — which is why coding agents improve faster than anything else.
7. Sandbox the power, not the agent. Gondolin puts agents in a micro-VM and injects secrets at the network edge, so the agent never holds the token.
8. Make code bases human-friendly, not agent-friendly. The agent can program in anything; the point is understanding what it did.
9. Two-pronged review. Mechanical fixes self-apply; dependencies and migrations trigger a human call-out.
10. Without friction, you can't steer. Remove the bad friction (repro cases), add the good (review gates, SLOs) — that's the engineering work left.

🔗 Resources & Links

• 🛡️ github.com/earendil-works/gondolin — the open-source micro-VM agent sandbox
• 🌐 pi.dev — the Pi coding agent (Mario Zechner's harness, now at Earendil)
• 🐍 flask.palletsprojects.com — Flask, the library that started it all (and got him the strange emails)

Source talk: youtube.com/watch?v=u_k9cwDNPcM (CodeCrafts 2026). Note: the auto-transcript renders "Earendil" as "Arendelle" and "Jinja2" as "Ginger" — corrected here.

⏱️ Timestamp Index