Shifting into third

For the last few months all of our work has gone through one internal tool. We call it rcli.

The rcli board

Before it, the setup was coding agents running in terminal windows, several at a time. We built prototypes with those agents too, drew diagrams, and kept a knowledge base where we wrote down decisions and things we learned. Then, when it was time to plan, we linked all of it together. That worked until we started running more things in parallel.

rcli started as a CLI to run more tasks in parallel without losing context, with one place to plan and to see what was happening. It now holds documents, prototypes, skills, planning sessions, loops we can start, and a view of task execution with all the agent logs and everything they produced along the way. It alerts us when a PR is ready for someone to review, approve, or send back with feedback, and that is the only point where it asks for a human. It moved from a TUI to a web UI along the way.

Work does not start by filling in a form to create an issue. It starts in a planning session, a conversation with a planning agent that ends in an epic broken down into tasks, with the docs and prototypes from that session attached to it.

A planning session

It also resolves dependencies between tasks. Every task carries the ones it is tied to, so the system knows what can run in parallel and what has to wait for something else to land first.

Dependencies on a single task

Every epic runs through the same path. A branch is created for it, and each task underneath opens a PR against that branch. When the agent doing the work is finished, a separate agent reviews that PR, and whatever the review finds is handed to another agent to fix. The PR still goes through the normal CI, tests and the rest of it, and once everything is green it merges into the branch automatically.

That is where autonomous execution stops. What has collected on that branch becomes one PR, and a person reads it before it goes anywhere. We use an agent to help inspect it, and we go through the change ourselves: where the code landed, how the responsibilities are split, and whether the implementation is moving the system in the wrong direction.

Guillermo Rauch made a good point on X about why that step is still there:

If you’re not reading the code, whether explicitly or through agentic inquiry, one or more of these is true: you’re a beginner, software is throwaway, you’re prototyping, you have no users / revenue, you’re taking on debt & risk, your problems are basic.

And btw. All of this is fine. But the reality is that models are still not at the “full autonomy” stage yet. They make rookie mistakes, they go down bad architectural paths.

The planning happens in a session and the system keeps what came out of it. The breakdown, the dependencies and the order things run in belong to the system rather than to whoever is holding it in their head. Agents run in parallel against that, review each other, and fix what the review finds. A person still owns the final review and the approval.

I think this is also where the market is moving. Faster implementation has already changed what founders expect from software teams. The next pressure is to move whole workstreams faster without losing control of the product or the system.

This is us in third gear.