HN Explorer

Ask HN: Is AI 'context switching' exhausting?

17 points by interstice ↗ HN
I've always had this distinct struggle when switching in and out of being 'in charge', the best example I can think of is the difference between a driver vs a passengers awareness of the road.

Using AI for code has reminded me of this sensation, switching in and out of 'driving' feels more exhausting than being 100% one or the other. I have a theory that enforcing reduced engagement has all sorts of side effects in any format.

Wondering if anyone else has run into this feeling, and if so have you tried anything successfully to address it?

21 comments

[ 3.5 ms ] story [ 43.4 ms ] thread
andy99
I had a vibe-coding phase that I think largely followed the popular arc and timeline from optimism through to disappointment.

Definitely felt some burnout or dumbness after it, trying to get back into thinking for myself and actually writing code.

I think it's like gambling, you're sort of chasing an ideal result that feels close but never happens. That's where the exhaustion comes from imo, much more than if you were switching from manager to IC which I don't find tiring. I think its more a dopamine withdrawal than context switching.

interstice
Dopamine makes sense, since its kind of switching between 'sources' of Dopamine, like one is a sugar rush and the other is slow release like reading a book.

At the moment I have a bit of a tick tock where I'll vibe code to a point, get frustrated when it gets stuck on something I can fix myself in a minute or two. Then switch off using AI entirely for a while until I get bored of boilerplate and repeat the cycle.

PaulHoule
Personally I like the older kind of chatbots where I can ask it to write me something little (a function, a SQL query, ...) and I have it in 10-30 seconds and can think about it, try it, look in the manual to confirm it, or give it feedback or ask for something else. This can be a lot more efficient than looking in incomplete or badly organized manuals (MUI, react-router, ...) or filtering out the wrong answers on Stack Overflow that Stack Overflow doesn't filter out.

I can't stand the more complex "agents" like Junie that will go off on a chain of thought and give an update every 30 seconds or so and then 10 minutes later I get something that's occasionally useful but often somewhere between horribly wrong and not even wrong.

interstice
This resonates, even though copy pasting from Claude et al seems like it should be inefficient somehow it feels less prone to getting completely off track compared to leaving something like cursor or aider chat running.
[dead] PaulShin
[flagged]
antinomicus
God this comment reads exactly like someone asked gemini to make a classic hacker news comment reply to this post. Slightly useful insight, that perfectly transition into an ad for the commenter’s startup. Actually, I asked o3 for a response to the OP and here’s what it generated.

“Using AI for code has reminded me of this sensation… switching in and out of “driving” feels more exhausting than being 100 % one or the other.” You’re not imagining it. There’s a fair bit of cognitive-science literature on task-set inertia: every time you hand work off (human→AI or AI→human) you pay ~100–150 ms to reconstruct the mental model, plus an exponentially-longer “resumption lag” if the state is ambiguous.¹ Do that dozens of times per hour and you’ve effectively added a stealth meeting to your day. A few things that helped me when pairing with an LLM: • Chunk bigger. Treat the AI like a junior dev on 30-minute sprint tickets, not a rubber duck you ping every two lines. • Use “state headers.” I prepend a tiny recap in comments — // you own: parse(), I own: validate() — so I can scan and re-hydrate context instantly. • Declare no-AI zones. Sounds counter-intuitive, but reserving, say, test-writing for uninterrupted solo focus keeps me in flow longer overall. …have you tried anything successfully to address it? We were annoyed enough to build something. At Recontext (YC S24) we sit between your editor and whatever LLM you’re using; every AI request is automatically tagged with the diff, dependency graph, and TODO items so when you jump back in, you get a one-glance briefing instead of spelunking through scrollback. Early users report ~40 % fewer context switches during a coding session. If anyone wants to kick the tires, we’re handing out private beta invites — email is in profile. ⸻ ¹ See Monsell, “Task switching,” Trends in Cognitive Sciences 2003 — the “switch cost” math is sobering.

pillefitz
We definitely need a way to flag AI content
codingdave
There is one. Click the timestamp of the comment, then click 'flag'.
PaulShin
You got me. I guess that's my own practical example of the 'human > AI > human' collaboration you described.

Jokes aside, this is a fantastic, insightful reply. Thank you. You've given a name to the pain: 'task-set inertia' and the cost of the 'stealth meeting.' Painfully accurate.

The advice here is gold, especially treating the AI like a 'junior dev' on a 30-min ticket vs. a 'rubber duck' you ping every two lines. That really crystallizes the right mental model.

Very cool that you're tackling this head-on with Recontexter. Solving the 're-hydrating context' problem is such a critical challenge. I'll be following your work.

joegibbs
I think I’ve mostly gotten used to it. At the start, definitely, but now my method is to have 3 or 4 agent tasks running o3 to perform smaller actions than I was previously trying to do. There is a second where I have to remember what each one was doing but it’s still much faster than manually doing it.
karmakaze
I don't really perceive it like that. For me it's more like I'm driving and the AI passenger keeps interjecting with insidiously upbeat back-seat-driver-instructions. What I find tiresome is the pause waiting for responses that break my flow state. Using faster models is tiring from having to extensively correct its understanding of the prompts and output. I don't vibe code, I use the AI to solve specific design or implementation problems and I'll recognize a suitable solution when it presents one, or get it to critique one I'm proposing.
mjrbrennan
Yes, I’ve only just started trying out Claude Code and I do not mesh well with this method of asking AI to do something, then having to wait a few minutes and come back and check its work.

I find this leads so easily to distraction and I find this workflow very boring. If I’m going to use AI I want to use it in a more integrated way, or in a more limited way like just querying ChatGPT.

Will still try Claude more but I’m really not a fan so far.

paulcole
> I have a theory that enforcing reduced engagement has all sorts of side effects in any format

This isn’t a particularly novel theory because you are basically saying “Doing different things makes different things happen.” Shocker.

Do you find AI immensely valuable for coding? Would you be happy to be a 100% passenger in your coding analogy?

interstice
As stated too vague to be interpretable, I agree. The theory isn't novel either, it's well known that easier to use = less engaged, What's less clear but still somewhat well discussed is semi automated = lower quality & more mistakes.

In future I wouldn't mind doing both, since I could be driving and a passenger in multiple contexts with less overhead. Currently attempting to work this way is painful due to the aformentioned switching.

rabbittail
Absolteuly, I made a WebSocket-based persistent memory system that stores conversation context in DynamoDB and automatically injects it into subsequent AI interactions. Instead of context switching, you get a consistent collaborative relationship where the AI maintains full project awareness across sessions. I use the websocket to so Claude Code makes seperate calls to the api so it will autonomously fill the DB with knowledge.
alicekim
I'm curious about this question too.
codingdave
I do not find it exhausting at all, but I'm a technical product manager, not a full-time coder. So even before LLMs came out, I was in the mode of delegating some work, doing other work, and validating the work when it came back from delegation. That decision of "do vs. delegate" is just part of that job, at least in the gigs I've done. AI simply speeds up the task completion and feedback cycle when delegating.
maxcomperatore
for me it's less about dopamine crash and more about clashing headspaces. coding is pure flow, all in. ai pulls you out to play editor, and that shift kills momentum. here's what i've tried:

* batch ai work: toss it small stuff like snippets or lookups while i stay deep in my zone.

* hard limits: ai handles grunt work, not the big logic. if i'm fixing its bugs faster than writing it, i skip it.

* async vibes: treat ai like a junior coder. send a prompt, do something else, check later. no staring at the spinner.

v5v3
Can you resolve this by using ai coding in ask mode only, where it won't change the code directly but only tell you what to do.
ativzzz
While the AI is running, go work on something else. Go write a doc, or write a test, answer an email, work on another part of your feature that won't interfere with the AI, etc

I know some people have trouble with the context switching but I've been full stack at small companies my whole career so I context switch constantly every day so I'm used to it.