When thinking about automation, don't consider only how long the task takes, but also the steps you already automated that sit between manual steps. For example, creating a PR takes almost no time, but it seats between coding and automated reviews, checks and tests. Automating PR creation isn't just about the seconds it takes to run a `gh` command, but about removing a choke point that requires no decision making. The human developer only needs to engage again once the confidence in the quality of the code is higher. In AI time even 5 mins waiting for a human to notice a message, is a lifetime of possible progress. Humans are poor multi-threaders. Even if I could mentally multi-task, while I'm creating a PR (or any other task), I can't be physically doing something else. This increases the chance agents are going to be waiting. Profile an agentic workflow and you’d see the classic signature of a process blocked on I/O: very little CPU time, lots of wall-clock time. The agent isn’t slow, it’s just waiting for humans (the I/O). [Amdahl's law](https://en.wikipedia.org/wiki/Amdahl%27s_law) puts a ceiling on this. If a task takes *two hours* from nothing to an automatically reviewed PR, and Agents could make everything *infinitely fast*, except the five minutes it takes me to notice it’s waiting to create a PR, the best speed-up I can possibly get is 24×. Not with today’s models, with any model! 24x sounds like a lot, but we're talking about infinite speedups otherwise here. And that’s with one agent, you’re likely running several agents at the same time. Let’s take an impossible ideal case. Since everything else has been infinitely optimised, the only thing left to do is run the PR creation command. Let's say it takes 1 minute (the command and some task switching overhead), and because everything else is so fast, agents keep producing more and more PRs. This is now a queueing problem. Every agent needs some attention, one at a time, and [queues behave badly as they fill up](https://en.wikipedia.org/wiki/Kingman%27s_formula). How long does each one wait before I get to it? That depends on how busy I am. ![[Pasted image 20261101213906.png]] Busyness increases as I deal with more incoming PRs. So if we say at 50% I can deal with 30 PRs an hour, at 90% we can deal with 54 PRs. We increased our throughput by 80% but an agent waits 9 times the task length! A 5-minute review or a 1-minute command doesn't matter here, the ratio is the same. This makes sense intuitively, as I'm busier I have less capacity to handle more agents, and there are more agents to handle. For the curious, this is the simplest queueing model: $W = S \times \frac{\rho}{1 - \rho}$ $W$ is the average wait, $S$ the task time, and $\rho$ how busy I am, and as my idle time ($1 - \rho$) approaches zero, the $W$ **explodes**. **More agents don’t just mean more work. They make every agent slower.** This wait time feeds directly into Amdahl's formula. With a single agent, a one-minute step capped each task’s speed-up at 120×, but at 90% busy, that same step costs ten minutes, nine waiting and one doing, and in the simplest model the best you could get drops to 12×. Same task, same minute of work, a tenth of the speed-up. Yes, you're shipping more PRs, but every minute an agent waits is that lifetime of progress again. --- Fortunately this is a ridiculous case, we have automated PR creation in agentic workflows, but if you stop to look around, I guarantee you'd be surprised by the choke points you may encounter that *weren't noticeable before because coding was slow*. They tend to hide behind "it only takes 2 clicks" and feel like it isn't worth automating. Actually, there’s a big one lurking, *manual code reviews*. The reasoning above should be enough to at least raise suspicions. As the time to fix bugs decreases to 0, manual PR reviews aren’t as valuable as they seem. How many automated checks can you run on the same code within the time it takes a human to finish? It doesn’t mean no human reviews of any kind, but these need to move to a different layer or target high value areas. Enough there for another article on reviews, CI and agent management, maybe another time. If you're feeling overwhelmed as the number of agents and decisions goes up, step back and consider your workflow. No one wants to be the bottleneck. It's possible you're hitting a ceiling, but it's also very likely to be a local ceiling, find [[the lift to the next floor]]. --- It also affects product design. If I leave a task running in the background and return later to check progress just to realise it is stuck awaiting some confirmation (yes, I'm looking at you [Claude Code](https://claude.com/product/claude-code)), not a great experience. What are the choke points in the problem you're currently solving?