I have started noticing many small gaps in my working day. An analysis is running, a coding agent is implementing something, or research will be ready later.
I do not need to watch any of this happen, so I can move to something else and let several pieces of work advance at the same time. That freedom also creates a temptation: when I can delegate another substantial task in less than a minute, waiting becomes difficult to justify, so I start another one.
Waiting used to limit work in progress
Software work has always involved waiting. Builds run, pull requests need review, data arrives late and other teams take time to answer. Starting something new still had a cost of its own, though. I needed enough uninterrupted time to collect information, establish context and perhaps involve other people, and that friction naturally limited how much work I kept active.
AI reduces that cost considerably. I can describe a problem, provide the relevant context and ask for an analysis or implementation. Then, while I wait, I can repeat the process somewhere else.
The pattern is simple: start, delegate, wait, then start something else. It does not look inefficient, which is precisely why the number of active threads can grow before I notice a problem.
How many different threads can my mind keep up with?
Context switching can hide the queue
I have always considered myself good at context switching. Moving between problems does not bother me much, and in Product it is often unavoidable.
At first, this way of working suits me. An analysis can run while a pull request waits for review, another agent investigates a problem and I begin writing something else. The cost becomes visible later, when those results return and all require my attention.
I still have to read the analysis, understand the implementation, decide whether the proposal is good and notice when two reasonable results contradict each other. Being comfortable moving between threads does not help me understand them faster. Execution may happen in parallel, but review and understanding still compete for the same attention.
Starting got cheaper than finishing
Launching another investigation, implementation or document is cheap, while finishing still requires judgment. I need to compare alternatives, check assumptions, resolve contradictions and eventually decide that the work is actually done.
Work can therefore enter the system much faster than I can review and integrate it. AI helps me process an existing workload, but at the same time it makes it easy to create more work for myself.
A question can return as a substantial answer, and a possible improvement can become an implementation waiting for review. Each task may be useful on its own, even as the queue they create becomes difficult to absorb.
Parallel work can fragment reality
The number of open tasks is not the only cost. Different threads may evolve from different versions of reality.
An analysis may start with one set of assumptions. While it runs, another investigation produces new information and I make a decision based on it. An implementation launched earlier can still return using the original assumptions.
None of those pieces of work has necessarily failed, and each result may make sense on its own. Together, however, they may no longer form a coherent whole. I then have to reconstruct why something started, what was known at the time and whether one result has made another stale.
This integration work becomes more important as execution becomes more parallel, although it only appears after the visible work looks complete.
A personal limit on unfinished work
Software teams have used work-in-progress limits for a long time because more simultaneous activity does not necessarily improve flow. AI-assisted individual work may need something similar.
Parallel execution remains one of the most useful capabilities AI gives me, but it is only useful while I can absorb what comes back. A personal limit would protect the part of the process that remains serial: review, integration and judgment.
In practice, that might mean finishing a review before launching another exploration, periodically stopping to integrate returned work, or accepting that an available agent does not imply that another task should be running.
I have not found the right limit yet. For now, I am trying to notice how many unfinished threads I already have open before I start another one.
