Ask HN: How do you maintain flow when vibe coding?

We have asked ourselves that question repeatedly over the past year. While I don’t have a simple solution, I have some mental models that may help.

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.

I do constantly 3-6 agents simultaneously. It is definatelly exhausting however productivity is through the roof. Make sure to be dynamic and don't follow pre-set patterns. E.g. sometimes you need to switch and just steer (you could quickly), sometimes you need to understand the solution proposed / changes done (it could take hour). Retain the human in the loop and think.

I don't understand the appeal of parallel agent programming.

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?

Running N agents in parallel creates serialism at the human level, not parallelism. You're one brain, and each context switch costs 15-25 minutes of re-entry. Three agents in parallel means your effective output is roughly one agent's worth, minus the switch tax.

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 spent time on this one because context switching was already my baseline before Claude Code because of the nature of my job; what's worked best: I force myself to ask why I'm launching things in parallel. Is it a real deadline? Back-to-back calls? Or am I just trying to feel more productive? If it's the last one, it's probably not worth it. Very few people actually multitask well. Write the task somewhere ( or have a todo skill that does it for you)

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.

Are you using multiple agents on the same project? If you are, use git worktrees.

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.

I have a skill called /devlog that will have it write down what we've been doing that session in a a file , like a captain's log, basically a tracker so i don't get lost in the mess. I have another skill I made called /makeblog where it does the same type of thing, but a blog post, not someting i publish or anythign, jsut for me that does an output of that sesssion.

Are you working on the same overall project or many separate projects? I find that makes a difference (entirely separate projects being more difficult for context switching of course).

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.

I've basically stopped using agentic AI completely as I've found the easy wins it gets me almost always come with tons of debt I have to pay down later. I specifically find the loss of situational awareness that comes with agentic development to cost far more than the utility I get from the code it writes.

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.

Same boat. 5 agents is my hard limit, past that I lose the thread and it stops being guided coding, turns into vibe coding. I lean into the context switch instead of fighting it. Plan a large task, kick the agents off, walk away. My rule is whatever I switch to has to be little productive than watching tokens stream or shorts. usually a workout or a research video. Reframes the wait for me. For review I go in other direction: spin up 50 to 100 review agents to audit everything and rank issues by severity. I work through the blockers manually and read the actual diffs. Handles most of the bug compounding problem you mentioned. It’s a kind of flow. Definitely not the same as writing the code ourself, nothing is. Just the closest substitute I’ve found in this era

I only use parallel agents when I have simple tasks to get done on all projects. Cleanup, running evals, etc. That whole day becomes parallel agents on easy tasks. Otherwise I do tight feedback loops on single agent (with subagents).

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 get the best output when I work on a single project or 2 entirely different projects at the same time. Example: work + a side quest or prototype where agents cannot overwrite each other's code. I can add a third stream of real world productive tasks, example: do the dishes.

I work task by task, like I usually do without AI agents. Working with multiple agents is just too much for me.

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.

AI is yet to solve one of its biggest problems, which is memory. So I trust my memory. I maintain the workflow momentum so I'm always aware of what I did, what I'm doing, and what I'll do. Also, I maintain a lot of markdown files for longer contexts to refer to later. But it's not foolproof. Sometimes I have to rethink the same thing again, and it pushes me in a whole different direction.

A classic but I think relevant pg essay - https://paulgraham.com/makersschedule.html

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 build a bunch of tools[1] that give the agents means to communicate and coordinate between each other, with me mostly just deciding what goes into the backlog, and checking their summaries whenever they finish a task.

https://github.com/triblespace/faculties

I still use Claude more has a helper and almost never use agent mode, and thus still work single threaded. I ask questions, for examples, and ideas on how it might do something.

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.

One task at a time. Zero your inbox while waiting for the agent. Or read / do a course. Etc.

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.

Do one thing at a time, and do it well.

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.

have enough sessions going that you just cycled through them and by the time you get back that chat is ready to go again. Easier sometimes staying in same project, sometimes easier if you don't use worktrees to work on different projects.

Quantity have quality of it own. Or in case of Code Assistants - speed.

Use Opus fast, Codex-Spark or Cerebras. No more spinner starring. Instant results. One project at time.

If I understand the research on flow state, you can’t. Not all tasks are compatible.

The answer to your question has less to do with "vibe coding," "harness," and all the jargon and "productivity guru speak."

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.

Is it even possible to get into anything resembling such a state? Do managers enter flow state?

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.

Sorry for not answering your question, but asking how to not let something do your work for you not be so exhausting is like listening to a billionaire complain that they have to instruct their maids and chefs too often.