How One Solo Developer Manages 30 AI Agents at

Three years ago, Kun Chen was at Atlassian, professionally building coding agents for a living. Today, he's solo, managing somewhere between 20 and 30 active GitHub repositories, and he almost never manually writes code anymore. The tooling he built to survive that transition is more interesting than the career arc.

Chen appeared on David Ondrej's podcast to walk through his setup in detail — not a slide deck, but a live screen share of a working system. What comes through isn't someone demoing a proof of concept. It's someone who hit a genuine wall and had to build around it.

The wall was cognitive load. When you're running multiple AI agents in parallel — because one agent on one task takes time, and there's no reason to sit idle waiting — you quickly accumulate sessions. Twenty, thirty tabs, each representing some work in progress. "You have to keep that in your head," Chen told Ondrej. "You need to remember, oh, what is this session, what is it doing." At some point that overhead becomes the job instead of the work.

The Coordinator Problem

His solution is a system he calls First Mate — a supervisory agent that sits above all the others. You talk to First Mate. First Mate delegates. You never need to remember what any particular sub-agent is doing, because that's First Mate's problem.

The mechanics matter here. First Mate runs on a more capable, reasoning-heavy model because it has to hold a lot of context, infer what you mean when you mention a project by its internal nickname, and make routing decisions — which crew mate gets which task, at what reasoning effort level. Sub-agents doing more routine work can run on cheaper, faster configurations. It's a layered economy of compute.

The whole thing lives in a terminal environment built on Herder, a multiplexer that understands the concept of agents natively — it can display whether a session is actively working or waiting for input, which older tools like tmux simply can't. The terminal itself runs on a Mac Mini that Chen SSH's into from his phone when needed. Everything persists. Nothing is lost when he walks away from his desk.

What Chen describes as the best part of this arrangement is the cognitive mode it enables. "I'm constantly in a brain dump kind of mode," he said. "I have thoughts and I just dump my thoughts to First Mate and let First Mate do everything else." The work that remains on his plate is genuinely ambiguous decisions — product trade-offs, architectural choices, judgment calls that can't be automated away. Everything else flows through the system.

This isn't magic. It took months of iteration. Early versions of First Mate had routing problems — wrong crew mate for the task, or multiple crew mates doing the same thing and stepping on each other. Trust was built incrementally, the way you'd onboard anyone to a new role. "I didn't initially just trust it for everything," Chen noted.

The Validation Layer

Generating code fast creates a downstream problem: you now have thousands of lines of AI-written code that need reviewing before you merge. Reviewing all of it manually creates a hard ceiling on how much you can actually ship. Chen's answer is a pipeline he calls No Mistakes.

When he's ready to merge a batch of changes, he runs a shorthand command that packages everything into a branch and hands it to the No Mistakes pipeline. The pipeline first goes back to the original agent session to understand what was intended — the prompt, not just the diff. Then it runs an adversarial review using a separate model (his preference is GPT for this role, which he finds particularly good at identifying rare-but-real edge cases). If the reviewer finds something obvious, it fixes it automatically. If the fix has product implications, it escalates to Chen. After review comes testing, documentation checks, linting, and a push to PR — with the pipeline watching the CI process until it clears.

Chen shared some numbers from roughly three months of use across roughly a thousand changes and 59 repositories: about 63% of the changes had at least one problem caught. The review step found the most issues; documentation staleness — a README still describing behavior that no longer exists — was a consistently significant hit.

The honest counterargument to all this is token cost. Running a full adversarial review pipeline on every change is not cheap, and Chen acknowledges the trade-off directly. His framework is simple: production software with real users gets the full pipeline. A weekend demo doesn't. He also exercises judgment on changes simple enough that he can evaluate them himself, skipping the pipeline entirely. "There's a trade-off to be made on which projects to apply this kind of approach," he said.

This is where human oversight remains non-negotiable even in a highly automated stack — the human isn't reviewing every line, but they're setting the policies that determine what gets reviewed and what gets escalated.

The Interface Problem Nobody Is Solving

The most structurally interesting part of Chen's setup isn't the orchestration — it's his work on what he calls axis, or agent-ergonomic interfaces. His argument is that most tooling built for agents is still designed for humans.

MCP servers are a case in point. Chen benchmarked the GitHub MCP server against the GitHub CLI for a set of common tasks and found, by his account, that the CLI-based approach was consistently cheaper, faster, and more reliable. His explanation: CLIs have existed long enough that the models have seen extensive examples of how to use them. MCP servers are new, often return bloated JSON that agents have to wade through, and haven't been optimized for token efficiency. "It's just worse in every way," he said of the MCP approach for standard GitHub operations.

He's been distilling principles for what good agent interfaces look like — token-efficient output formats, minimal default schemas, not forcing agents to paginate through data they don't need. He's published these under the axi.md framework and built several tools following the principles, including wrappers around the Chrome DevTools MCP server that he says reduced average cost by over 20% without changing any underlying functionality. The interface was the only variable.

This connects to a broader prediction Chen makes: a significant rebuild of existing SaaS software is coming. Most of the platforms built over the past two decades were designed around human interfaces — click here, navigate there, fill in this form. Agents need something different. Headless, stable, well-documented APIs optimized for machine consumption rather than human navigation. Whoever figures out how to be the "new GitHub" for the agent era, in Chen's framing, will need to nail this.

It's a thesis worth examining, because it runs counter to the dominant product instinct in software, which is to make things easier for end users. The structural shift toward agents suggests "end user" may need a new definition.

What It Actually Costs

The subscription economics of running a setup like this deserve mention, because Chen is refreshingly concrete about them. The current $200/month subscription tiers from major AI providers aren't sufficient for his workflow. He and Ondrej both suggested a $500 tier would make more sense for power users. API pricing at scale would cost, by Chen's rough estimate, an order of magnitude more than flat-rate subscriptions — making the arbitrage in subscriptions substantial, but the quota ceiling a genuine constraint.

He's developed strategies around this: saving his most capable model allocation for genuinely complex design work, routing routine tasks to more economical configurations, and tracking quota consumption as carefully as he tracks anything else in his workflow. The monitoring infrastructure is, notably, also built by agents. There's a self-referential quality to all of it.

One thing Chen is careful about, which distinguishes this from most "AI workflow" content, is the anti-pattern he nearly fell into: spending all your time building tooling instead of building things. He described a period where he noticed he was mostly maintaining the infrastructure, not making progress on the products he'd left a senior big tech role to build. First Mate resolved this partly by taking over tooling maintenance — the mundane bug fixes and improvements get delegated, so his attention naturally surfaces to work that actually requires him.

Whether setups this elaborate make sense for the median developer is a fair question. Studies have found that AI tools don't automatically improve developer velocity — and can actually slow people down when the overhead of managing AI-generated output exceeds the time saved on writing. Chen's system is an attempt to solve exactly that overhead problem at scale. Whether it generalizes, or whether it represents one unusually systematic person's solution to his own unusually complex situation, is something the tooling will have to prove out over time.

Bob Reynolds is Senior Technology Correspondent at BuzzRAG.