The Phoenix Project Rises Again
I can run ten AI agents at once. I'm trying not to.
A friend brought up The Phoenix Project to me recently. Which was funny, because I was the one who recommended it to him eight years ago. Apparently the book had been sitting in both our heads, waiting for the right kind of chaos.
The book follows Bill Palmer as he tries to get a software organization drowning in work under control. Requests arrive faster than the teams can finish them, dependencies pile up, and everything eventually lands on Brent, the one engineer who seems to understand how the whole system works. Poor Brent.
The way out is not heroics or working harder. The book applies the Theory of Constraints to software work: find the bottleneck, protect it from interruptions, and organize the rest of the system around it. Adding capacity everywhere else does not make the system faster. It only creates a bigger queue in front of the constraint. The solution: Make the work visible, limit work in progress, and finish before starting more.
This spring, somewhere between my seventh terminal tab and my laptop fan doing its best jet engine impression, it hit me: The Phoenix Project was happening again. Except this time the whole organization fit inside my laptop, and I had somehow become both Bill Palmer and poor Brent.
Managers now, all of us
Once you start using AI agents for real work, part of your job turns into management.
You're still engineering, but you're also delegating, checking in, reviewing, unblocking, and every now and then discovering that your direct report has confidently done something completely different from what you asked for.
This spring and summer I've been thoroughly consumed by agents. Five at a time. Seven. On a good, or possibly bad, day, ten plus! Sometimes I grind my CPU and memory into dust, and do roughly the same to my mental RAM.
A lot of the time though, it feels amazing. Like conducting an orchestra. You fire off a refactor here, a bug fix there, and a research task in a third window. For a glorious twenty minutes everything hums and you feel like you've been handed superpowers.
But the times it doesn't feel like that are starting to take a toll. Jumping between seven half-finished conversations. Reviewing code you barely remember asking for. Trying to recall which branch is stacked on which, which test suite actually passed, and which agent is waiting for a review instead of more work.
In the end, I got an absurd amount done these last months, but the other day I started realizing the contours of a pattern. The more things I tried to keep moving in parallel, the smaller those things became. Refactors, bug fixes, bits of plumbing. All useful, and all easy to bounce between. Meanwhile, the work that mattered most was still sitting there, waiting for the kind of attention I was no longer giving anything.
At one point I found myself coding with AI on a boat in the open ocean between Flores and Bali, around Komodo National Park. Laptop open, sea on every side, still staring at the screen.
On the one hand, it was genuinely great. On the other, I was in one of the most beautiful places I had ever been, staring at my laptop. Looking back, I probably should have shut it down and enjoyed the ocean. All this extra productivity has been fun, but it has also made me more addicted to work, and to the screen, than ever. I suspect that also makes it easier to come back and focus on the work that actually moves the needle.
Komodo with agents. Santorini before them. Apparently the symptom predates the diagnosis.
The case for a personal WIP (work in progress) limit
In the book, the turning point comes when they stop starting and start finishing. Work in progress is the silent killer. Every extra item in flight makes everything slower, because the cost is not only in the tasks. It is in switching between them.
I see no reason this stops being true just because the workers are agents.
So I'm going to try something: an intentional WIP limit of two agents at a time. Max three. I think that is roughly the point where I can still hold the full context in my head, review the work properly, and choose what matters instead of inventing tasks to keep the machines busy.
My honest experience from this summer is that seven tasks at 60 percent done loses to three tasks actually finished. Every single time. More finished work is nice. The bigger benefit is leaving room for the larger project I might otherwise avoid because ten smaller tasks are easier to juggle. And hey, if I happen to line up the tasks so that all three are long running at the same time, I guess I can sit there and twiddle my thumbs for a bit, and actually think about the bigger picture. Or do some pushups. Either beats hunting for a new 4th and 5th task to run in parallel! Maybe I'll even take a walk outside and "touch grass"!
To make this less dependent on willpower, I've been building a little skill to keep me honest. I have a weakness for impulsive side tracks, after all. I call it Loopkeeper. It reads roughly the last 2,000 characters from every agent thread from the previous period and lets me know if I left anything unresolved. It also deterministically reads my various git branch and worktree stats from the file system and actively warns me if I'm about to launch into something new while I still have "loose threads" (see what I did there?).
That is what making work visible looks like in practice.
The token-burning Olympics
Not me. Yet.
The age of AI was supposed to give us abundance and freedom. Instead, I think many of us are more locked to the screen than ever.
In some circles I follow I've started noticing something like sportsmanship around it. How many tokens did you burn this week? How many agents do you have running? And the ultimate flex: how much did AI do for you while you slept?
Some overnight runs are genuinely useful. I'm not trying to be a Luddite here. But I want to make the case for the opposite move: don't go hunting for tasks to feed the machine before bed just because you can. If there's no natural task, there's no natural task.
Have the agent write a handoff summarizing where things stand, then close the lid.
Humans need sleep. Sometimes computers need to be restarted so memory can be released. Agent sessions need the same reset. A new thread is a new day.
In my experience, the handoff is worth more than the overnight run anyway. Future you gets a clean briefing instead of waking up to 40,000 lines of code to untangle before coffee.
At least whatever you do, don't rely on auto-compacting to carry you through a marathon session.
A compacted thread is like working with a colleague with amnesia. They remember fragments and sound confident, then casually reintroduce the bug you fixed together two hours ago.
Stop starting, start finishing
I want to get better at using these tools, not use them less. I think the people who get the most out of them over the next few years will be the ones who manage them well. Management is an old discipline with old lessons. It's just funny that a thirteen-year-old novel about a fictional auto parts company turned out to contain the operating manual.
I'll report back on how it goes. Knowing myself, there's a decent chance you'll find me in a month with nine terminals open, insisting this time is different. But hey, Bill Palmer didn't fix Parts Unlimited on the first try either.
Enjoy the rest of the summer, everyone!