Flow Is a Property of the System and the Individual
Flow does not come from harder working teams, it emerges when the system stops fighting them
In the beginning, there was a corridor.
It was not a particularly long corridor, but it had been extended many times, each extension justified by a document that referenced another document which no longer existed. The corridor connected desks, though no one was certain which desks belonged to whom, or whether ownership was still a meaningful concept.
At the centre of this corridor sat Elena, a software engineer of some competence and declining certainty.
She had arrived that morning with a single, modest intention:
> “I will change one line of code.”
The line, she knew, was wrong.
It had always been wrong.
Everyone agreed it was wrong, though for subtly different reasons, all of which had once been recorded and then carefully lost.
Elena opened her editor.
Immediately, the corridor stirred.
A bell rang.
Not a loud bell. A polite one. The sort of bell that apologises for interrupting you while doing so anyway.
A message appeared:
> CI has failed.
Elena had not yet typed anything. She opened the failure report. It contained:
A stack trace pointing to a service she did not recognise
A link to a dashboard that no longer loaded
A recommendation to “check the logs”, which were archived for compliance
She closed it gently, as one closes a door that leads nowhere.
She returned to the line. Another chime sounded.
> “Can you quickly review this?”
The word quickly was underlined, though no one remembered doing so.
Elena agreed, because she always did. She believed, mistakenly, that agreement was a finite resource she could eventually exhaust.
The review referenced an architectural principle. The principle referenced a wiki. The wiki referenced a meeting. The meeting referenced a decision log. The decision log referenced Elena, though the date was from before she had joined the company.
Time folded slightly.
She stood up to fetch coffee.
The corridor lengthened.
On the wall was a chart explaining Team Flow Enablement Initiative v3.1, which asserted—confidently—that interruptions were bad, and then listed fourteen ways to notify people of this fact.
Each notification required acknowledgement.
When Elena finally returned to her desk, the line of code waited patiently.
It had been waiting for years.
She hovered her cursor over it.
A final bell rang.
This one was different. Louder. Certain.
> AI Suggestion:
> “I can fix this for you.”
Elena paused. She asked the AI why the line existed in its current form.
The AI replied with admirable fluency, citing:
A deprecated standard
A performance optimisation for a system that had since been decommissioned
A business requirement no longer in effect
None of it was wrong. None of it was useful.
The explanation was complete, yet understanding was absent.
Elena accepted the suggestion. The line changed. The tests passed. The corridor fell silent.
Flow, she realised too late, had not returned, but it had been bypassed.
She no longer knew why the line was correct. Only that the system now permitted it.
Years later, a different engineer would stand in the same corridor, staring at the same line, now annotated, documented, and surrounded by tooling.
They would ask the same question. The AI would answer. The corridor would grow.
And somewhere, buried beneath layers of assistance, the original moment of flow—clear goal, direct feedback, unbroken attention—would remain perfectly preserved.
Like a lost book in an infinite library. Unread. With only a footnote deciphered:
Flow does not vanish dramatically.
It is eroded politely.
One helpful interruption at a time.
Flow As a Property of the System
Flow is not a mood, a perk, or a motivational poster. It is a state that appears when four conditions align:
Clear intent
Fast, unambiguous feedback
Balanced challenge and skill
Minimal interruption
Modern software organisations systematically violate all four. Not because engineers are weak, distracted, or undisciplined—but because the systems they operate within are noisy, fragmented, and cognitively hostile.
AI enters this story not as a replacement for thinking, but as potentially a helpful tool for environmental repair.
Used well, AI does not “speed developers up”. Instead it can remove friction, restores signal, and protects attention—the true limiting factor of creative work.
Used poorly, it adds yet another channel of interruption, abstraction, and false confidence.
AI should reduce extraneous cognitive load while preserving essential cognitive effort.
If the developer stops thinking, flow is lost—even if output increases temporarily.
Some practices to consider — Where AI can support flow
Guard the Attention Budget — AI should act as a buffer between the developer and the noise of the system. Healthy uses include:
Summarising alerts, CI failures, and dashboards into actionable signals
Filtering Slack, tickets, and notifications by actual relevance
Providing “on-demand memory” so developers don’t context-switch to search
Potential outcome to look for: Longer uninterrupted focus windows—the prerequisite for flow.
Compress Context, Not Understanding — Codebases can grow faster than human memory. Flow collapses when developers must constantly rehydrate context. AI can be used to:
Explain intent, not just implementation
Summarise architectural decisions and trade-offs
Translate between business language and technical structure
But it must explain its reasoning, not merely assert correctness. Rule of thumb: If the AI removes the need to understand, it is harming flow.
Tighten Feedback Loops — Flow thrives on immediacy. AI accelerates feedback by:
Explaining why tests failed, not just that they failed
Flagging likely invariant violations before review
Checking implementation drift against specifications or intent
This has similarities to the use of good CI/CD, i.e. fast feedback loops but this time with cognition and flow the forefront.
Reduce Social Friction — Team flow is often broken not by code, but by coordination cost. AI can be used to help by:
Summarising long threads into shared understanding
Acting as a neutral explainer during disagreement
Allowing private rehearsal of questions and ideas
This can lower the emotional and social cost of collaboration.
Shape the System, Not Just Assist the Individual — The deepest gains come when AI is used to improve how work flows, not just how fast tasks are completed. Some examples include:
Identifying recurring bottlenecks and handoffs
Revealing hidden queues and failure patterns
Highlighting coordination hotspots between teams
Suggesting changes to ownership or topology
Performance emerges from system design, not individual optimisation.
Some things to avoid — Where AI can destroy flow
Autopilot coding — Generation without understanding
Interrupt amplification — More alerts, more chatbots, more noise
Opaque automation — actions without explanation
Speed theatre — measuring output instead of focus and learning
These produce activity, not flow. Velocity, not mastery.
Watch out for:
Developers disengaging from design discussions
Increased rework despite “faster” coding
Rising dependency on AI explanations
Fewer questions, but more defects
These are signs of cognitive offloading, not flow. And before adopting an AI capability, consider asking:
Does this increase uninterrupted focus time?
Does it reduce context switching?
Does it clarify intent faster?
Does it shorten feedback loops?
Does it preserve human judgment?
If the answer is “no” to any at a minimum, pause.
AI-assistance in software development should be like noise-cancelling headphones, not an autopilot. Headphones remove distractions so you can listen better. Autopilot flies the plane while you forget how.
Flow is not speed. Flow is clarity sustained over time.
Design your AI-augmented engineering habitat accordingly.
Some Further Reading
“Flow”, Mihály Csíkszentmihályi — Explores the state of deep immersion where challenge and skill are perfectly balanced, producing peak performance, creativity, and intrinsic satisfaction.
“Accelerate”, Nicole Forsgren, Jez Humble and Gene Kim — Uses rigorous empirical research to show that high-performing technology organisations win by optimising flow, feedback, and learning rather than processes or tools alone.
“Team Topologies”, Matthew Skelton and Manuel Pais — Argues that software systems improve when teams are deliberately structured to minimise cognitive load and aligned with flow.
“Deep Work”, Cal Newport — Makes the case that sustained, distraction-free concentration is a rare but decisive skill for producing meaningful, high-quality work in a noisy world.
“The Sciences of the Artificial”, Herbert A. Simon — A foundational work that reframes how we think about design, engineering, and human-made systems