The Models Are Dead: Thorsten Ball on Why Babysitting AI Coding Agents Is Already Over

Thorsten Ball is a founding engineer at AMP and the author of the well-known Writing An Interpreter In Go / Writing A Compiler In Go books. In a recent long-form conversation on the David Ondrej podcast, he laid out a blunt argument: the era of carefully babysitting individual AI models is already over, and most teams are still working like it's not.

Here's what stood out - and what it means for how NexAi thinks about building with AI agents.

"The models are dead" - and it's not what it sounds like

Ball's claim isn't that AI models are getting worse or that they don't matter. It's the opposite: they're good enough now that obsessing over which model you use, or micromanaging how it writes a single function, is a waste of time.

"I don't have to watch a model and go 'don't change this file' anymore," he says. "There's diminishing returns to this close-up managing of what a single model does." His framing: you get a button that spawns a senior engineer who writes the code for you. That engineer won't make syntax mistakes. It will do exactly what you ask. The real bottleneck moves entirely to what you tell it to do - not how you supervise it while it works.

Contribution graphs are dead, and code is getting cheap

One of the more uncomfortable claims: GitHub contribution graphs - the little green squares that have functioned as a proxy for developer productivity for over a decade - "aren't worth anything anymore." If 99% of a codebase's lines are written by AI, a graph counting commits measures almost nothing about the value being created.

The deeper point is about cost. Code itself is becoming cheap to produce. What's expensive - and valuable - is knowing what to build, for whom, and why. Ball predicts this will hit open source hard, since a large part of its value historically came from visible, hard-won contribution history.

Stop parking bugs in a backlog - spawn an agent instead

One of the sharpest points is about workflow, not technology. The old pattern: someone reports a bug, it gets filed, it sits in a backlog until someone has time, and then an engineer looks at it.

Ball's argument: that entire queue is now unnecessary friction. "Why don't you optimistically spawn these agents and have them parked somewhere, then go through and look at the fixes?" The agent already runs its own tests in an isolated sandbox before you even look at the result. You're not estimating whether something is worth doing before you do it - you just let it run in the background and review the outcome. A lot of process that existed to manage engineers' scarce time doesn't make sense when the constraint is gone.

Slop is a human problem, not an AI one

Ball pushes back hard on the idea that AI-written code is inherently "slop." His view: "Most slop comes from humans not having good product [ideas]. They just, with AI, can build these trash products faster."

The distinction he draws is between execution and taste. AMP's product has visual details people compliment - like an animated status orb with dozens of hand-picked color and character variations. Ball didn't hand-code those variations; he asked AI to generate 15-20 versions and then picked the one he liked. The craft isn't in typing the code - it's in having an opinion about what's good and being willing to iterate until you find it. Skip that step, and you get slop regardless of whether a human or an AI typed the characters.

How he actually writes a prompt

Ball says he uses no custom slash commands, no skills, no MCP servers. His mental model is simple: an agent has exactly two sources of information - its training data (a senior engineer who's seen almost everything, but has no idea what's specific to your codebase or intent) and whatever's in the context window.

A vague prompt like "port this feature to the CLI" produces a generic result, because the model has to guess at everything you didn't say. His actual prompts read like a message to a colleague: point at the reference implementation, state the constraints you already know, name what should stay consistent, and say explicitly what you want researched versus decided already. The gap between a mediocre and a great output is almost never the model - it's how much real information made it into the prompt.

Orbs: packaging the agent, the context, and the change into one URL

AMP's newer feature, which Ball uses for "basically all" of his coding now, is called an orb: a remote sandboxed machine tied to a single conversation. The agent runs there, tests run there, and once the agent goes idle, the sandbox sleeps - it wakes back up the moment you type again. You can open the same orb from your phone, a browser, or a terminal.

The part he considers genuinely new: the computation that produced a change, the context that shaped it, and the resulting diff all live behind one shareable URL. Compare that to the old model of a local branch plus a separate CI pipeline plus a PR description that only partially explains why a change was made. A teammate can open the URL, see the full reasoning trail, and take over the last 10% themselves.

He also points out this kills most of the old objections to cloud-based development - latency, missing keybindings, no local terminal access. Those complaints mattered when you were waiting on a human typing speed. They stop mattering once you're waiting on tokens per second and reviewing results asynchronously anyway.

What this means if you're building something new

Ball's advice for a new AI-era product isn't technical - it's about where code sits in the value chain. His example: instead of building yet another admin form so a human can manually edit prices, let the person just hand the agent a photo of a new menu and say "update the pricing." A lot of internal tooling that existed purely so humans wouldn't have to touch code directly is now more efficiently replaced by an agent that touches the code directly, on demand.

The practical questions he says matter more than model selection: What's your market, who's the customer, what workflow are you actually replacing, and how agent-friendly is your codebase and information? Get those right, and the model underneath becomes a commodity choice - pick a strong one, don't overthink it, and spend your attention on the problem instead.

The takeaway

None of this is really about a specific model release. It's a mindset shift: stop treating agents like fragile juniors that need constant supervision, stop routing every fix through a backlog built for human bandwidth, and stop assuming code quality and "AI-written" are opposites. The craft moves from typing syntax to having good taste, feeding agents real information, and deciding when to hit ship.