What you're missing is rarely a tool

I went into those five hours of DHH with a shopping list in my head. Which tools does he use, what am I missing, what do I install tonight. I came out with a list of three things, and none of them can be installed.

That is an uncomfortable result, because it is far nicer to hear you are missing a tool. A tool you buy. A habit you have to introduce, and that is work.

Let me be honest about where I stood. I have been running several agents at once for months, each in its own git worktree so they cannot touch each other's files, with one overview showing which is working, which is blocked and which is done. If one gets stuck, I get a ping.

DHH describes exactly that, only in a terminal: tmux with panes, now with a layer that adds agent status, and a sidebar that rolls up per project to show who needs him. Different shell, same machine underneath.

That is the first thing I want to correct, because this episode gets written about as though he is an era ahead. Four mini PCs in a closet and sixteen parallel threads sound impressive, but he says himself that it is not sustainable and that the human is the bottleneck, not the hardware. The number is not the achievement. The shape of the work is.

His standard way of working is too dull to sound exciting and too good to ignore. One model does the work, a different model checks it. He builds with Claude, has Codex review on its highest setting, and recently added a third. Not because the first model is bad, but because a model with different training sees different things.

He cites a study Shopify's CTO ran against real production incidents: pull requests reviewed by agents caused fewer outages than those reviewed by humans. We found something comparable in research across 25,000 pull requests: writing is not the bottleneck, reviewing is.

Why I wasn't doing this is exactly why it works. Once you stop typing the code yourself, you lose the feel for where it can go wrong — you read a two-hundred-line diff and mostly notice that it looks tidy. A second model has no such feel either, but it has patience, and no ego about work it did not produce. It costs two minutes per job. From this week it is a fixed step at the end of every job.

This is the real difference, and it is not a matter of degree but of kind. DHH is building a bot that works through his pull requests and issues overnight, each in an isolated environment, and sends him one email in the morning: these twelve are ready, I would close these. He is no longer in the loop. He is after it.

My setup is fully synchronous. Nothing happens when I am not looking. Sixteen agents or three makes no difference there — as long as every step waits for me, I am the clock of the whole system.

That is also where the scaling story turns. Adding agents helps up to the point where you can no longer keep up with the decisions, and that point is lower than you would think: two, three at a time. Beyond it you do not go faster, you just pay less attention. The only way up is not more parallelism but fewer moments where the work has to wait for you.

The sharpest observation in the episode comes from an experiment at his own company, where they put agents into their project tool as colleagues and assign them to-dos instead of chatting with them. His conclusion: a chat window invites you to wait. It looks like a conversation, so you stay until the answer arrives.

An assigned task does not. You assign it and walk away. Same work, same model, different shape — and that shape decides whether you sit next to it.

Two things from those five hours are spectacular and not my problem. The four machines in a closet, joined by a private network, with sixteen threads spread across them: fun, but it solves a bottleneck I do not have. And his own Linux distribution, where an agent can rebuild not just your code but your entire operating system — that malleability is real, and it is a hobby argument, not a productivity one.

That distinction matters more than it sounds. The biggest risk with this episode is copying the spectacle and leaving the habit.

The question I get most often in AI consultancy is which tools a team should have. Almost always the answer is: you already have them. What is missing is the process around them — who reviews it, what happens when nobody is looking, and how you stop one person becoming the clock for the whole team.

It is also why code is getting cheap and engineering isn't. Generating costs almost nothing now. Reviewing, integrating and operating cost exactly what they always did, and that is what we work on in tech consultancy. Whether it then genuinely goes faster rather than merely busier is a measurement question — that is what Agile Analytics is for.

My own list for the coming weeks is short: every job past a second model, and find the first piece of work that can run overnight without me sitting beside it. Neither is in an App Store.

Running into this in your own team — agents running, but a process still waiting on one person? Get in touch. Bring how you work today rather than a list of tools; it makes for a better conversation.