More agents, same human brain – Codeaholicguy

Skip to content

codeaholicguy

AI, ai-devkit, Software Engineering

06/03/202606/03/2026

11 Minutes

I have been running multiple coding agents at the same time for a while now.

Sometimes I have Claude Code working on one feature, Codex reviewing a plan, Gemini CLI exploring another direction, and another Claude session fixing a smaller issue in parallel. On paper, this sounds like the future of software engineering. One engineer, multiple agents, multiple streams of execution are happening at the same time.

And honestly, it is exciting.

For the first few minutes, it feels like I suddenly have a small engineering team around me. One agent can build, one agent can review, one agent can explore an alternative, one agent can check if the plan makes sense. Instead of waiting for one task to finish, I can start several pieces of work and let them run.

But after doing this for long enough, I realized the hard part is not starting more agents.

The hard part is keeping up with them.

The old productivity equation is changing

In the past, engineering capacity mostly scaled with people.

If we wanted to do more work, we hired more engineers. That gave us more hands, more thinking capacity, more reviews, more parallel execution, and more ownership. Of course, it also added communication overhead, meetings, planning complexity, alignment cost, and all the usual coordination problems that come with growing a team.

But the basic model was simple: more people meant more capacity.

AI changes that model.

With coding agents, one engineer can now start multiple streams of work at the same time. The amount of work we can attempt is no longer limited only by the number of engineers in the team. It also depends on how many agents we can safely direct, review, and coordinate. This is a big thing.

It does not mean headcount no longer matters. That is too simplistic. Great engineers still matter a lot because judgment, system understanding, product context, and ownership still sit with humans.

But the scaling model is changing.

In the future, the question may not only be “how many engineers do we have?” It may also be “how many agent workflows can these engineers safely orchestrate?”

The word "safely" matters because generating more code is not the same as creating more good software .

Why I started running everything at once

Part of my motivation is practical.

I already paid for multiple AI subscriptions. Claude, ChatGPT, Google AI, and a few different tools around them. I do not want to use them in a slow sequence: use Claude first, wait until I hit the limit, then switch to Codex, then switch to Gemini when something else runs out. That feels wasteful.

If I have multiple tools available, I want to use them at the same time. Not because every tool is equally good at every task, but because different tools have different strengths, speeds, limits, and behaviors.

Claude Code may be better for one kind of implementation. Codex may be useful for reviewing a plan or taking another pass at the same problem. Gemini CLI may give me a different perspective. Sometimes the value is not that one model is clearly better, but that they do not fail in exactly the same way.

So I started thinking less about “which tool should I use?” and more about “how do I compose these tools together?”

That is where things get interesting.

One agent can implement a feature, another can review the plan before implementation, another can generate tests, another can inspect the diff and look for edge cases, another can explore a simpler version of the same solution.

I am no longer just doing AI-assisted coding. It starts to look more like orchestration.

The first wall I hit was not code quality

I expected the first major bottleneck to be code quality.

That is still a real problem. AI-generated code can be functional but wrong. It can pass the happy path while missing the edge cases, it can create abstractions that look clean in isolation but do not fit the existing system, it can confidently change things it does not fully understand.

But surprisingly, that was not the first wall I hit.

The first wall was tab switching.

Personally, I use tmux heavily. I arrange agents by session, window, and pane. One session for a feature, one session for another experiment, one pane for a running server, one pane for tests, one pane for a coding agent, another pane for a review agent.

This works quite well when the number of active streams is small.

If an agent needs my attention once an hour, no problem. I can switch to it, read the output, make a decision, and move on.

But agents do not work at human speed.

They generate code fast, they ask for confirmation, they hit errors, they finish tasks, they need permission, they ask whether to continue, they suggest a plan, they wait for feedback. When that happens every few minutes, tab switching becomes more than a small annoyance.

I found myself...