What if the thing developers miss most about pre-AI coding was never that valuable in the first place?
That's the argument from developer Kieran Gill, whose recent blog post makes a deliberately provocative claim: the flow state that programmers chase - those hours of uninterrupted, deeply satisfying coding - was actually a signal that the work had become routine. And AI agents just made that obvious.
Flow Was a Comfort Signal, Not a Skill Signal
Gill's core point lands harder than most "AI is changing everything" takes because it's specific. Flow, he argues, is what happens when a task that was once difficult becomes automatic. You enter flow when typing React components or wiring up API routes because you've done it hundreds of times. The challenge is gone. The reward system in your brain fires anyway.
AI coding assistants - Copilot, Cursor, Claude Code - now handle exactly that layer of work. The boilerplate. The patterns you could write in your sleep. And with that automation, the flow disappears.
The natural reaction is grief. Developers genuinely loved those hours. But Gill pushes back: missing flow is like a factory worker missing the rhythm of the assembly line. The rhythm felt good, but it wasn't where the real value lived.
What's Actually Hard About Engineering
If writing code is the easy part, what's left? Gill points to the work that never produced flow in the first place: choosing which problems to solve, designing abstractions that hold up under pressure, anticipating failure modes, and communicating trade-offs to non-technical stakeholders.
This tracks with what I've seen using AI coding tools daily. The time I save on implementation gets immediately consumed by review, architecture decisions, and debugging AI-generated code that's syntactically correct but conceptually wrong. The job didn't get easier. The hard parts just became a bigger percentage of the day.
The Cognitive Debt Problem
The most useful idea in Gill's piece is "cognitive debt" - the gap between how fast AI generates code and how fast a human can understand it. This is a real, daily problem for anyone using agent-based development tools.
When Claude Code or Cursor generates 200 lines across four files in 30 seconds, you now own code you didn't write and may not fully understand. That's a new skill to develop: reading and auditing code at the speed it's being produced. Most developers haven't built that muscle yet.
Gill doesn't offer a neat solution here, and that honesty is refreshing. He frames the current moment as a genuine struggle period where engineers need to develop new competencies around directing AI tools strategically and maintaining comprehension despite volume.
The Part Gill Gets Wrong
Where the argument stretches thin is the blanket claim that "coding is low-skill." Writing a CRUD endpoint is low-skill. Writing a distributed consensus algorithm is not. AI tools handle the first case well and the second case poorly. The spectrum matters, and collapsing it into a single category oversells the disruption.
But the broader point stands. If your day was 80% pattern-matching and 20% genuine problem-solving, and AI just automated the 80%, then complaining about lost flow is missing the opportunity. The 20% is where you were always supposed to be spending your time.
The developers who adapt fastest won't be the ones who type code the fastest. They'll be the ones who can read AI-generated code critically, catch subtle architectural mistakes, and direct agents toward the right problems. Flow state might come back eventually - just for a completely different kind of work.