jd:/dev/blog_
· 5 min read

The Flow Is Gone

I used to hold entire systems in my head. Now I hold seven terminals. The trade was worth it, but something real got lost.

Illustration of a developer losing flow state

I have seven Claude Code terminals open right now. Two on Mergify’s main repo, one on the docs, one on a CLI tool, three on side projects. Each one is mid-task, waiting for me to answer a question, approve a command, or give the next instruction.

Nobody forced me to work this way. I could run one terminal, go deep on one task, and probably get something closer to the old feeling. But the leverage of running seven in parallel is too high to ignore. So I chose throughput over depth, and I keep choosing it every morning.

This is what that choice costs.

What I Said a Month Ago

In February, I wrote that “the flow state people mourn isn’t gone. It’s just moving. […] The flow will come back. It’ll just be at a different altitude.”

I was wrong.

A month of working this way changed my mind. The flow didn’t migrate to a higher altitude. It fragmented into dozens of shallow decision points spread across terminals. Briefing, reviewing, approving, redirecting. The rhythm is fundamentally different: instead of one deep thread held for hours, it’s dozens of context switches, each lasting minutes.

The output is enormous. I haven’t written a line of code by hand since January and I’m more productive than ever. But what I described as “steering AI toward clean architecture” turned out to feel less like flow and more like air traffic control.

What Flow Actually Was

If you’ve coded for long enough, you know the state. Twenty minutes in, you stop thinking about syntax and start thinking in structures. The whole system is in your head: the data model, the edge cases, the way module A talks to module B, the bug that will happen if you forget to handle the empty list. You’re not reading code, you’re seeing it.

This is why you shouldn't interrupt a programmer “This is why you shouldn’t interrupt a programmer” by Jason Heeris

That’s flow. Deep immersion, total absorption, time disappearing. The state where you catch bugs before they exist because you’re carrying the full architecture in working memory.

I spent twenty years in that state. It’s where the best code came from. Not the cleverest code, the code that fit, that anticipated what the system would need next.

The Fuzzy Mental Model

Now I context-switch. Constantly. Terminal one needs a decision about error handling. Terminal three just finished a feature and wants me to review the diff. Terminal five hit a permission prompt. Terminal seven is waiting for a brief on the next task.

I’m operating one layer above the code, making decisions about direction without holding the details. That works when the decisions are small. It breaks when they’re not.

Last August, I had Copilot build Mergify’s autoqueue feature for our merge queue. Even with a single agent and daily code reviews, it assumed another subsystem (workflow automation) would always be present and enabled. That assumption was invisible in the diff. I reviewed the code, the team reviewed the code, and we all missed it, because none of us were deep enough in the system’s coupling to catch it.

The bug shipped to production. Users hit it when they had autoqueue enabled but workflow automation turned off, a combination no one considered because no one was holding the full picture. We fixed it, but not before real users were affected. That was with one agent. Now multiply by seven.

That’s the cost of the fuzzy mental model. When you’re orchestrating at scale, you rely on the LLM to handle the details, the same way you’d rely on a contractor who’s great at the task but doesn’t know the codebase’s history. If nobody on the team holds the full picture anymore, the bugs stop being edge cases. We haven’t hit that wall yet at Mergify, but I can see the trajectory.

The Orchestrator’s Dopamine

The satisfaction of building something is still there. I still feel like I built it. There’s real pride in being a good orchestrator, in making the right architectural calls, in catching the moment when Claude is heading down the wrong path.

What’s different is where the dopamine comes from. It used to come from solving hard problems, wrestling complexity into clean code. Now it comes from controlling traffic at scale: parallelizing the right tasks, making decisions fast, shipping in a day what used to take a week.

There’s also something new: a feeling of raw power. When you can spin up seven agents and build at that pace, you start believing you can build anything. That’s why you see developers shipping new projects every day on X. Creation got cheap. (Maintenance didn’t.)

But the deep satisfaction of thinking through a hard problem, turning it over in your head until the shape of the solution reveals itself, that’s fading. Not because I chose to let it go, but because why would I? Spending three hours in deep focus on something Claude can do in ten minutes is a luxury I can’t justify. Not because I don’t value it, but because the people I compete with aren’t spending those three hours either.

What Gets Better From Here

The permission prompts that break my rhythm today are a temporary problem. Models get faster, sandboxing gets smarter, trust boundaries expand. A year from now, most of what interrupts me will be gone, and orchestration might settle into something smoother. Not flow, but a rhythm of its own.

And there’s an upside I didn’t expect: orchestration forces simplicity. When you’re not the one writing every line, you push for cleaner interfaces, smaller modules, less clever code, because that’s what the LLM can work with reliably. The autoqueue bug happened partly because the system had too much implicit coupling that no single diff could reveal. Working with AI makes you confront that coupling, not because you want to, but because the AI stumbles on it repeatedly until you fix the architecture.

What Doesn’t Come Back

But the flow state itself, in the form I knew it? Gone.

A generation of developers is about to start their careers with AI from day one. They’ll be natural orchestrators. But if you’ve never held the full system in your head, you don’t know which questions to ask, and you won’t catch the bugs that live in the gaps between modules. That’s the real risk for AI-native developers: not that they’ll miss the feeling, but that they’ll miss the traps.

I’m not sure they’ll see it that way. But I do. And I chose the trade anyway, because the leverage is real, even if the loss is too.

share:

Related posts