Ask HN: How do you maintain flow when vibe coding? It's been a year now since I made Claude Code my daily driver, but I feel exhausted by all the context switching from managing 2-3 agents at a time. I know some people advocate for letting agents run wild, but in my experience that leads to subtle bugs that compound and reviews become 100x more painful. What have you done to retain some semblance of flow, stay organized, and limit spinner staring? |
Overall, there are two knobs to tune, each with a few strategies:
1. reducing the number of times you have to switch context 2. reducing the cost of switching
Let’s start 1. - The easiest of course is to have less agents in parallel. - Clustering interventions. When starting a new session, use plan mode or similar, have the agent interview you until it has a good idea of what to do, don’t move away from the window until it’s ready to execute. Read the thoughts to stay on it without switching until you’re confident it understands your intent - invest heavily verifiability. That means make it easy to check if the final code correctly and exhaustively captures your intent. Let it write specs first and update specs as necessary during implementation. Have righteous integration tests and “digital twin” mocks for external integrations etc. have an adversarial prompt that reviews whether the code matches the specs.
Then reduce the cost of switching: - i usually plan my work to have only one “heavy” task, and then 2-6 agents working on small tasks, ideally straight from tickets. My brain stays with the hard tasks, the easy ones should be in and out - wait until all the easy ones need input, then do a round of those and go back the hard tasks - prompt the agent to give you a brief summary every time it stops (what the goal was, bullet list of what it did so far, what it needs from you).
Finally: be okay with staring at a spinner. Day dream. Listen to music. Enjoy that the robots are doing work for you. Won’t try to optimize every second by also checking emails, responding on slack, or god forbid open hacker news. Just do one thing - code - and allow yourself to live in the terminal for an hour. Then take a break.
Otherwise, I love your advice. Thanks.
It’s ok for the mind to wander a bit, and we are lucky to be in a time during engineering where the ability to think has become a priority.
Even Opus is often outputting wrong shit, or questionable code, I have to manually fix, refactor because it's quicker done that way. What do you get from parallel agents one can't do? Surely you can throw in a couple of extra cycles and "specialized agents" aka just different prompts, but I don't think the extra benefit is worth the token cost.
I just throw a prompt defining what I want done, review and regenerate if I don't like something, wait until it's done generating, maybe stretch or read something, kick into manual gear to iron out details, call it a day.
Sometimes I wonder if LLMs even help at all. They seem to make programming easier, but the cognitive load has reduced only marginally, but you still need to know what you're doing when reviewing it, is reviewing code easier than writing code? Is reviewing code you didn't write easier than manually writing it and bit by bit building context in your head?
Everyone calls those tools miraculous and we get the impression it makes our lives easier. But to my knowledge no data has proven this is the case, apart from wild sensationalistic claims by CEOs and other LLM figureheads.
If there's something I know is that our perspective is very often flawed, and our feelings can deceive us into believing things. We are wired to be lazy, is it far fetched to say LLMs make things easier, not better?
The flow came back for me when I dropped to a single agent with tight feedback. The subtle bugs you're describing are the direct cost of reviewing code you weren't fully in the context of when it was written. Parallelism hid the review from you, but didn't eliminate it.
I personally prefer 3-4 concurrent terminal sessions, working on different projects. Claude code usually runs around everywhere with agents, and sometimes takes 20 minutes to get shit done. During that time I'm shipping open source work, etc.
I use my own tools to help: Sugar and RemembrallMCP. Sugar is used for memory that's stored outside sessions. So I say store this in sugar memory. If I open a new claude session later, and ask it to lookup sugar memory, it's there.
RemembrallMCP is a AST and code graph that helps the agents understand change impact of your codebase. Instead of insane greps veritical and horizontal, it uses this to quickly understand impact with very high accuracy, time reduction and low token limits.
Game changers.
The other piece I picked up from someone writing about this: treat your head like RAM. When you can't avoid a switch, clear it before moving on. Write the note, close the loop, get it out of your head. The lingering open tabs in our heads are the heaviest load, not the switch itself.
Overall though, I wouldn’t buy too much into the hype of running 1000000x agents at once. The quality simply isn’t there yet IMO, hence the agent management overhead/tax we’re feeling.
As a result of this I've switched almost entirely to using qwen-coder3 locally in FIM autocomplete mode, and that's been pretty fantastic. Since I'm still doing most of the programming myself I keep the codebase loaded up in my brain the way I'm used to but so much of the tedium of programming is accelerated by the mind-reading autocomplete with 300ms latency (to useful completion, not first token).
Agents are neat but fundamentally it's a hack on top of the best autocomplete you could imagine, I find using it to do the thing it actually does gives me by far the best UX.
When running multi-agent I recommend keeping an eye on the flow of the work. Is it touching files that make sense? Has it been spiraling too long, is it pulling in packages? Things I can eyeball quickly without fully committing to that context. A full review of that sus diff would make me context switch, but seeing it's editing only files in a related part of the codebase is low effort.
I have bmad integrated. and what I usually do for each session is: * call a start command that loads all the relevant documents and context; * call the bmad quick-dev or quick-spec slash commands that load an specialized agent. * at the end I update the documentation, commit, push, create pr, clear the session; * start from the beginning
If you do the above, and have enough basis as documentation, you can loose a little bit and let it run wildly, but like with human developers, some regular control might be needed. No way without it.
The closest I attained to flow state vibe coding involved building UIs with claude 4.6 fast mode low thinking, a local TTS model (nvidia's), and hot reloading browser.
Arguably maybe I could have done better on higher thinking and then done more in parallel but it is more tiring.
I tried using an agent and even just one had me stressed out. I can’t imagine running multiple, I’d go insane. If a tool is causing me more stress, it’s not the right tool for me.
Reading about the problem you are solving with the agent is good. Less of a switch. E.g. it implenents calling an API. you read the API docs end to end so you can review better.
Human brains didn't evolve to be proicient at cognition-heavy multi-tasking. You can habituate yourself to it to some extent, but there's a good chance that your exhaustion is your body asking you not to treat yourself like a machine.
Use Opus fast, Codex-Spark or Cerebras. No more spinner starring. Instant results. One project at time.
It is akin to asking, "How do you get a runner's high when running in the Nike Vaporfly?" You don't. What you _can_ do is improve your core strength, endurance, cardio, etc. Then, there will come a day, if you are consistent in your running, when, while running, you are less worried about tired legs and generally feel "open" and feel like flying. That day, you will push your pace and realise "oh shit" and bonk. That day you realise that your body and mind are not ready for sustaining a very high pace for a long time. You start doing interval training, hill repeats, and so on. A few months later you try to push the pace again on a good day and voila, you love it! Pure running bliss.
The same is true for engineering. If your "multitasking" muscle/mechanism is weak, if your orbital-prefrontal cortex is weak and you get distracted easily, then no amount of process hacking will get you to flow state. So first understand your mind, understand your body, understand your weaknesses. Work on them consciously, deliberately.
As for me, I can work on at most 2, maybe 3, projects at a time. I observed that my mind works well as a stack, and I am good at pushing context from one project onto the stack, loading the next project's context, then pushing it onto the stack and starting work on the next one. Finish it, then pop to the previous project, and keep going around. When my mind feels weak, I use digital sticky notes or just jot down notes somewhere to maintain context between projects, to just drop down t o focusing on 1 project a time.
I've tried using agentic development for something I understood well, and every time, it's frankly fucking sucked. Even if the output was good - which it usually wasn't - it just didn't feel like the same type of work I actually want to do.
Things like line-completion is fine, though - except comments; I wish I could tell VSCode's Copilot to never write a line of human thought.
Say you have one test that checks if Y works properly. The point of the agent harnesses is that you can throw them at that problem, and they'll return once Y works properly according to that test. How the test is structured, or how the agent triggers it, or what the agent is willing to do to pass that test, is all up to you.
But if you manage to set things up like that, you're not longer relying on any "slot machine behaviour", at least as we commonly understand what that is.