I’ve gone through multiple iterations of how I develop software. It’s evolved, more or less, with a similar curve to LLM capabilities.
The early versions trusted the models too much. Then I didn’t trust them enough. Now I’m somewhere in between.
Along the way, I’ve focused in on a few core thoughts that I hold on to pretty strongly.
Context matters. Getting the “why” along with the code helps LLMs make more accurate judgments. Without it, they’re guessing. With it, they’re usually right.
Large codebases need fast search. Watching an LLM burn tokens for five minutes grepping and sedding through code at the start of every session is infuriating. I’ve tried RAG. I’ve tried SQLite. I’ve tried a few different text formats. I’m currently using an OKF wiki for large codebases. It works.
Linear orchestration sucks. Getting a single harness to plan and execute tasks in parallel is a crapshoot on the best days. Real software work isn’t a queue. It’s a graph.
I’ve been doing a lot of work lately on Project Scion from Google Cloud. It’s good. It’s also complex for my needs.
Scion is built for an enterprise context. It might be the right tool for that context. Those sort of use cases are just now starting to emerge in the world. But I’m not running an enterprise. I’m running two 32GB hosts and a handful of projects.
So I started developing something smaller. Still multi-host. Still multi-harness. Just… smaller.
It’s now called Leaf.
What it does
Leaf runs across two 32GB hosts. It can run across more. I just have these for now because I had them available. Each host runs its own agents. The system coordinates between them: planning, execution, integration. It doesn’t assume an enterprise org structure.
The core idea is decomposition before agent involvement. You plan once with expensive reasoning. Then you parallelize the cheap work across many agents. Each plan node carries four things: what it’s supposed to accomplish, what files it touches, how you know it’s done, and which issue it serves.
Not every agent is the same. The system uses whatever harness and model makes sense for each node. Cheap local models for documentation. Frontier models for the hard coding work. I wrote about this hybrid approach a couple months ago.
Agents talk to each other through rooms. One room per plan being worked. A pod asks for work; it’s never handed work. The foreman assigns nodes, watches for stalls, handles integration when pods finish.
GitHub is the completion signal, not an agent’s word. The foreman reports done only after a PR is confirmed merged.
What it’s like to run
A host dials in. It advertises its capacity and preflight status. When a plan runs, pods get spawned, work gets distributed, and the foreman watches for anything that goes quiet. If a foreman dies, the system spawns a replacement with a resume digest instead of replaying everything.
When a plan finishes, worktrees get cleaned up, branches get pruned, and the room log gets archived into structured tables with plan summaries, per-node costs, model choices, and outcomes. You can look back and see what actually happened.
The dashboard shows rooms, plans, host fleet status, and a paginated room log. No authentication. LAN-only.
How it works (briefly)
The UI is a web app with a few API endpoints to manage plans, update UI and database values. Nothing fancy. Plans are created using a skill in an interactive session in your favorite harness. It adds the plan to the Leaf UI. Once approved and started, the UI spawns a foreman agent. Foremen are Opus agents running in Claude Code in a podman quadlet. It gets the plan and information needed to communicate with the API. It joins a websocket that’s created for all agents in the plan to join. The first wave of Worker agents are spawned. They announce that they’re up and read in the websocket chat. The foreman confirms and sets them on their tasks.
Each agent sends their output into the websocket chat. Things like thinking tokens are filtered out. This gives me a free timeseries of what happens to get work done. It also gives the foreman an easy check to make sure Workers aren’t hung or wedged. If they don’t say anything for a minute they get a nudge form the foreman using the websocket. Chats get a format that all agents know how to interpret.
Agents can communicate with their neighbors and the foreman. When they’re done, they commit their code. The foreman closes them down and spawns the next agent in the plan.
So far it’s working well. The biggest issue I’ve run in to so far is that an outage tends to make eveything ugly really fast. That took some human intervention. But it’ll get there.
Everything happens in containers. Additional hosts have a small daemon that runs and acts as a proxy to the server running the UI. It could be built in to something else down the road (like a kubernetes CRD), but I wanted simple to start, and this is simple.
Where it is
It’s not finished. I’m not calling it a product. But it’s at a point where I can see the shape of what I’ve been looking for across three iterations, and it feels right.
Once it reaches a level of completeness I’m happy with, I plan to open source it.
Until then, it runs on two hosts and does what I need it to do.