Optimal Vibe Coding Isn't Running 6 Claude Code Tabs. It's Running One.
Don’t be fooled by influencers peddling FOMO. Do one thing at a time.
Originally published on LinkedIn, March 2026.
Steve Yegge recently published his 8 Stages of Dev Evolution to AI, a maturity model for agentic coding that culminates in Level 8: building your own orchestrator to manage dozens of parallel AI agents. It’s compelling. He built Gas Town to do it. It’s remarkable.
I don’t think it should be your goal.
The Temptation
Claude Code is amazing. I love it. It can do so much, so fast. And what do you do while you wait for it to finish? Brainrot dopamine mill? How about another Claude Code session. And another. You’re only limited by how fast you can review each session’s output. You are suddenly matching the output of an entire team, or more.
This is intoxicating. It feels like a superpower. For a few days, it is.
The Crash
Then, you hit a wall. An unexplainable, deep fatigue. Post-work tiredness dialed up to 11.
It’s not just you. An 8-month study of 200 employees at a U.S. tech company, published in HBR, found that AI tools don’t reduce work — they consistently intensify it. Workers moved at a faster pace, took on a broader scope of tasks, and extended their workdays, often without being asked to. 83% said AI increased their workload. The majority reported burnout.
The pattern the researchers identified is exactly the multi-agent trap: “workers increasingly kept multiple threads alive at once, running AI processes in the background while doing other work and sometimes running multiple AI agents simultaneously.”
It’s Worse Than You Think
Humans are famously terrible at context switching. It might be the single biggest productivity sink in agile software teams. And the research is unambiguous.
Gloria Mark at UC Irvine found it takes an average of 23 minutes and 15 seconds to fully refocus after a task switch. The APA’s research on task switching (Rubinstein, Meyer, & Evans) showed that time costs increase with the complexity of the tasks — and what’s more complex than reviewing code diffs? Sophie Leroy’s work on “attention residue” shows that part of your brain stays stuck on the previous task, and for developers working with complex abstractions, that residue can linger for 30 to 60 minutes.
You’ve heard this before, right? And now the pitch is that we should context-switch all day, every day, several times a minute?
It’s not a good idea.
A Diagnosis, Not a Roadmap
I don’t disagree with Yegge’s model as a description. It accurately described my journey, too. But I am afraid that people see it as a prescription — as a developmental roadmap. The FOMO says, “Not at level 8? You’ll never escape the permanent underclass.”
I reject such framing. Sure, multi-agent orchestration is great for well-defined problems, like test suite overhauls, and I’ve even used it to parallelize work across microservices, having agents coordinate on API contracts and end to end testing. But this type of work is the exception. Orchestration is a tool, not the tool.
The Bottleneck is Not Software
Claude Code generates lots of code, very quickly. Gas Town generates code faster than anyone can review, by design. But lines of code do not correspond to value delivered, and more code written more quickly and with less oversight does not mean value is being delivered.
In real life, most of what makes software hard is everything around the code. The business requirements. The constraints nobody wrote down. The edge case your PM hasn’t thought of yet. The stakeholder who hasn’t settled on a value proposition.
Level 9: Pair Programming
Here’s what I recommend instead: think clearly, in writing, about the value you are delivering. Then, while your agent is churning, do what it’s doing. If it’s reviewing code, review alongside it. If it’s designing an approach, design alongside it. While it’s writing, review its diffs in real time. Stay with it.
Treat it like a pair programmer.
Anyone who’s done pair programming knows the difference between a good session and a bad one. In a good session, both people are locked in — one implements, the other watches, catches mistakes, and thinks ahead. In a bad session, one person zones out and checks their email.
Running six Claude Code tabs is being the bad pair partner to six agents simultaneously. Running one tab, with your full attention, is being a great pair partner to one. The second approach produces better software. Every time.
And your partner needs the attention. Even Opus 4.6, which I love, makes mistakes. Frequently! Unoptimized code. Over-optimized code. Strange python workarounds to bash commands. “Pre-existing” test failures. Temporal mistakes where it uses deprecated APIs or invents functions that don’t exist. They are better at writing code than most of us, and better at reviewing it too. But they don’t reason like humans, and they require your attention. Your full attention.
Level 9
Engage with your customers. Talk to your users. Write clear specs, because clear specs require clear thinking. When it’s time to code, sit with your agent. Do one thing at a time.
Finish your day with some gas left in the tank.
There’s one more surprising benefit to working this way: my engineering ability has actually improved. While anecdotes abound of skill atrophying in the era of coding agents, pair programming keeps you in the code — reading, evaluating, and learning. It would be worth it just for that.