I think that "hovering the code" and "broken rhythm" are correlated, but still separate issues. There are parts of my code (e.g. vibe-coded mockups) that I don't look at the code of at all, and I don't care about it. There are others where I check everything in detail (same as if I were to review someones PR), and I think I have a very good grasp of that code.
But the broken rhythm problem persists regardless, and I find that issue to become more and more serious as LLMs are able to work for longer and longer on their own.
It might be that what we're experiencing now is just an uncanny valley, where they're not yet good enough for us managing them to work in similar ways as with other developers, but are good enough to allow us to switch our attention away from them while they work. But that attention span is mostly wasted, as the time between interactions isn't enough to e.g. work on something else, or read a book.
It's a stupid analogy, but currently it's similar to having a bathroom break every couple of minutes, and if this continues, most developers will probably start doomscrolling more and more.
I was wondering recently if there are some productive activities that might fit well into this rhythm, but I haven't found any yet. I guess sourdough baking is one such example, but there's only so much bread you can eat...
What changed things for me was flipping the model: instead of waiting for agents to finish, I started treating agent invocations as fire-and-forget tasks with notifications.
I built a task system where I define what the agent should do (prompt + connections + schedule), set a trigger (cron, webhook, or manual), and walk away. The agent runs, and I get notified when it finishes or needs input. This turned the 10-30 second micro-waits into async reviews I batch together.
The key insight was that the broken rhythm comes from trying to supervise agents synchronously. Once you accept they should run in the background like CI jobs rather than pair programming sessions, the flow problem mostly disappears. You write specs in batches, kick off agents, do deep work on something else, then review results.
The tradeoff is you lose some real-time steering, but for most tasks that's fine. I save synchronous agent sessions for exploratory work where I genuinely don't know what I want yet.
The broken rhythm you're describing is real, and I think it's a sign the tooling is still calibrated for the developer, not the developer-agent pair.
What's helped me most: stop treating agent invocations like function calls and start treating them like delegating to a junior dev you trust but still need to review. That reframe changes what you do in the gaps. Instead of waiting for confirmation prompts, I now use that 10-30 seconds to write the next spec segment, review adjacent code, or just think about what the agent should find. The gaps become planning time, not interruption time.
The deeper issue is that flow state was designed around a human holding the full context in working memory. With agents, the context lives outside your head by design. The discomfort you're feeling might be the transition from solo-player flow to coordinator flow - which is a genuinely different cognitive mode, not a degraded version of the original.
Concretely: do you write your specs before or after starting the agent run? I've found writing specs upfront (even rough ones) shifts me into coordinator mode faster and makes the waits feel purposeful.
I tried agentic coding and was not a fan. I’ve gone back to just using LLMs to augment search. This usually improves flow, as it’s faster than a normal web search for basic stuff I might need.
I just have to be careful not to ask too much of it, because it will often take a left turn and then I spend far too long fighting a losing battle.
I have been experiencing this as a (don't judge) full-time vibe coder without an engineering background. tmux helps a little. I'm leaning towards embracing YOLO mode (in CC) + writing very detailed specs. That way, the attention goes into the specs.
It's actually really good for targeted debugging. Not the tool itself - still goes into lala land if you let it (arguably even more than trying to build out something). But I get to deeply think about code, then tell the agent to go make a small prototype or explain some arcane thing to me. Then I reason about it some more, etc.
The other times, when I let it generate 3k LOC with minimal supervision, yeah, that's when I die inside.
I think that "hovering the code" and "broken rhythm" are correlated, but still separate issues. There are parts of my code (e.g. vibe-coded mockups) that I don't look at the code of at all, and I don't care about it. There are others where I check everything in detail (same as if I were to review someones PR), and I think I have a very good grasp of that code.
But the broken rhythm problem persists regardless, and I find that issue to become more and more serious as LLMs are able to work for longer and longer on their own.
It might be that what we're experiencing now is just an uncanny valley, where they're not yet good enough for us managing them to work in similar ways as with other developers, but are good enough to allow us to switch our attention away from them while they work. But that attention span is mostly wasted, as the time between interactions isn't enough to e.g. work on something else, or read a book.
It's a stupid analogy, but currently it's similar to having a bathroom break every couple of minutes, and if this continues, most developers will probably start doomscrolling more and more.
I was wondering recently if there are some productive activities that might fit well into this rhythm, but I haven't found any yet. I guess sourdough baking is one such example, but there's only so much bread you can eat...
We might be in a kind of uncanny valley. Models may become good and "independant" enough to compare to a colleague.
I feel the solution is either reduce drastically time between each interaction with the agent OR increase it by a lot (every 2 or 3 hours).
Maybe we do not have the right workflow yet. Maybe the work with an agent should be more async.
I guess we will figure out.
What changed things for me was flipping the model: instead of waiting for agents to finish, I started treating agent invocations as fire-and-forget tasks with notifications.
I built a task system where I define what the agent should do (prompt + connections + schedule), set a trigger (cron, webhook, or manual), and walk away. The agent runs, and I get notified when it finishes or needs input. This turned the 10-30 second micro-waits into async reviews I batch together.
The key insight was that the broken rhythm comes from trying to supervise agents synchronously. Once you accept they should run in the background like CI jobs rather than pair programming sessions, the flow problem mostly disappears. You write specs in batches, kick off agents, do deep work on something else, then review results.
The tradeoff is you lose some real-time steering, but for most tasks that's fine. I save synchronous agent sessions for exploratory work where I genuinely don't know what I want yet.
The broken rhythm you're describing is real, and I think it's a sign the tooling is still calibrated for the developer, not the developer-agent pair.
What's helped me most: stop treating agent invocations like function calls and start treating them like delegating to a junior dev you trust but still need to review. That reframe changes what you do in the gaps. Instead of waiting for confirmation prompts, I now use that 10-30 seconds to write the next spec segment, review adjacent code, or just think about what the agent should find. The gaps become planning time, not interruption time.
The deeper issue is that flow state was designed around a human holding the full context in working memory. With agents, the context lives outside your head by design. The discomfort you're feeling might be the transition from solo-player flow to coordinator flow - which is a genuinely different cognitive mode, not a degraded version of the original.
Concretely: do you write your specs before or after starting the agent run? I've found writing specs upfront (even rough ones) shifts me into coordinator mode faster and makes the waits feel purposeful.
I tried agentic coding and was not a fan. I’ve gone back to just using LLMs to augment search. This usually improves flow, as it’s faster than a normal web search for basic stuff I might need.
I just have to be careful not to ask too much of it, because it will often take a left turn and then I spend far too long fighting a losing battle.
I have been experiencing this as a (don't judge) full-time vibe coder without an engineering background. tmux helps a little. I'm leaning towards embracing YOLO mode (in CC) + writing very detailed specs. That way, the attention goes into the specs.
I feel like I'm a stone skipping across the water instead of being submerged deep in coding context.
I'm getting used to it but I don't like it.
I'm also much more tired at the end of the day. My mind feels broken. I don't know if our brains were designed for this.
It's actually really good for targeted debugging. Not the tool itself - still goes into lala land if you let it (arguably even more than trying to build out something). But I get to deeply think about code, then tell the agent to go make a small prototype or explain some arcane thing to me. Then I reason about it some more, etc.
The other times, when I let it generate 3k LOC with minimal supervision, yeah, that's when I die inside.