Starting a piece of work costs nothing now. That’s the real change, and most of what feels strange about a workday in 2026 falls out of that one fact.
There’s a chart everyone in this industry has seen: xkcd’s Is It Worth the Time, the grid that tells you how long you get to spend automating something before the automation costs more than it saves. Shave thirty seconds off a task you do daily and, across the five years the chart runs, you’ve earned twelve hours of build time. It’s a good chart. The arithmetic is honest.
It was also always wrong about the unit, in a way that didn’t matter until now. Automating a thirty-second task never really bought you thirty seconds. It bought you the sentence you didn’t lose while you copied the file, and the decision you didn’t postpone because you’d gotten up to go do a chore. The savings were never denominated in seconds. They were denominated in switches you didn’t have to make.
AI took that footnote and made it the whole story.
What actually got cheap#
Two years ago, starting a second thread of work had real setup cost. Commit or stash what you had, switch branches, wait for the install to settle, rebuild your mental model of the other thing. That cost was annoying, and it was also load-bearing. It made you finish, because starting something new was expensive enough that you wouldn’t do it on a whim.
Now it’s git worktree add, a fresh checkout in seconds, and an agent pointed at it with a paragraph of instruction. I only learned worktrees because the agent tooling made me; the command had been sitting in git for years and I’d never needed it. Setup stopped being a barrier at all. Opening a new front now costs about as long as it takes to describe what you want.
When starting is that cheap, you start everything. Of course you do. Trying the idea now costs less than writing it down for later.
The day I counted#
In January I had four agent sessions running at once. I made a note about it at the time, and the rhythm went like this: read what the first one produced, give it the next instruction, flip to the second, review, instruct, flip to the third, and by the time I came back around to the first I’d half-forgotten what I’d asked for. That forgetting is the tax. It gets paid on every single flip, and each individual payment is small enough that you never notice writing the check.
Here’s the part that took me longer to admit. Three of those four sessions weren’t running. They were stopped, waiting on me to look at something. I had four threads in flight and exactly one reviewer, and the reviewer was the same guy who kept opening threads.
It felt productive. Four things in flight looks like four times the output, right up until you ask which of the four actually moved.
Work in progress is not throughput#
This part isn’t a matter of taste. Queueing theory has a flat answer, and it’s the one every kanban board is built around: for a system with fixed capacity, how long items take to get through, on average, is proportional to how many items are in the system. Little’s Law. Cycle time equals work in progress divided by throughput. Add work in progress without adding capacity and you don’t get more done, you get the same amount done later, with every item sitting in a queue longer than it needed to.
Your capacity in an agent-heavy workflow is not the model. It’s your review attention, and there’s one of you. Ten branches don’t parallelize that. They queue against it. The agents genuinely do run in parallel, which is exactly what makes the illusion convincing, but they all converge on a single serial resource the moment they need a human to say “yes, that, keep going.”
So the dashboard in your head reads four things in flight and reports it as four times the output. What’s actually true is that you have four things aging.
Where parallel is genuinely right#
Some work really does split, and I don’t want to argue against the cases where it does. If three threads are independent, need no decision from me in the middle, and I’m content to review all three at the end, running them at once is free money. A long test suite. A dependency bump across three repos. A spike I already plan to throw away.
The test isn’t whether the tasks are different. It’s whether the tasks will want me at the same time. If two threads both need judgment in the next twenty minutes, they aren’t parallel. They’re a queue with extra steps.
What I’m working on#
A cap, and a low one. Two active threads. Not a philosophy, a number, because philosophies bend at 4pm and numbers don’t. That’s the rule. Holding it on an afternoon when the third idea is the interesting one is the part I keep failing.
Batch the switches. The agent isn’t in a hurry, and the notification isn’t an interrupt, it’s a queue entry. Finish the thought you’re holding, then flip. The gap while you do that is DMN-time, and refilling it with another thread burns the only minutes that ever hand you a decent idea.
“Started” counts as zero. Nothing gets credit for being in flight. Four things at 80% ship exactly as much as zero things, and they cost four times the attention to get there.
The leverage is real and I’m not giving it back. The discipline to not strand four threads is the part I’m still building.
But the tools got very good at the first ten percent, and starting is solved now in a way it has never been solved before. Nobody has shipped the thing that finishes. I don’t think anyone will, because finishing was never a typing problem. It’s a deciding problem, and the deciding is still mine.
