The hard part of AI development is not the agent
About ten months ago, we were using coding agents the same way most teams do. Open a chat, describe what needs to happen, let it work, review the output.
It worked, which was the surprising part. Tasks that used to take a developer a few hours were getting done in minutes, so we started doing more of it, and that is when the problems started.
Getting an agent to write code was never the hard part. The hard part was everything around the work: what should happen next, what had to wait, what could be done separately, what each task was allowed to touch, and what counted as finished.
Without a system behind it, all of that sits in someone’s head: multiple sessions, multiple tasks, different repositories, checks, context, dependencies. The limit becomes your attention.
When we started running more agents, the problems became obvious: work that could have happened separately was waiting for no real reason, work that should have been isolated was not, and one agent could touch the wrong place or change something another agent was also changing. The failure was sometimes obvious right away, and sometimes it only showed up later, when we tried to integrate the work.
And everything was local, so if you closed the laptop or lost the internet connection, the work stopped.
The individual agent sessions were fine, and the coordination around them was the problem.
So we started building what we internally call rcli.
rcli sits above the agents, as the layer that plans work before implementation starts, splits it into epics and tasks, assigns each task to the right repository, defines what the task is supposed to change, and decides what needs to pass before the work moves forward.
The agents still do the implementation. They read the task, write the code, run the checks, and try to fix what breaks.
But the system decides when a task can start, where it runs, what it can touch, and whether the result matches what the task asked for. A human still decides what gets accepted back into the product.
AI development for us is no longer a set of open chats, but a queue of tasks, separate workspaces on a server, checks that have to pass, and a clear point where someone reviews the result.
The actual board, mid-run
Claude Code is moving in a similar direction, where a coordinator shapes the work and smaller subagents handle bounded tasks.
One practical thing worth saying is that most of our implementation work now goes through Cursor Composer 2.5. Planning, task decomposition, and decisions that need deeper reasoning go through Claude.
There is always another model announcement. We pay attention, but we do not rebuild the workflow around each one. Once the task is shaped clearly enough, model choice becomes a routing decision.
That is what AI development looks like for us now. We depend less on any single model doing something impressive, and more on the system that decides what it is allowed to do.