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.

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.

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.

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.

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.

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.

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 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?

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.

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.

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.

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.

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

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.