Toxic flow: why multi-agent coding is addictive, exhausting and nothing like real flow

The state that feels like peak productivity but leaves you worse than when you started

Last Thursday, I had five agents running in parallel. Two were writing code, one was updating specs, one was researching for new features, and the fifth was refactoring a service layer. My terminal looked like a mission control dashboard. Output streamed in from every direction. I felt as though I was operating at ten times normal speed.

By 2 pm, I was mentally destroyed. Not tired in the way you get after a hard day of focused coding. Destroyed in the way you feel after four hours of air traffic control. I had approved at least two diffs without reading them. I could not remember what agent three was working on. And I felt anxious in a way that good programming flow never produces.

I call this toxic flow. It mimics Csikszentmihalyi’s flow state: total immersion, time distortion, and a sense of control. But it produces exhaustion instead of satisfaction, anxiety instead of calm and declining output quality instead of peak performance. From what I see among developers across the industry, it is becoming an epidemic.

Flow has a dark cousin

Mihaly Csikszentmihalyi defined flow in 1990 as the state where challenge and skill are balanced. You lose track of time. You feel effortless control. Afterwards, you feel energised and satisfied. Most experienced programmers know this state well. It is the reason many of us got into coding in the first place.

Toxic flow shares some of those surface characteristics. You lose track of time. You feel a sense of engagement and urgency. But the underlying dynamics are inverted.

In real flow, your skill matches the challenge. In toxic flow, the challenge exceeds your cognitive bandwidth. You are tracking more concurrent state than any human brain can handle. In real flow, feedback is intrinsic and meaningful. In toxic flow, feedback arrives so fast you cannot process it. In real flow, you feel calm afterwards. In toxic flow, you feel drained.

Csikszentmihalyi had a term for this: junk flow. Addictive flow states that feel engaging but produce neither growth nor satisfaction. Gambling researchers call a related phenomenon dark flow. Dixon et al. documented it in 2017, and Jeremy Howard from fast.ai applied the concept to vibe coding in early 2026.

But those terms describe the single-agent version. One developer, one AI, losing track of time. What I describe is the multi-agent variant, the cognitive overload that comes from supervising a swarm.

The addiction mechanism

The addiction signal from the developer community is hard to ignore.

Garry Tan, Y Combinator’s chief executive, [admitted publicly](https://x.com/garrytan): ‘So addicted to Claude Code, I stayed up 19 hours… I sleep four hours a night.’ Armin Ronacher, who created Flask, described spending two months in a state he called ‘agent psychosis’, marked by excessive prompting, no sleep and compulsive iteration. Steve Yegge runs what he calls ‘a practised escape plan every night to get my computer closed by 2 am.’

The pattern keeps repeating. On Hacker News, one commenter captured the comparison: ‘It’s MMO all over again.’ Another wrote: ‘After four hours of vibe coding, I feel as tired as a full day of manual coding.’

The mechanism is straightforward. Multi-agent coding delivers dopamine hits at superhuman speed. You fire off five agents, and within minutes, you are reviewing completed work. The reward cycle, writing code, testing it, and watching it work, normally takes hours. With agents, it compresses into seconds. Your brain receives the same reinforcement signal that makes slot machines effective: variable-ratio, high-frequency rewards.

And like slot machines, the compulsion is to keep going. One more agent. One more feature. The marginal cost of spinning up another parallel task feels close to zero. The cumulative cognitive cost is anything but.

The four cognitive loads

When you run one agent, you are the producer being assisted. When you run four, you become a manager, and the worst kind: one who must review the output of four workers producing at superhuman speed, with no ability to slow them down and an approval system that rewards speed over scrutiny.

Multi-agent toxic flow imposes four distinct cognitive loads that go beyond ordinary fatigue:

The tracking tax. Each agent has its own context, its own state, its own failure modes. At any moment, you need to know which agent is making progress, which is stuck in a loop, which has drifted off-task and which approval is urgent. This is air traffic control without the training, the tooling or the mandatory rest periods.

Simon Willison captured this in a post describing how he ran three agents while attending meetings: ‘It’s now 11.47am, and I am mentally exhausted.’ He was not tired from coding. He was tired from context-switching between agent states at a pace his working memory could not sustain.

Approval fatigue. The first five approval prompts get a careful review. By the twentieth, you are skimming. By the fiftieth, you are rubber-stamping. One developer described it bluntly: diffs were coming fast, multiple file tabs were opening, and it was easier to keep clicking ‘apply all’. This is not carelessness. It is a predictable cognitive response to sustained high-frequency decision demands.

The anxiety gap. Between prompts, there is a gap where agents are working, and you are waiting. This gap is too short to start meaningful work and too long to simply watch. Developers fill it by checking Hacker News, scrolling Twitter or starting another agent, each of which fragments attention further. As one developer put it: ‘Instead of developing, I’m code reviewing. Hard to get into a flow state when Claude is the one flowing, not me.’

The illusion of control. You set the prompts. You chose the orchestration pattern. You configured the sandbox. So it feels as though you are in control. But you are not. You are reacting to machine-speed output with human-speed cognition.

A BCG study of 1,488 workers published in March 2026 found that 14 per cent of AI-using workers reported what they called ‘AI brain fry’, with decision fatigue up 33 per cent and major errors up 39 per cent. Those numbers are from general AI-assisted work. Multi-agent development, where the cognitive demands are higher, is likely worse.

The perception gap

The most dangerous aspect of toxic flow is that it distorts your self-assessment.

The METR study, widely discussed in early 2026, found that experienced developers using AI tools were 19 per cent slower than developers working without them. But those same developers believed they were 20 per cent faster. That is a 40-point perception gap. The tool made them less productive while making them feel more productive.

Multi-agent workflows amplify this distortion. When you have five agents producing output, the volume of code is staggering. Your terminal fills with completed tasks. Your commit history grows. It looks as though you are producing at five times normal speed.

But output volume and productive output are different things. When your review bandwidth is saturated, when you approve diffs faster than you can read them, quality degrades invisibly. The bugs do not appear until next week. The architectural drift does not surface until the PR review. The subtle misunderstanding of requirements that agent four introduced in hour two does not emerge until a customer reports it.

An O’Reilly Radar article captured the collapse point vividly. A developer created 17 dashboard visualisations in three hours of agent-assisted flow, then made one more request, ‘add colour-blind accessibility’, and the AI restructured the entire codebase, breaking everything. Three hours of work vanished because the developer never committed, never paused, never created a checkpoint. They were flowing too fast to build safety nets.

High output volume masks declining quality, and the feeling of productive flow makes it almost impossible to notice in real time.

The risk spectrum

Not all multi-agent work produces toxic flow. The risk depends on how the orchestration is structured:

Low risk: wave-based execution with explicit checkpoints. Agents work in waves. Between waves, everything stops. You review completed work, commit and decide whether to proceed. The wave boundary is a natural circuit breaker that forces pause and reflection.

Medium risk: sequential gated chain. Agents work one at a time. You review each output before triggering the next stage. Cognitive load is manageable, but sustained attention is required for the full pipeline duration.

High risk: parallel swarm with real-time monitoring. Multiple agents work simultaneously. You watch all of them, approving and correcting as outputs arrive. High stimulus rate, no natural pauses and the monitoring-without-producing role that creates the tracking tax.

Extreme risk: unbounded parallelism without an aggregation plan. Agents spawned without a concurrency cap, no predefined completion criteria and results reviewed in real time rather than in batch. This is the multi-agent equivalent of playing an MMO without a logout timer.

The warning signs

I have been tracking my own patterns and talking to other developers who work with multi-agent setups. Here are the warning signs that you have crossed from productive parallel work into toxic flow:

You are approving without reading. This is the most common and most dangerous sign. The diff looks reasonable. The tests pass. You click approve. But you did not read the code. You trust the agent’s output the way you would trust a senior colleague’s code, but agents are not senior colleagues, and they fail in different, less predictable ways.

You cannot recall what an agent is doing. If someone asked you ‘what is agent three working on?’ and you needed to check, you have exceeded your cognitive tracking capacity. With two agents, most people can maintain a clear mental model. At four, it becomes unreliable. At six, you are guessing.

You feel anxious, not focused. Real flow produces a calm sense of control. Toxic flow produces a buzzing, vigilant anxiety, the feeling that something may be going wrong in one of your parallel threads, and you need to keep checking. This is the emotional signature of cognitive overload, not engagement.

You cannot stop. You have finished what you planned, but you keep going. One more agent. One more feature. The work expands to fill all available agent slots. If you have lost the ability to pause deliberately, you are in the addiction loop.

You are physically exhausted but have not moved. Multi-agent supervision burns glucose at a rate that cognitive work does not normally sustain. If you feel physically drained after a few hours of what was mostly reading and clicking approve, that is a signal.

What works

I have been experimenting with mitigation strategies for several months. The most effective mitigations are architectural, not psychological. Willpower is not a reliable defence against a superstimulus. Instead, design your orchestration patterns to create the pauses that toxic flow eliminates.

Cap your concurrency below your cognitive ceiling. Most tools let you run six or more agents in parallel. Most human brains can supervise two to three. The gap between what your tools allow and what your cognition supports is where toxic flow lives. I default to two concurrent agents now. Three if the tasks are independent and well-scoped.

Use wave-based execution, not continuous streaming. Instead of running agents constantly, work in waves. Launch two or three agents. Wait for them all to complete. Review the output. Then launch the next wave. This creates natural pause points where you can reset your cognitive state, assess quality and decide whether to continue. It is slower on paper but produces better outcomes.

Batch your reviews. Real-time review of streaming agent output is the fast track to approval fatigue. Let agents finish, then review all the output in a dedicated session where your only job is reading code carefully. Separate the supervising phase from the reviewing phase.

Set hard time limits. I use a 90-minute timer. When it goes off, I stop regardless of what is in progress. Agents can be paused. The work will still be there. The addictive pull of toxic flow makes this hard to do without an external signal.

Commit obsessively. The developer in the O’Reilly story lost three hours because they never committed. If you commit every 15 minutes, even messy work-in-progress commits you will squash later, you create rollback points that reduce the cost of stopping. When stopping feels expensive, you will not stop.

Adapt the Pomodoro technique to agent rhythms. The standard Pomodoro, 25 minutes of work then a five-minute break, has the right instinct but the wrong cadence for multi-agent work. Twenty-five minutes is too short for meaningful orchestration, and when the timer fires mid-wave with three agents producing output and one waiting for approval, stopping triggers more anxiety than it relieves. Use wave boundaries as your Pomodoro instead of a fixed timer. Launch a wave, let agents complete, review, and commit, then take a break. Extend the intervals to 45–60 minutes with a 10–15 minute break. Make the breaks hard: leave the room. Checking Slack or scrolling Hacker News does not count because you are still in the stimulus loop. And enforce one rule: every break starts with a git commit, which forces you to reach a stable state before stopping.

Track your approval quality. After a multi-agent session, read the diffs you approved. Count how many you would approve again after careful review. If that number drops below 80 per cent, you were in toxic flow and your concurrency is too high.

The paradox

There is an irony at the heart of multi-agent development. These tools exist to reduce developer toil, to take repetitive, tedious tasks off your plate so you can focus on the interesting problems. And they succeed at that. The output is real. The productivity gains are real. I ship faster with agents than without them.

But without deliberate pacing, the tools that promise to reduce cognitive load end up increasing psychological strain. The developer shifts from writing code to supervising a dashboard, and supervision at scale is one of the most cognitively demanding activities humans do. Air traffic controllers have mandatory rest periods for a reason.

The developers who get the most value from multi-agent workflows are not the ones running the most agents. They are the ones who understand their own cognitive limits and engineer their workflow to stay inside them. Two agents instead of six. Waves instead of streams. Hard stops instead of ‘just one more.’

Toxic flow is not a reason to avoid multi-agent coding. It is a reason to take your own cognitive architecture as seriously as you take your system architecture. The agent swarm does not need rest. You do.

Daniel Vaughan writes about agentic engineering, developer tooling and the human side of AI-assisted development. He is the author of ‘Codex CLI: Agentic Engineering from First Principles’ and builds with multi-agent systems daily.