"I want the Codex app, but for multiple agents."
Same.
Stopped waiting and built the screen I wanted.
Claude Code, Codex, and Command Code, side by side.
The real CLIs underneath.
Projects and conversations in one place.
Same sessions on my phone.
No model in the middle. The agents are the CLIs you already run.
25 seconds. Tool in the reply.
I stopped giving my AI coding agents task lists. I give the PM a goal and a deadline.
My whole request is four lines:
Goal: what I want done
Until: 09:30
Allowed: merge what passes tests and CI
Still ask: new issues, design changes, releases
Why a team at all:
I ran several coding agents in parallel, and I became the bottleneck. Every agent asked me something. I read every agent's output.
So I built a team of coding agents: a PM, a dev lead, and workers. Now I talk to the PM alone.
One contact meant one place to grant permission. So I widened what the PM decides.
"Do whatever you want" is a permission I'd never give.
"Until 9:30" is one I can, even with merge rights.
My day job leaves little time for side projects, so most of the work now runs this way, mostly on the agents' own recommended plan. So far, no real problems.
It also stops at the edge. One night it merged 4 PRs, then left 2 new issues waiting for my OK instead of filing them.
I run the team on CommandMate. Each agent works in its own git worktree, and I reach the PM from my phone. The deadline is just a line in my request.
Open source, runs on your machine.
npx commandmate@latest
https://t.co/n9JEKM9gGp
Lately, AI coding feels like it’s gradually shifting from “using agents” to building an AI team.
I’ve also been experimenting with ways to reduce human cognitive load — for example, consolidating project status into a single HTML one-pager.
The human interface should probably be a PM agent.
Under that layer, different agents and models can take on different roles:
- PM → intelligence + strong communication with humans
- Workers → balance of cost × speed × implementation capability
- Research / Enabling → strong reasoning and investigation
- Reporting → fast synthesis of large amounts of information
Humans shouldn’t need to talk directly to every agent.
What we really need to know is:
What are we trying to achieve?
How far have we gotten?
What decisions need human judgment?
Once this kind of setup becomes normal, I think the next challenge will be:
automating the operation of the AI team itself.
Choose models based on task difficulty.
Scale worker count based on budget.
Switch agents when one fails.
Bring in research agents when needed.
Run verification gates.
Escalate only the exceptions that require human judgment.
Today, humans are still orchestrating the agents.
But eventually, humans may only need to define:
Goal / Priority / Budget / Constraints
while the AI system handles team composition and day-to-day operations.
With CommandMate, I want to build the management layer for assembling, running, and eventually automating these AI coding teams.
And going forward, I want to explore the team topology of AI coding agent organizations themselves.
Which roles should be permanent?
Which should be created on demand?
How much should the PM own before the role needs to split?
Which models fit which roles?
The next step after AI Agent Orchestration may be AI Organization Operations.
That’s the direction I’ve been thinking about lately.
How the team runs, in four commands. The PM and the lead call these too.
commandmate verify init
Drafts the checks from your CI.
commandmate send --contract
Hands a worker the task, the files it may touch, and the checks.
commandmate wait --verify
Waits for "done", then verifies it in that worker's worktree.
commandmate remote
Opens it to your phone, so you can talk to the PM from anywhere.
I built an AI team. I stopped being the bottleneck. Verification became the next one.
I talk to one agent: the PM.
Behind it, a lead splits the work and six workers write in parallel.
I still read one report.
The new bottleneck is everything after "done": tests, CI, merge, UAT.
Seven test runs queued up. About 50 minutes to clear them.
But I can't drop verification.
Without it, checking whether "done" is really done comes back to me.
The rule I'm learning:
Size the team by what verification can absorb, not by what agents can write.
The PM reduces what I need to read.
Verification reduces what I need to trust.
I run this on CommandMate. Open source, runs on my own machine.
npx commandmate@latest
https://t.co/n9JEKM9gGp
The whole team runs on the CommandMate CLI, including the PM and the lead.
commandmate verify init
Draft verification gates from your CI.
commandmate send --contract
Give a worker the task, scope, and checks.
commandmate wait --verify
Don't trust "done." Verify it.
commandmate remote
Talk to the PM from your phone.
npx commandmate@latest
https://t.co/n9JEKM9gGp
I run this with CommandMate.
- I talk to the PM from my phone.
- Workers run in isolated git worktrees.
- When a worker says "done," declared tests decide whether it's actually done.
- Verification returns pass, fail, or no change.
- Heavy checks run one at a time, so an overloaded machine doesn't reject good work.
The PM reduces what I need to read.
Verification reduces what I need to trust.
The tool is CommandMate, an OSS I build. It runs on your own machine.
It runs the checks you declare and returns one exit code per run, so "passed" is something you can act on without reading the prose.
npx commandmate@latest
https://t.co/3L7sFAWeXO
More agents did not make me faster. Generation parallelizes; review does not.
Now I open only the runs that come back red. The gain is not the minutes saved per report. It is that my reading stopped growing with the number of agents. It grows with the failure rate, and that is a number I can work on.
Before that, every agent I added put one more unread report in front of me rather than one more thing shipped. Mine stopped scaling somewhere past four.
The catch is that a pass is worth exactly as much as the list you wrote. Mine was worth almost nothing at first: the list was short, runs came back green, I merged on the green, and what got through were exactly the defects nothing on the list was looking for.
So the reading moved rather than disappeared. I write the list once; after that, the only thing asking for me is the exception.
Tool in the reply.
The tool is CommandMate, an OSS I build. It runs on your own machine.
The page opens rendered rather than as source, with scripts off; its links start working once you allow them.
https://t.co/3L7sFAWeXO
The agents got fast enough that the slow part is me.
Not writing the code. Reading what came back and deciding. A summary only asks me to believe a paragraph.
So I'm trying the Amazon one-pager shape: a run ends by producing a document you read once and decide on.
What was done, what it means, what is already settled, and what is left for a person. The proof is linked from where it is claimed. Not having to assemble the reading order myself is the part that actually helps.
Still early. The document is not the proof. It points at the exit code and the diff that decided. A page that only asserts success is worse than no page.
#claudecode
The tool is CommandMate, an OSS I build. It runs on your own machine.
The phone reaches it inside your own tailnet by default; a public tunnel only if you ask for one.
https://t.co/3L7sFAWeXO
I stopped writing code at night.
Not discipline. Tired code doesn't survive the morning, and I can't tell what I meant by it.
What does survive is deciding. So the day is a handoff — one instruction before I leave — and the evening is reading what came back and saying yes or not yet.
The only thing that has to reach me in between is the question the work is stuck on. One tap, from wherever I am.
The rest waits on the branch: the list, the half-written line in the box, the conversation still open where I left it.
37 seconds. Tool in the reply.
#claudecode
If you want to make use of small pockets of time for development, I’ve found that the key isn’t:
“How much code can I write in 10 minutes?”
It’s:
“Can I get back into the work in under a minute?”
A surprising amount of short sessions gets wasted on questions like:
“What was I doing last time?”
“What did I ask this agent to do?”
“Which files are being changed?”
So I’ve been optimizing around three things:
1. Recover context in seconds
→ history, notes, progress
2. Make the next decision from your phone
→ launch agents, send follow-ups, orchestrate work
3. Inspect results without a laptop
→ browse files, code, Markdown, and HTML remotely
Once those are in place, the workflow changes:
10 minutes at lunch → dispatch the next issues
Back to the day job → agents keep working
Commute → check the results
Evening → resume by testing something that already moved forward
This is also how I’ve been shaping CommandMate.
The best way to use small pockets of time isn’t to code faster.
It’s to make sure even a few minutes are enough to move your AI team forward.
npx commandmate@latest
https://t.co/n9JEKM9gGp
Building a side project while working a full-time job usually means working with whatever time you can find:
a lunch break,
30 minutes between meetings,
late at night,
or a few hours on the weekend.
With AI coding agents, I think that constraint can become much less limiting.
Use a small window of time to decide what matters next.
Turn it into clear issues.
Let coding agents work in parallel while you go back to your day job or life.
Then, the next time you have a free moment, you don’t start from zero.
You come back to work that has already moved forward.
For me, this is one of the most interesting parts of vibe coding:
not just building faster, but making serious indie hacking possible even when you only have nights, weekends, and small pockets of time.
That’s also one of the things I want CommandMate to enable:
turn limited personal time into continuous progress on a side project.
npx commandmate@latest
https://t.co/n9JEKM9gGp
Late-night thought.
In my case, I have a full-time job and I’m raising a child, so the time I can spend on personal projects is pretty limited.
But this isn’t really about parenting.
Work, family, hobbies, studying, caregiving — everyone has different reasons why their time is constrained.
So lately, I’ve been thinking less about:
“How do I find more time to build?”
and more about:
“How do I keep a product moving forward even when my time is limited?”
Capture an idea from my phone when it comes to me.
Let a PM agent turn it into issues and coordinate workers.
Then go back to work or life.
The next time I have a bit of time, I don’t want to restart from zero.
I want to come back to something that has already moved forward.
Having large blocks of free time shouldn’t be a requirement for turning ideas into real products.
Even with limited time, people should be able to build at their own pace and keep improving what they create.
That’s one of the things I want CommandMate to make possible.
npx commandmate@latest
https://t.co/n9JEKM9gGp
#commandmate