I have mixed feelings about vibe coding. Hey, maybe you do too. But ignoring it won't help. AI-generated code is already in production everywhere, and the funniest thing happens: it doesn't magically get its AI slop sticker. Chances are that's not going away anytime soon. So I'd rather experiment with it now and figure out how to think about it. Maybe treat it like learning a new programming paradigm, useful even if you end up deciding against using it.
In this article we're going to explore a framework to think about vibe coding, multitasking and decision making, borrowing some concepts from StarCraft. They have been tackling the same challenges we're facing now, building systems and vocabulary to think about them since 1998.
Here's a question, how many projects are you usually working at the same time? My record was about 8. Yikes. I literally made a script to cycle to the next tmux window with an idle claude code session. Vibe coding makes multitasking so tempting because the cost of starting something new feels close to zero. In fact I'd go so far as to say spinning up another project while you wait is the path of least resistance. But the promises of 1000x productivity soon made us realize how infinite productivity breaks our brains (covers a lot of the issues we're talking here).
Maybe you think multitasking is a thing, and I could agree with you, but then we'd both be wrong. What we actually do is more similar to sequential juggling. You throw ball 1 in the air and move to ball 2. When ball 1 needs attention again, you come back. Except the balls don't all fall at the same speed. And you adapt in real time, depending on the whole ball-situation thing. Now listen, I'm not saying you should stop throwing your balls, but instead suggesting you do so with intention and awareness of the costs.
You know what's basically an entire sport built around this? StarCraft. Yes, really. We're going that way.
In a StarCraft match you're doing everything at once. Moving units, positioning them. Building more stuff, picking the right army composition to counter your opponent. Aaaand you forgot your upgrades again. But strip it down to its essence and StarCraft is an essay in decision-making and juggling. There are just too many things to do and not enough time. And you gotta choose what happens and what doesn't. Programming seems to be moving in a similar direction, and most of us simply are not well equipped to think about these systems.
Acknowledge and Separate your Micro vs Macro
In StarCraft we have this concept of micro vs macro. Micro is focusing your attention on a single task to maximize its effect. Individually retreating injured units during a fight, squeezing out every advantage. Naturally, macro is the big picture. It's picking out the right tasks to do, perhaps most importantly, which ones not to. Building the right economy, choosing the right army composition, knowing when to expand and greed for resources.
Hopefully you are already drawing the parallel to code. Micro is your prompting, how well you read the generated code, how much you test it. Macro is whether you should spin up another claude code session or switch projects in the first place. The benefit of separating these two in your head is that when something goes wrong, you can tell which one failed. Was it a bad decision or bad execution? Different problems, different fixes.
Well, you need them both. Insane micro doesn't matter if every macro decision you're making is wrong. And perfect macro isn't enough if you're too slow to execute. By now a tradeoff picture should be forming in your head.
But here's what most miss: the tradeoff between micro and macro is completely personal. Do not offload this decision to someone else. Doesn't matter how much you think they are better than you.
Okay. So what's the best approach to figure out where your limits are?
Train Hard, Play Safe
When a seasoned StarCraft player trains, they push everything. Put themselves in impossible situations on purpose. Ones they know they'll fail. The point isn't to win, it's to build muscle memory and subconsciously map out what they're capable of. This builds up your inner compass that guides your juggling. On an unrelated side note: I once heard a player call this "ceiling edging" and I hate it.
In games that matter, players do the opposite. They focus on the basics and let everything else come naturally. Calculated plays over fast ones. Nothing forced beyond their well established limits. Two fights happening at the same time? Retreat from one to give full attention to the other. Lose a few units pulling back, sure. But they won't lose a critical mass that costs them the game.
Around 7 minutes into a Terran vs Protoss game, you're attacking with an army. And you need to land your third base. Set rally points. Maybe you have a drop harassing the enemy base in a corner. Maybe your opponent is counter-attacking. And you can't stop producing units. All of this costs attention too, it is a resource you should learn how to manage.
Some games, they know that focusing on the attack wins it outright or cripples the opponent. So they do that. Third base never lands. They don't defend a counter-attack because full attention on the front is worth more. Other games, the attack won't end it. The game will go on. So they pull back slightly, buy 2-3 seconds, use that window to land the base and set rally points. Lose a bit of momentum but enter the midgame with a proper setup and an intact economy. See where I'm going with this?
Replace the army with claude code sessions. Maybe the rally points are your tests failing on another tab. The third base is that startup idea of yours. The drop in the corner is a slack message. Same decision. Do you stay focused or split your attention? And do note that "just stay focused" is an oversimplification of the problem we're dealing with here. So what should be the priority? Your answer should depend on your micro and macro.
It is a good practice to train micro to its limit so you know exactly where your ceiling is. Then in real games, make macro decisions based on that. You'll want to be at a point where you know what juggling you can handle and what would crash everything. And I remind you sometimes it's not a loud crash, but a silent -50% debuff on your productivity across all projects you're juggling.
Know what else got multiplied by 1000x? Cognitive Overload
For the record, I'm a terrible StarCraft player. But I have dear friends who are absolutely brilliant at it (like, top-100 worldwide on SC2 Aligulac). And I've talked to them about this: In-game, their sequence of actions happens naturally, without much thought. Thank you pattern recognition brain (built over thousands of hours). Complex groups of actions happen automatically, the result of a single, abstract thought.
This is what we should aim for in programming. Don't take my word for it, ThePrimeagen often talks about this: the sheer amount of cognitive load we tragically bring upon ourselves (macbook users with that app-explosion view I'm looking at you). Sure, we like to joke around saying skill issue. But in reality, it's more like a choice, isn't it? You don't need an LLM to grep your codebase. And you shouldn't have to think how to search across your files. Search is the intent and the commands should be second nature, doesn't matter if you use vim, vscode-forks, or if you just rawdog ripgrep on a terminal. The less you think about your tools, the more attention you have for the actual juggling.
What to take away from this
-
Multitasking doesn't exist. What you're doing is juggling, and juggling has rules.
-
Separate your micro from your macro. Micro is how well you execute a single task. Macro is whether you're even doing the right tasks.
-
Train and perform differently. Push your limits in side projects, experiments, low-stakes work. When it matters, play within your known ceiling.
-
Reduce cognitive overload everywhere you can. Reducing friction was important before and now it matters 1000x more. Make your environment yours.
-
Your micro-macro tradeoffs are unique to you. Someone else's workflow is not your workflow. Figure out your own ceiling by testing it, not by copying someone with a different brain.
Hopefully this helps you reason about your own choices when vibe coding. Next time you're running multiple projects at the same time and claude code finishes with two other things waiting for your attention, notice how you decide what's next. That's the whole game.