What ever happened to going with the flow?

Why did we spend a decade protecting developers from distraction?

It’s half eleven at night, and somewhere a developer has four terminal windows open. One agent is refactoring a service. Another is writing tests for code it generated an hour ago. A third is halfway through a migration they stopped paying attention to an hour ago. They’re not going to bed because one of the sessions is at 80% and it would be a waste not to kick off another agent to work overnight. Tomorrow, they’ll triumphantly post on social media that they shipped a week’s work overnight.

I keep seeing versions of this, and it makes me wonder. Because not long ago, as an industry, we were actively campaigning for the precise opposite.

A Decade of Defending Focus

For years we built a careful, evidence-led case that developers need uninterrupted time to do their best work. We had the research to back it. After a single interruption, a developer needs around 23 minutes to fully reload the problem they were holding in their head. A few poorly timed meetings could ruin the day.

So we acted on it. We carved out no-meeting blocks. We pushed for asynchronous communication over the constant tap on the shoulder. We treated the maker’s schedule as something worth protecting. Both SPACE and DevEx, the frameworks most of us now use to reason about productivity, treat flow as a first-class dimension rather than a soft perk. The whole argument rested on a single idea: fragmented attention is the enemy of good engineering.

We were right. So why are we now fragmenting it on purpose?

We Built Our Own Interruptions

The problem I believe is running ten agents in parallel is not the same as being interrupted by a colleague. An interruption is something done to you. Orchestrating a swarm of agents is a choice you make, and it feels wonderful while you make it.

It feels a lot like flow. You are absorbed. Time distorts. The feedback comes fast and the wins are real. Steve Yegge described agentic coding as a slot machine: you pull the lever with each prompt and wait for the payout. Although that’s true, I think it’s more nuanced. Developers fell free, unshackled, and able to finally make progress on the hundreds of ideas they’ve had. It’s like being a kid in a candy shop; you just want to eat it all at once.

The behaviour that follows is measurable. One analytics firm tracking more than 500 developers found that adopting AI tools came with a 19% rise in commits made outside normal hours. Weekend work is climbing across the board. And the time these tools save rarely finds its way back to the person who saved it. The research on this is consistent: AI-driven gains tend to be absorbed as higher expectations, not returned as breathing room. You proved you could ship a week’s work in a night. Congratulations. That is the new baseline now.

None of this is the tool’s fault. But none of it looks like the sustainable, focused engineering we spent a decade asking for either.

Flow Was Never About The Feeling

We did not protect flow because it felt pleasant; we protected it because sustained, deep engagement with a problem was how engineers built a real understanding of the systems they owned. Multitasking was the villain because it degraded comprehension and multiplied mistakes.

The problem is orchestrating agents delivers the absorption of flow with almost none of the understanding. Simon Willison, who has been writing software for close to thirty years, admitted recently that excessive unreviewed AI output had left him without a firm mental model of code he had technically authored. He calls it cognitive debt. The code works, but his understanding of why and how it works did not survive the speed at which it arrived.

The Uncomfortable Parallel

For years we told organisations a clear story. When developers are constantly distracted, that is a failure of system design, not a failure of individual willpower. Do not blame the engineer for losing focus in an open-plan office with Microsoft Teams pinging every ninety seconds. Fix the system that keeps interrupting them.

I still believe that. Which is why this moment sits so awkwardly with me. We have taken the logic we spent years criticising when employers imposed it, and we have installed it in ourselves. The ratchet didn’t go away; we just stopped needing a manager to crank it.

If a leader demanded that their team work like this, prompting agents at midnight so nothing sits idle overnight, unable to switch off, we would rightly call it a wellbeing problem. A great many developers are now volunteering for it and posting about it as a flex.

A Healthier Relationship With The Machine

I am not arguing against agentic tools. The capability is real, and I use it daily. But the developers getting durable value from them are not the ones running the most sessions. They are the ones who treat the agent’s output as the start of their thinking, not the end of it.

That looks like discipline, applied on purpose. Willison’s own rule is to cap how much generated code he will accept in a day at the amount he can realistically review, and to write the things that define the shape of a system, the architecture and the interfaces, by hand. Not because the agent cannot produce them, but because those are precisely the parts you cannot afford to stop understanding.

For those of us who lead, the job is harder and more important. We have to resist the ratchet rather than reward it. That means valuing sustainable throughput over heroic overnight bursts. It means measuring whether people still understand what they ship. And it means protecting comprehension now with the same seriousness we once gave to protecting focus.

Are You In Flow, Or Just In Motion?

Picture that developer again, four terminals lit at midnight, certain he is having his most productive week ever. Maybe he is. Or maybe he is performing productivity while his understanding of his own system quietly erodes behind him.

The argument we made for protected, focused work did not expire when the tools got better. If anything it got more urgent, because our capacity to generate work has now comfortably outrun our capacity to understand it. That is the gap that should worry us, and it is a gap no agent can close on our behalf.

So before you open the fifth terminal tonight, it is worth asking the only question that still matters. Are you in flow, or are you just in motion?