DEV Community: Zhao KK

I Ran 10 AI Coding Agents in Parallel. Then I Built a Tool to Manage Them

Zhao KK — Wed, 05 Aug 2026 04:24:04 +0000

A CLI-first workspace manager for developers running multiple AI coding agents

In my previous article, I wrote about running multiple AI coding agents in parallel.

The surprising conclusion was:

The bottleneck was not AI anymore.

It was me.

The agents became faster and more capable, but my own workflow started breaking down.

I had too many things to track:

Which agent is working on what?
Which one is waiting for my input?
Which one finished?
Which terminal session belongs to which project?
Which machine is running that agent?

The problem was no longer:

"How do I make AI code faster?"

The problem became:

"How do I effectively work with many AI agents at the same time?"

After experiencing this problem repeatedly, I started building a small tool for myself.

That tool became WaitAgent.

GitHub:
https://github.com/kikakkz/wait-agent

After hundreds of iterations, I finally feel comfortable releasing the first public version:

WaitAgent 0.1.0

This Started As A Personal Tool

I did not initially plan to build another developer tool.

I just wanted something that solved my own daily workflow.

My current development environment is quite different from a traditional IDE workflow.

I usually work with:

terminal
SSH
multiple machines
multiple repositories
multiple AI coding assistants

A typical day might look like:

Machine A
 └── Claude Code
      └── backend refactoring


Machine B
 └── Codex
      └── frontend implementation


Server C
 └── another agent
      └── experiments

Everything works.

Until it doesn't.

The Problem Was Not Running Agents

Running multiple agents is surprisingly easy today.

The difficult part is keeping track of them.

After a few hours, my environment looked like this:

I found myself repeatedly asking:

Where is that agent?
What was it doing?
Did it finish?
Does it need me?
Which machine was it on?

The agents were productive.

But my attention was becoming the bottleneck.

Then My Network Failed

This was another problem I didn't expect.

Imagine:

You have several agents running on remote machines.

Everything is working.

Then:

Wi-Fi disconnects
VPN changes
laptop switches networks
SSH connection disappears

The agents are still running.

But your control connection is gone.

Before WaitAgent, recovery looked like this:

Reconnect VPN

SSH machine A

Find tmux session

Remember what agent was doing


SSH machine B

Find another session

Try to recover context

The frustrating part was not reconnecting.

The frustrating part was rebuilding my mental context.

The hardest part was not restoring the terminal connection.
It was restoring the developer's state of mind.

Existing Tools Solved Only Part of The Problem

tmux is great, but it doesn't understand agents

I have used tmux for years.

It solves an important problem:

Keep terminal sessions alive.

But tmux only knows about terminals:

window 1
window 2
pane 3

What I needed was something closer to:

Backend Agent
  Claude Code
  Running


Frontend Agent
  Codex
  Waiting


Research Agent
  Completed

The terminal became the workspace.

But I needed a layer that understood my workflow.

I didn't need another AI framework

There are already many excellent AI agent frameworks.

But I was not trying to create:

another autonomous agent system
another workflow engine
another coding assistant

I wanted something much simpler:

A better way for humans to supervise many agents.

Introducing WaitAgent

WaitAgent is a CLI-first workspace manager for developers running multiple AI coding agents.

The idea is simple:

                 Developer

                     |
                     |

                WaitAgent

          /          |          \

     Agent A      Agent B      Agent C

    Claude       Codex       Other CLI Agent

WaitAgent does not replace your agents.

It helps you manage the space around them.

Why CLI First?

I intentionally built WaitAgent as a CLI-first tool.

Not because GUI is bad.

It is simply because this is how I work.

I have always been more comfortable working in the terminal. I use IDEs occasionally, but most of my daily workflow happens through:

terminal
SSH sessions
command-line tools
remote machines

When I started using multiple AI coding agents, this workflow became even more natural for me.

The terminal is where I usually:

start agents
check their progress
review changes
run tests
inspect logs
switch between projects

So I built WaitAgent for the environment where I already spend most of my time.

What WaitAgent Does Today

1. A Single View For Multiple Agent Sessions

When running multiple AI coding agents, the first problem is simple:

Where are all my sessions?

Before WaitAgent:

Terminal 1

  Claude Code


Terminal 2

  Codex


SSH Terminal

  Another agent

The problem was not that these sessions disappeared.

The problem was remembering where everything was.

WaitAgent provides a sidebar where you can see your sessions in one place.

For example:

Sessions

> bash@local                 I
  claude@192.168.31.125      R
  kimi@10.235.6.45           R
  codex@192.168.31.133       R

2. Multi-Machine Session Management

My agents do not always run on the same machine.

Sometimes they run on:

Laptop

   |

Server A

   |

Server B

The challenge is not starting these sessions.

The challenge is keeping track of them.

Without a session manager:

ssh server-a

find session


ssh server-b

find another session

WaitAgent allows me to manage sessions from different machines through the same interface.

3. Recover Sessions After Network Interruptions

This is one of the reasons I built WaitAgent.

When working with remote machines, network interruptions are inevitable.

Maybe:

Wi-Fi changes
VPN disconnects
laptop sleeps
SSH connection drops

The agents may still be running.

But the developer loses the connection.

Without a session manager:

Network lost


Reconnect


Find machines


Find sessions


Recover context

With WaitAgent:

Network lost


Reconnect

Continue from existing sessions

The goal is simple:

A temporary connection problem should not destroy your development flow.

The Design Philosophy

While building WaitAgent, I kept coming back to one simple idea:

Developers need visibility before automation.

When many agents are running, the first challenge is not making them more autonomous.

It is knowing:

What sessions exist?

Where are they running?

What state are they in?

Which one needs my attention?

WaitAgent focuses on making this information visible and reliable.

The future workflow may look like:

1 developer

+

10 AI agents

+

multiple machines

The challenge is not only making agents smarter.

It is helping humans stay productive while working with many agents.

What Comes Next?

WaitAgent 0.1.0 is still an early version.

Some things I am exploring:

better session state tracking
easier session switching
richer remote workflows
notifications
integrations with external tools

But I want to keep the core idea simple:

Help developers stay connected with their AI coding sessions.

I Want To Hear From Other Developers

I built WaitAgent because I had this problem myself.

But my workflow might be unusual.

I would love to hear from developers experimenting with multi-agent workflows:

How many AI coding agents do you run at the same time?
Do your agents run on multiple machines?
How do you manage sessions today?
What information do you want when switching between agents?

If you are running multiple AI coding agents, I would love your feedback.

Repository:

https://github.com/kikakkz/wait-agent.git

Final Thoughts

AI coding agents are becoming more capable every month.

But when one developer starts running many agents, a new problem appears.

Not intelligence.

Not execution.

Continuity.

How do we keep our context when our work is distributed across many sessions and many machines?

WaitAgent is my first attempt to explore that future.

I Ran 10+ AI Coding Agents in Parallel. The Bottleneck Wasn't the AI.

Zhao KK — Wed, 22 Jul 2026 01:22:46 +0000

AI coding agents changed the way I work.

When I started using them, the workflow was simple:

Give an agent a task → wait → review the result → continue.

Running one agent was easy enough.

Then I started running multiple agents in parallel.

At first, it felt like a huge productivity boost. Different agents could handle different tasks at the same time:

1. one agent implementing a feature
2. another fixing bugs
3. another exploring a technical approach
4. another reviewing code
5. another handling repetitive tasks

The limiting factor no longer seemed to be how fast I could write code.

Then something unexpected happened.

The bottleneck became me.

My current setup

My workflow usually involves more than 10 agents running at the same time.

They are not all the same type of agent:

1. Claude Code
2. Codex
3. Kimi
4. other task-specific agents

More than half of them are coding assistants, which means they consume a significant amount of CPU and memory.

Running everything on one machine is not practical, so I spread them across multiple machines and manage them remotely through terminal sessions.

On paper, this sounds like a good setup.

In reality, it creates a different problem.

The problem is not running agents. It is knowing what is happening.

When you have many agents running, the first question is no longer:

"Can this agent finish the task?"

The question becomes:

"What is every agent doing right now?"

I started noticing that I was spending more and more time checking sessions instead of making decisions.

Questions like:

1. Is this agent still working?
2. Did it finish already?
3. Is it waiting for my input?
4. Did it get stuck?
5. Is this session still relevant?

The agents were running, but my visibility was getting worse.

Context switching becomes the real cost

The biggest mental overhead comes from switching between sessions.

Every time I open another terminal tab, I need to reconstruct the context:

1. What was this agent working on?
2. Why did I start this task?
3. What decisions were already made?
4. What should happen next?

This is manageable with one or two agents.

With ten or more, it becomes exhausting.

The problem is not that the agents are not capable.

The problem is that humans are still limited by attention.

Multiple machines make it harder

Because coding agents are resource-heavy, many people cannot simply open 10 agents on one laptop.

My workflow requires multiple machines.

Remote terminal tools work well for connecting to those machines, but they mostly show the terminal itself.

They don't tell me:

1. which sessions are active
2. which ones are waiting
3. which ones finished
4. which ones need attention

So the only way to know is manually checking each tab.

Ten agents means ten context switches.

tmux solves a different problem

I have tried tmux and other terminal multiplexers.

They are excellent tools.

They solve an important problem:

How do I keep my sessions alive and organized?

But managing multiple AI agents introduces another problem:

How do I manage my attention across many autonomous processes?

Keeping everything visible is not always better.

A screen full of active sessions can become another source of distraction.

More information does not always mean more clarity.

I think we are entering a new workflow problem

For years, developers optimized their workflow around:

1. editors
2. terminals
3. build systems
4. CI pipelines
5. version control

AI agents introduce another layer:

Multiple autonomous workers running simultaneously.

The challenge starts to look less like traditional programming and more like supervising a small team.

Not because agents need constant supervision, but because humans need a way to understand their current state.

Curious how others are handling this

For people running multiple AI coding agents:

1. How many agents do you usually run at the same time?
2. Are you mainly using CLI tools, IDE extensions, or web interfaces?
3. How do you keep track of which agent needs your attention?
4. What breaks first for you: context switching, approvals, or simply mental overhead?

I’m interested in hearing how others are adapting their workflows.

Hello DEV Community 👋

Zhao KK — Fri, 17 Jul 2026 02:53:09 +0000

I'm KK.

For most of my career, I've been building software — sometimes for products, sometimes for ideas that were not ready for the world yet.

I have always been fascinated by the invisible layers behind technology: how systems communicate, how tools shape the way we work, and how a simple idea can eventually become something people rely on every day.

Over the years, I have worked on different areas of software engineering, from low-level systems to developer tools, from infrastructure to emerging technologies. But the thing that keeps me excited is still the same:

building something from nothing.

Recently, I've been spending a lot of time exploring AI and how it is changing the relationship between developers and software.

AI is not just another tool. It is changing the way we think about creating things — how we write code, how we solve problems, and how a single developer can explore ideas that once required a much larger team.

I enjoy experimenting, breaking things, rebuilding them, and learning through the process.

I joined DEV because I want to share some of these journeys:

things I build
problems I encounter
ideas I am exploring
lessons learned along the way

I don't have all the answers, but I believe the best part of technology has always been the conversations between people who are curious enough to keep building.

Looking forward to connecting with developers, builders, and anyone who enjoys creating things.