While we search for the true future of vibe coding with Claude Code, Codex, or otherwise, one thing that I’ve seen emerge over this last 10 months are two very different kinds of software engineers:

1. The linear programmer: using VSCode LLM Autocomplete and GitHub Copilot
2. The parallel programmer: several ClaudeCode/Codex terminal windows open

I’m in the “top 0%” of parallel programmers as of writing this for my organization. This means I’m constantly chatting in several iTerm2 tabs with ClaudeCode/Codex.

Now, I love eating baked goods and whenever I’m watching a chef making a delicious croissant or pizzas, they are always doing many things at the same time: checking the incoming ticket, prepping the next thing, checking the oven, pulling things out that are done.

This is basically what software engineering looks like in July 2026. Software Engineers are bakers with several ovens, where those ovens are tabs in a terminal window.

This reminds me of the same behavior Software Engineers had around building and compiling – in the J2EE days, you’d have to build all of your code which could take 30 minutes to hours, what you did with that time, in my opinion, defines the person. You could take a break and get coffee or you could start working on something else while your code builds – agentic coding today is basically this but now it includes building and deploying plus the agentic loop.

My tabs are roughly this:

1. Code review loop tab – every 10 minutes, use a custom skill that looks at all past significant bugs, incidents that are related to the current pull request (Meta calls them “diffs”), any currently open pull requests that might overlap and cause merge conflicts (better to spot these early and chat with the other engineer). I use Codex 5.5 for this right now since most people are using ClaudeCode to write code, I wanted a different mindset for my code reviewer.
2. Technical Program Manager tab – look at the work the team has done over the last week or day, aggregate and publish this into chat, flag any things that are slow or risks the team has made by creating a task with a [risk] title prefix, look at the current state of our dependencies (for us it’s devices and sensors), so we’re aware if milestones are shifting.
3. Personal Agent tab – If I’m thinking about an idea, or I need to follow-up with something, read a document, I always give it to this agent first to either creating a Task for me later with enriched information, or to schedule a block on my calendar.
4. Crash tab – I’m constantly hunting for crashes (most of our devices are running on Android OS), trying to devise a test to replicate it, and then a fix for it. I think this is the largest gap with agentic coding today, we’re unable to write code that doesn’t crash.
5. Workstream tabs (~3) – I might be building out a dashboard or report (more Data Science and Data Engineering mixed with Product Management), adding important debug logging, building out the data flow for a product, doing data analysis – I usually have about 3 tabs open for this work.
6. Big bet – there’s usually an idea that I’d like to through agentic AI at where I’m building a prototype.

Now you can see why I’m always chatting with some agentic solution in parallel, at even given moment one of these terminals has completed their work and I’m giving it it’s next instruction.

If you’re waiting for your terminal to finish before you’re giving another instruction, think about how you can add another oven to get something else done, especially if your company has no token budgets. But if you are tight on token spend, try to at least get into Planning Mode, that will get some code exploration out of the way for you while your balancing manual code with agentic code writing.