For thirty years I programmed with Phish on, every day

You say minutia, but others say well organized notation and predictive systems. At least for me, writing code is as easy as writing English and with less effort.

That loop (open a session, ask a question, redirect, switch) happens before the spec discipline is tight enough to trust the result without watching. When you've actually delegated well, you're not context-switching constantly between sessions. You hand over a detailed spec, wait for the agent to finish, and evaluate. The watching gets compressed to the handoff and the return, not the whole run.

Most engineers haven't gotten there, because getting there is hard. The spec has to be good enough that the agent can hit an ambiguity without needing to ask, fill a gap without needing your correction, and still produce something worth using. That's a different kind of writing than what most engineers were doing before. It takes the kind of attention that's hard to find when you're also redirecting three other sessions.

The flow state question is the more interesting one. It doesn't disappear. It moves. The continuous-arc attention used to live at the implementation layer. Now it's available at the spec-writing layer. Most people haven't redesigned their work to find it there. The new deep-work mode runs from a high-level goal through a narrow, implementation-ready spec through a validation pass. That can be a continuous arc if you've structured the work to allow it. It just doesn't look like the old one, and the muscle memory for it doesn't exist yet.

Whether that's actually flow or just a different kind of concentration is a real question. The engineers that I know (myself included), who've found something like the old rhythm have moved most of their time/effort upstream in the process. The ones still in the redirect loop are usually starting with stories with the same information they always had in them, ran through an LLM to make them appear more tightly defined.

The work is, among other things:

* Writing components * Writing glue * Requirements gathering * Architectural design * Testing

Which parts are the grunt work depends on the individual. Personally, writing components was the most challenging, least grunt work job there was. Requirements and design was the next most fun, but not really very challenging. Writing glue and testing was grunt work--had to get done, but was mind-numbing.

As one of my friends put it, "Beej, writing software was never the goal."

I might counter that managing LLMs was never the goal, either, so we'll get to see where that leads.