atriumatrium
← All posts
·Jonny Asmar

AI Didn't Kill Your Flow State. Your Tooling Did.

The most upvoted complaint about AI coding isn't that it's wrong — it's that the work stopped feeling like anything. The research says the flow tax is real. But it's not the model's fault. It's the pile of terminals you bolted it onto.

Three agents working, one of them blocked on you, and you just alt-tabbed into a terminal you don't remember opening. You've been heads-down for hours — and you'd be hard pressed to say what you actually built. This was supposed to be the fun part.

A recent thread on r/programming gained quite a bit of traction: "AI coding killed my flow state." It's a few months old and still making the rounds. This isn't a news story, it's a realization landing on more people every week. Ask HN asked the same question less than a year ago. The people writing these are not AI skeptics. They're early adopters who wired up the agents, got the leverage they were promised, and then noticed something went missing. The work got faster, but the feeling of being in the work disappeared.

I want to make an argument that might sound like a dodge. Stick with me, though. I promise it’s not: AI didn't take your flow. The way we bolted AI onto our existing tools and workflows did. And to be precise about the target: this is about agentic coding — prompt, wait, review, redirect, often several agents at once. The supervisory kind, not the autocomplete kind.

A disclosure before I go on: I build a tool that argues for exactly this conclusion, so I'm about as biased as it gets. I'm going to make the case with the research anyway — judge it on the evidence, not on me.

The flow tax is real, and it shows up in the data

Let’s start with the part that isn't a vibe.

The most relevant study we have is from METR — a randomized controlled trial, sixteen experienced open-source developers, 246 real tasks on repos they already maintained, each task randomly assigned AI-allowed or not. The headline result was that they came out 19% slower with AI — even though they'd expected a 24% speedup, and even after finishing, still believed they'd gotten one. I won't hand you that number clean, though: METR themselves complicated it in a 2026 follow-up, where later data points toward a speedup and they concede the measurement gets unreliable once developers run several agents at once. So don't take 19% to the bank. What survives the walk-back is the part that matters here — the gap between how fast these developers felt and what the work actually showed. You can lose track of time in flow; that's a feature of it. But finish measurably slower, walk away sure you were faster, and the work has stopped giving you an honest read on your own pace. Flow runs on that read.

The rest of the numbers rhyme. Stack Overflow's 2025 survey found the top AI frustration — flagged by 66% of developers — is output that's "almost right, but not quite," and 45% said debugging AI-generated code is more time-consuming, not less. "Almost right but not quite" is the exact texture of broken flow: the thing that keeps yanking you back out just as you settle in. Atlassian's 2025 developer report makes the point from the other side: 99% of developers say AI saves them time, and yet half still lose 10+ hours a week to non-coding friction — context switching, hunting for information, waiting on other people. Codegen got faster; the work around it stayed exactly as fragmented. Devs in that report spend about 16% of their day actually writing code.

And the interruption math is brutal. Gloria Mark has tracked knowledge workers' screens for two decades, and in her book Attention Span she documents that average sustained attention on a single screen is now about 47 seconds — down from about two and a half minutes when she started. After an interruption, it takes roughly 25 minutes to get back to the original task. That 25 minutes isn't a tax you pay every time you glance at an agent — it's the shape of the failure: one "let me just check" becomes another tab, then another task, and the thread you were on resurfaces much later, if it resurfaces at all. Stack a few of those across an afternoon and there was no deep work to protect in the first place.

None of those studies measures flow directly — you can't put flow on a dashboard. What they measure is what flow runs on: fast feedback, unbroken attention, and a read on your own progress you can trust. Those are the first things to go when the work turns into prompt-and-wait.

Why the loop eats flow

Mihaly Csikszentmihalyi named the conditions for flow fifty years ago:

  • A clear goal
  • Immediate feedback
  • A task hard enough to hold you without breaking you
None of these are negotiable, and the agent loop quietly violates all three.

Feedback stops being immediate the second your agent starts "discombobulating." That wait is the assassin — too long to hold the thread, too short to start anything real. So you drift. To the thread, to the phone, to a different tab.

The challenge-skill balance inverts. The work stops being make the thing and becomes check the thing, one agent at a time. Creating is flow-shaped. Babysitting a single agent through its diff is not. Twenty years into a career he loved, one commenter wrote: "the biggest thing agentic coding has achieved is suck the fun out of it. I am bored for the first time in my career."

And the goal goes fuzzy because you stop holding the mental model. You didn't write it, so you don't quite own it. Microsoft and Carnegie Mellon surveyed 319 knowledge workers last year and found the more you trust the AI, the less critical thinking you do; the work shifts from generating to verifying, and the muscle goes quiet.

Then there's the loop itself. Marcus Hutchins described it better than I can: LLMs "give the same feeling of achievement one would get from doing the work themselves, but without any of the heavy lifting." A developer named xadram, on HN, put it bluntly: "There is zero flow and I just end up in yolo mode pulling that slot machine — 'yes and don't ask again.'"

That's the real diagnosis. Not flow. A reward loop wearing flow's clothing.

It's not AI. It's the pile.

I promised you this wasn’t a dodge, and here’s where I make good on that.

Some of this really is the model. It hallucinated, it stalled, it handed you 800 lines you now have to read line by line — tooling didn't invent any of that, and I'm not going to pretend it did. But the model's failures turn into flow failures because of where they land: the waiting has nowhere to go, the review shows up stripped of its context, and the thread is in pieces by the time control comes back to you. Claude isn't what makes your afternoon hollow. Neither is GPT, or Gemini, or whatever you've wired in. The pile they're sitting in is.

Look at where your agents actually live right now. A stack of terminal windows you've lost count of. A tmux session you're afraid to touch. A bottom panel in VSCode you thought was just meant for the occasional npm run dev.

A mental map of which-agent-is-doing-what. A slew of refugee CLI agents with no home. That setup works for a couple of agents. In my experience it starts breaking down around four or five. And every coping mechanism it forces on you — alt-tabbing to find the one that's waiting, scrolling back to remember what you asked it, opening a dropdown to find the original user prompt you think started the thread... rebuilding the whole picture from scratch every time you context switch — is an interruption. You’re living in an interruption machine and wondering where your flow went.

The job changed, but the tooling didn't change with it. You're not writing one function anymore; you're running a small team.

Disappearing isn't flow either

There are two tempting ways out, and both make it worse.

One is to go back. Close the agents, write it all yourself, get your quiet back. It works — and it's a retreat. You hand back the leverage that made you reach for the agents in the first place, but that leverage is real, and that's why this is such an impossible decision to make.

The other is the dream the orchestration crowd is selling: hand it all off. Fully autonomous. Queue the work, walk away, come back to a finished PR. But when you actually walk away, you lose the thread. And the thread is where flow lives. You come back to a diff you don't understand, no feedback loop, no sense of control, none of the conditions flow needs. This is for the stuff we don’t want to do, not the part that made us love building to begin with.

Disappearing isn't flow. It's just a slower way to lose the plot.

Flow isn't at either end. It's in the middle. The point was never to go back, nor to disappear.

The point is to stay close enough to matter.

Flow didn't die. It moved up a level.

Here's the part the "just go back to hand-coding" crowd misses. The old flow — the one everyone's grieving — lived down in the code: write a line, run it, see it, adjust, repeat. That loop is mostly gone for the kind of work agents do well, and it isn't coming back. But flow didn't die with it. It just moved up an altitude.

The job now is closer to conducting than typing. You're not in the function; you're directing the things writing the functions. And that altitude has its own flow, built from the exact parts Csikszentmihalyi named — a clear goal, fast feedback, a challenge that matches your skill. The challenge just changed shape. It used to be "solve the hard problem." Now it's "hold ten agents coherent and moving towards a common goal without losing the thread of any of them." Get that balance right and it is the most absorbing the work has ever been. Get it wrong — which the pile guarantees — and it's just noise disguised as "cogitating."

It isn't only about writing code either. Step back to the slower, harder work — architecture, system design, the upstream thinking that decides whether the rest is even worth doing — and the same thing happens. One agent, and you're back to prompt-and-wait. But hold a live conversation across several at once — one mapping the data model, one stress-testing the failure modes, one digging through how the existing system actually behaves — and the back-and-forth stops being a bottleneck and starts being a flow of its own. You think at the speed of the question instead of the speed of one reply. Every holding pattern with one agent turns into prompting time with another.

I've been writing software for 25 years. I'm not romantic about the old way, and I don't spook easily at a new tool. Using atrium is the first time in the agentic era I felt like I got my flow state back — not because the agents got out of my way, but because I finally had somewhere to stand while they worked.

One thing this isn't: an argument to use less AI. If autocomplete or one focused agent is your whole workflow and your flow's intact, you're done — keep it. This is for the spot a lot of us are already in: the leverage got real enough that we keep three, five, a dozen agents running, but the workspace around them still assumes one human, at one terminal, holding one thread. The honest objection isn't "agents or flow." It's whether the new job — supervising the fleet — can have the same clarity and feedback the old one did. I think it can. Just not from inside a pile of terminals.

What actually gets flow back

So I stopped fighting the pile and built a room instead — for the agents you already run, whichever they are. Not to replace them, not to hide them: to give them a place to live, and give me one place to stand and step in where and when I needed to. The difference between babysitting and conducting is the room you do it in. None of what follows is hand-waving. Here's each thing the loop broke, and the specific thing that puts it back.

The dead air. The single most-cited fix in that whole HN thread came from a developer named noodletheworld: "the key to maintaining flow is having a second clone... where you can keep doing work after you kick the agent off." That's the entire idea behind launching every task into its own room. Kick one agent off, slide to the next, keep moving — the wait stops being dead air because there's always another live thread to step into. Fan out as many as you have ideas; opt into worktree isolation and the branches don't collide, the diffs don't drift, the agents don't fight over the same files.

The hunting. One sidebar tracks every agent across every room and workspace — working, waiting, parked, blocked. It pulls you back only when one is actually waiting on you, not every time it speaks. You stop alt-tabbing to find the agent that needs you. atrium tells you.

The "where was I." Every session you've ever run is indexed — locally, with controls for what's included — and backfilled into a timeline: your prompts, the replies, the commits, grouped by day, fully searchable. The fix an agent made at 2 AM while you were asleep is keystrokes away, sitting next to the prompt that caused it. You don't have to hold the whole mental model in your head, because the room holds it for you.

The reset. Every pane, branch, terminal, and agent session writes itself to disk as you work. Crash it, reboot it, come back Monday — the room is still there. The reconstruction tax after an interruption — that long climb back into the context you'd lost — stops being a thing that happens to you.

None of those are AI features. They're the opposite. They're the boring, durable, un-magical scaffolding that lets you keep the agents close without drowning in them.

The Reddit thread was right about the symptom, but wrong about the cause. AI coding didn't kill your flow. Running a fleet of agents through tooling built for single-threaded execution did. Fix the room and the flow comes back — not because the agents got quieter, but because you finally have somewhere to stand while they work.


Sources

  1. "AI coding killed my flow state" — the r/programming thread this piece responds to.
  2. Ask HN: Do you struggle with flow state when using AI assisted coding tools? — the developer quotes come from here: xadram, noodletheworld, and donatj.
  3. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, July 2025 (the 19% slower / 24% expected / 20% perceived figures), and its 2026 follow-up complicating the result.
  4. 2025 Developer Survey — AI — Stack Overflow ("almost right, but not quite"; the debugging-time figure).
  5. State of Developer Experience 2025 — Atlassian (time saved vs. friction lost; 16% of the day coding).
  6. Can't pay attention? You're not alone — University of California, on Gloria Mark's research and the 47-second attention figure.
  7. The Impact of Generative AI on Critical Thinking — Microsoft Research & Carnegie Mellon, CHI 2025.
  8. Every Reason Why I Hate AI and You Should Too — Marcus Hutchins (MalwareTech).