What Building 70 Services Taught Me About Leverage
codmir is a monorepo of more than seventy services. Here's what running that alone has actually taught me — mostly that scale is a people problem wearing an architecture costume.
codmir is, at time of writing, north of seventy services in a single monorepo. Agent orchestration, cloud workstations, a full IDE, real-time collaboration, voice, scheduling, billing, a desktop app, browser extensions. When I say that out loud to other engineers the reaction is usually some version of why?
Fair question. The honest answer is that it wasn't a plan. It was a consequence.
The thing nobody tells you about agent platforms
If you're building a product where AI agents do real work, you discover quickly that "the agent" is maybe five percent of the system. The agent needs somewhere to run that survives a disconnect. It needs a filesystem. It needs credentials that are scoped correctly. It needs to be observable while it works, interruptible while it's wrong, and resumable after it's interrupted.
Each of those is a service. None of them are optional. The surface area isn't ambition — it's just what the problem actually requires once you stop hand-waving at it.
The architecture that emerged:
- Persistent cloud execution. Agents run server-side and survive the client going away. Close the laptop; the work continues. This is the single most important design decision in the platform and it forces almost everything else.
- Worktree-based environments. Multiple branches worked simultaneously, in isolation, without agents standing on each other.
- Streaming everything. Long-running jobs report progress over server events. If you cannot watch an agent work, you cannot trust it, and if you cannot trust it you will not delegate to it.
- End-to-end types. One TypeScript type definition shared across API, UI and data models. With this many moving parts, the type system is the only thing keeping the seams honest.
Leverage is not the same as speed
The lesson I keep relearning: adding capacity does not remove a bottleneck, it relocates it.
Early on I assumed more agents meant more throughput. It doesn't, not directly. Ten agents producing work faster than one person can review produces a review bottleneck, which is worse than the original problem because now you have ten confidently-wrong changes to untangle instead of one.
What actually creates leverage is narrowing what has to pass through you:
- Make verification cheap. Every agent output needs an automated verdict before it needs a human one. This is the QA instinct showing up again, and it's the single highest-leverage investment in the entire platform.
- Make state legible. If you have to reconstruct what an agent was doing, you've already lost the time you saved.
- Make failure local. One agent failing should cost one agent's work, not the run.
None of that is about AI. It's the same lesson as any distributed system: the coordination is the hard part, the workers are commodity.
The uncomfortable part
Building this alone means I am, structurally, the thing I'm trying to eliminate. Every architectural decision routes through one head. I've had to get deliberate about writing decisions down — not for a team that doesn't exist yet, but for me in three months, and increasingly for the agents that read the repo as context.
That turns out to be the strange, genuinely new part of this work. The documentation isn't only for humans now. Code comments, architecture notes, the structure of the repo itself — they're inputs to the system that writes the next version of it.
Which is the whole thesis, really. Not automation that replaces the engineer. A system where what the engineer knows becomes something the system can act on.