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

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.

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

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.