Vibecoding
Build for the vibe, debug later
Start new thread

Your AI agent is waiting for you. Your attention isn't. How much time do you lose to this?

by•

Daily reality: Claude Code in one pane, Codex in another, Cursor in a third, plus a few shells. An agent stops and waits for "yes". By the time I find the right pane, 20 min gone.

Just me? What's your setup — notifications, layout tricks, or you've accepted the tax?

353 views

Add a comment

Replies

Best

Honestly this is exactly why I built one for myself — . Menubar app, pings me when any agent (Claude Code / Codex / Cursor) is waiting, click the notification and it jumps straight to that pane.

Curious if others solved this differently — what am I missing?

probably 15-20 min a day easily, but the actual cost isn't the wait, it's that I forget which of the 3 panes was even blocked and end up re-reading the last few messages in all of them to remember. a simple terminal bell or OS notification the moment it's actually waiting on you (not just running) would fix most of it, but half these tools don't distinguish 'thinking' from 'blocked on approval' in any visible way.

 Yeah, the "thinking vs blocked on approval" distinction is the hard part. A bell that fires on every pause becomes noise fast; one that only fires on real blocks needs to actually understand what the agent is doing.

That's basically why I ended up building — it hooks into Claude Code / Codex / Cursor at the approval moment specifically, and clicking the notification jumps you to that pane so you skip the "which one was it" step you described.

This is painfully real 😂 By the time I find which pane is waiting for approval, I have already lost 20 minutes. I need one universal agent needs attention notification.

 Same 😂 The "universal" part is what got me too — I didn't want a different setup for Claude Code vs Codex vs Cursor. Ended up building for exactly this: one menubar notification across all of them, click to jump to the pane.

Would love your take if you try it.

35 minutes later: Oh… that agent was waiting for me.” 😭 I now keep one dedicated pane for anything that needs human approval.

 That works until you can't predict which task will need approval — half the time I think "this one's autonomous" and it stops on the third tool call anyway. Also the discipline itself has a cost: one more rule to remember while you're deep in something else.

That's why I went the other way with — no dedicated pane, no rules, just let the agent tell you when it needs you.

me using multiple agents at once sounded productive until context switching became the biggest delay. I now limit active sessions. Has anyone measured whether fewer parallel agents actually finish work faster?

 Interesting angle. I think the answer depends on how fast the LLM itself is — if inference gets 3x faster tomorrow, the "context switching tax" you're describing shrinks a lot.

But honestly, the thing that changed for me isn't measured productivity. It's that once agents were a thing, I can't stop myself from spinning up tasks in idle moments — not even work stuff. "Can my terminal look prettier?" "What if I try that CLI I bookmarked?" Parallel agents feel less like a productivity strategy and more like… a new default behavior.

Not sure if that's better or worse, just different.

I think this gets to the real bottleneck. We've become much faster at generating work, but switching attention between agents and remembering why each one is doing something still feels expensive. I'm curious whether the answer is better interfaces or a shared context layer that keeps every agent aligned with the original intent.

 This is the right framing, honestly. And I'd argue both directions are already being explored — just by different products.

The "shared context layer" you're describing is basically what tools like and are building — agent orchestration, shared memory, keeping parallel agents aligned. That direction reduces the volume of interruptions by making agents smarter about when to ask.

The other direction — better interface for the moment an agent does pull you back in — is more under-invested. Even with perfect orchestration, agents will still hit ambiguous moments and need you. When that happens, "which agent, which pane, what was it doing" is still a manual cost. That's the gap I've been working on.

Both matter. Just curious which one hurts more for you day-to-day.

  Spot on. The cmux/herdr direction is cleaner architecturally, but I think the real win is when they work together. Context orchestration handles the happy path, but the interface needs to be there for the edge cases you mentioned.

One thing I'm curious about: as agents get more specialized, doesn't the cost of context switching become less about interface clarity and more about the cost of maintaining alignment across different task-focused agents? Like, even with a shared context layer, keeping a code agent and a research agent on the same page feels like its own problem. How are you thinking about that?

 
Honest question — how often are your coding agent and research agent actually stepping on each other's output? In practice, I think most of us naturally avoid that: you don't ask one agent to clean the desk while another is still coding on it. The workflow instinctively separates tasks that would collide.

Also worth noting: the direction things are actually moving is one main agent dispatching sub-agents (Claude Code already does this). In that model, alignment is the main agent's job, not yours. You're not the one keeping them in sync — the orchestrator is. So the problem you're describing might get solved at the agent architecture level before it ever reaches the human.

For me, the friction that actually shows up every day is still "which one stopped and needs me" — that's the one I keep paying for.

@hellokidder01 That "which one stopped" problem is the unglamorous one nobody talks about until they're shipping. The orchestrator approach makes sense architecturally, but you're right that the human friction—knowing when to look at what—might outlast the technical one. Curious if you're seeing tools solve this differently or if everyone's still reinventing the status-polling layer.

Not just you. and 20 min is honestly conservative once you add the context switching cost of remembering where you even were

Try treating agent prompts like async messages rather than blocking calls kick off longer tasks before I switch focus, not during

Hope this help:)

 Nice framing — async-in-spirit definitely helps. Still hits a wall when the agent stops mid-task asking about something you didn't anticipate.

One thing though — this kind of discipline suggests you've got serious focus and self-control, which honestly puts you in the minority. For the rest of us, it feels a bit against human nature: wasn't AI supposed to reduce our mental load? Right now it often adds to it — more tasks in flight, more context to hold, more decisions to make. Curious if you actually feel it as freeing, or if the discipline is what makes it work.

I stopped scanning panes and gave each agent its own sound — one chime for "needs a decision," another for "done," a third for "approve this prompt" — so I can stay heads-down on a second machine and only turn around when the one that actually needs me goes off. For me the 20 minutes was never the waiting, it was the cost of switching over just to check; once the sound tells you which agent and why, that mostly disappears.

 

Legitimately good setup — and you named the real cost precisely: "switching over just to check" is the tax that keeps hurting.

A few limits I see, though: the sound-mapping starts to fight you past ~4 agents × 3 event types, and even when the chime tells you which agent, you still have to physically get to that pane — that "last mile" is where a lot of friction hides when you're juggling panes on one machine.

Also honest question — when you're deep in focus mode, does the sound ever just… not register? I've noticed the deeper I go, the more my brain filters out ambient audio, especially with music or noise-canceling headphones on. Sound works great as an "alert layer" until the moment you actually need it most.

How many agents are you running when this really shines?

will do - the rough edge I keep hitting isn't your tool specifically, it's that I context-switch to something else while the agent runs and then lose 5-10 minutes getting back into the headspace of what I was actually trying to do before I can review its output properly. so the 'waiting' cost isn't just the runtime, it's the re-entry tax after. curious if that matches what you were seeing when you built this.

 

I couldn't agree more — this is exactly why I started building it. The goal was never "just notify you", it was to help the attention switch land on the right thing. But I quickly realized: what I can do is only the physical switch — the pane, the click, the jump.

The other thing you're pointing at — the cognitive re-entry, actually getting your mind back into the previous context — I haven't found a good answer for yet. And honestly, I think this vibe coding mode we're all in makes it worse. We're context-switching between tasks constantly, and I can't remember the last time I was truly in flow on one thing for a sustained period. Compared to writing code by hand, this mode somehow leaves us more drained, not less.

I don't have a solution for the second part yet. But hearing you name it this clearly tells me I should keep looking.

Same setup, and what fixed it for me wasn't notifications. It was a list with one row per agent and a live status on each row, so "which one is waiting" is a glance instead of a hunt. I answer the blocked one straight from the list without attaching to it.

The other half was remembering what each session was even doing. They rename themselves from their own work now, so the row tells me.

Mine is agent-manager, a tmux TUI, free and open source. It is on PH today.

123
Next