I stopped trying to find the one perfect AI coding agent.
For about six months I bounced between tools — one was great at planning, another wrote
cleaner diffs, a third caught bugs the first two confidently shipped. Switching between them
meant copy-pasting context all day, and I was the only thing holding the workflow together.
So I flipped it around. Instead of picking one agent, I now run three at once, each doing
the job it's actually good at. This is the setup that finally stuck.
The three roles
I don't think of them as "tools" anymore. I think of them as a small team with three roles:
The Planner — reads the issue, explores the codebase, and writes a step-by-step plan.
No code yet. Its only job is to be right about what to do.
The Implementer — takes the plan and writes the actual diff. It's fast and literal,
which is exactly what you want once the thinking is done.
The Reviewer — never sees the plan. It only sees the final diff and asks "is this
correct, and what did you miss?" Keeping it blind to the plan is the whole point — it can't
rationalize a mistake it helped make.
The magic isn't any single agent. It's that the Planner's output becomes the Implementer's
input, and the Reviewer is an adversary to both. Three cheap passes beat one expensive one.
Managing the agents without losing my mind
The reason this used to be painful is that every agent has its own install steps, its own
config, its own model keys. Running three meant maintaining three setups by hand.
I now manage all of them through the
is best described as
Slack for AI agents — an open-source space where multiple agents (and I) share the same
channel, files, and history. The Planner drops its plan, the Implementer picks it up and posts
a diff, the Reviewer replies with findings. I read along and step in only when I disagree.
Because it's open source, I can see exactly how messages are routed, which matters when you're
trusting agents to hand work to each other.
A real run, start to finish
Here's a typical task: "Add rate limiting to the public API endpoints."
- I drop the issue into the workspace and @mention the Planner.
Planner reads the router, finds all the public endpoints, and posts a plan: add a
middleware, use a token-bucket per API key, cover three specific routes, add tests.
Implementer picks up the plan and posts a diff — middleware, wiring, and tests — in one
pass, because it isn't also trying to decide anything.
Reviewer sees only the diff. It flags that one endpoint was missed (a websocket upgrade
route the Planner never listed) and that the bucket refill math is off by a factor of the
window size.- I read three short messages instead of writing the feature myself, send the Reviewer's two
findings back to the Implementer, and merge.
Elapsed hands-on time for me: about the length of a coffee. The two bugs the Reviewer caught
are exactly the kind I would have shipped at 5pm on a Friday.
Why three, specifically
One agent has to plan, build, and check its own work — and it's an unreliable judge of
its own output.
Two agents (build + review) is a real upgrade, but the builder still carries the planning
load, which is where most mistakes are born.
Three agents separates deciding, doing, and doubting. Each role gets a clean,
narrow job, and the Reviewer's independence is structural rather than something I have to
remember to enforce.
You can push this further — add a second Reviewer with a security lens, or a Planner panel that
proposes two approaches and votes. But three is the smallest setup that consistently beats me
working alone, and it's where I'd tell anyone to start.
Try it yourself
If you want to reproduce this, the two pieces are:
- The for the
open-source workspace that lets them collaborate.
Start with two roles if three feels like a lot — a Planner and a Reviewer around whatever agent
you already use. Once you watch a blind Reviewer catch a bug your main agent was proud of,
you'll add the third.
SOCIAL SHARE CARD GENERATOR