Hey HN, I'm Prateek. About a week ago I started building a tool to manage my AI coding agents. In 8 days and 134 commits it's merged 80+ of its own PRs and largely built itself. 2,700+ GitHub stars in two weeks.
It started super hacky. I was running a bunch of Claude Code sessions and just built a quick agent that could switch between them and take me to the right session at the right time. That alone got me to 13 PRs in a day.
Then I started using that same agent to plan too — look at what's in the backlog, figure out what matters most, scope tasks, send agents off. So I took the hacky version and pointed it at building the proper version. It's been building itself since.
Each agent gets its own git worktree and branch. There's a dashboard so I can see what's going on — which agents are working, what PRs are open, what's failing CI, what has review comments. A merge queue handles rebasing when things land so downstream agents don't build against stale main. If CI breaks, the agent gets the logs and retries. If someone leaves a review comment, the agent addresses it.
The orchestrator itself is an agent too — it reads the backlog, decides what to prioritize, breaks it down, spawns agents. I mostly just review PRs at this point. At peak I had ~16 going in parallel on the same repo.
Works with Claude Code, Codex, Aider. Tmux or Docker. GitHub or Linear. Everything's pluggable.
"Your codebase must be bad" is backwards. Agents perform better on well-structured codebases with clear interfaces and good tests. They struggle on legacy spaghetti.
The mental model that works: treat them like junior engineers. Clear issue, bounded scope, review their PR. Output quality tracks directly with task scoping.
Where it genuinely falls apart: anything requiring context about why something was designed a certain way. Agents can read code, they can't read the Slack thread from 2023.
Nice. PTY pattern matching is the right call for state detection.
I run 16-30 Claude Code sessions in parallel using an orchestrator I built (ComposioHQ/agent-orchestrator on GitHub). Session management is half the problem. The bigger problem is managing your own context around everything that's going on. Which agent is working on what, what's blocked, what just merged, what needs rebasing. The orchestrator is really an optimised human-in-the-loop process. It keeps me oriented so I can make decisions fast instead of spending 10 minutes figuring out what state everything is in.
Have you hit that yet or is this mostly focused on the monitoring side?
It started super hacky. I was running a bunch of Claude Code sessions and just built a quick agent that could switch between them and take me to the right session at the right time. That alone got me to 13 PRs in a day.
Then I started using that same agent to plan too — look at what's in the backlog, figure out what matters most, scope tasks, send agents off. So I took the hacky version and pointed it at building the proper version. It's been building itself since.
Each agent gets its own git worktree and branch. There's a dashboard so I can see what's going on — which agents are working, what PRs are open, what's failing CI, what has review comments. A merge queue handles rebasing when things land so downstream agents don't build against stale main. If CI breaks, the agent gets the logs and retries. If someone leaves a review comment, the agent addresses it.
The orchestrator itself is an agent too — it reads the backlog, decides what to prioritize, breaks it down, spawns agents. I mostly just review PRs at this point. At peak I had ~16 going in parallel on the same repo.
Works with Claude Code, Codex, Aider. Tmux or Docker. GitHub or Linear. Everything's pluggable.
Wrote up how the whole thing works here: https://x.com/agent_wrapper/status/2025986105485733945
Curious if anyone else is running multiple coding agents and what you've tried for coordination.
reply