Compile-Time Came Back

There’s an old xkcd where two people sword-fight across the office because “the code’s compiling.” (If you started programming after compiles got fast, that joke is a historical document.) For a long stretch the dead time it’s making fun of mostly went away. Interpreters, fast incremental builds, hot reload. You typed, you saw the result, you typed again. The loop was tight enough that you just stayed inside it.

Agentic coding brought the dead time back.

When I hand a task to Claude Code or Codex, I dispatch it and then I wait. Not a sword-fight’s worth of waiting, but real waiting, minutes at a time, long enough that staring at the terminal is a waste. What I’m waiting on isn’t a compiler turning source into a binary, but the shape of it is identical: I’ve kicked off a job, I’m blocked on it, and there’s nothing useful to do on this particular thread until it comes back.

So you do what everyone did during long compiles. You context-switch; you go do something else while the loop runs. I used to say the best thing about commercials was that they gave you time to kick off the next build, and I still basically live that way: TV on while the agents run, nothing that needs real attention (so, not sports), and a 42-minute episode that somehow takes me 2+ hours to watch.

And this is where it stops being a nostalgia bit. Once you have one loop running with dead time in it, the obvious move is to start a second one, and then a third. I’ll have an agent working an issue in one project, another doing a refactor in a second, and I’m reading a PR in a third while both of those run. (It is not as smooth as that sounds, but more on that in a second.) The single-threaded “me and this codebase” workflow turns into me time-slicing across a handful of blocked jobs, which is to say the human turned into the scheduler.

That’s the shift, and it isn’t the one the tools advertise. The pitch is that they write the code. Fine, they do. But the part that reorganized my day isn’t the writing, it’s that I now sit at the top of a little run-queue, deciding which blocked job gets attention when it unblocks and trying not to lose the context I had loaded on each one. The context-switch cost is real, and it’s mine: the reason it doesn’t feel as smooth as it sounds is that I am the expensive context switch, not the agents.

It also moves the bottleneck. It used to be typing speed, then it was thinking speed, and now, with four of these running at once, each with its own sub-agents, the binding constraint is my own context-switching capacity. How many independent threads can I hold in my head before I drop one? The machine isn’t the bottleneck in that picture. I am.

I happen to be good at this, which I credit to learning the trade when the inner loop was slow enough that waiting was most of the job. But being good at it doesn’t save you, because the context-switching changed shape. Waiting on a compiler, you held two contexts for a long time. Waiting on four agents, you hold a lot of contexts for short, ragged stretches, and you pay the switch cost over and over. It isn’t that I can’t juggle them. It’s that this is too many threads for anyone, and I don’t know what someone who never had the slow loop does with it at all.

I think that is where this goes. If the bottleneck is a human hand-scheduling a pile of agents, the fix isn’t to get better at it; the answer to too many processes was never to make the user switch faster, it was to build a scheduler. So you build the layer that does the scheduling, the thing that tracks what each job is doing and notices which one needs you next. That is the interesting thing to be working on right now, and it is not a prompt.