The first step in our process, in the era of AI

alex@ragebite.com — Fri, 24 Jul 2026 00:00:00 GMT

We do not start by building.

That is easy to forget right now, when everyone assumes speed is the whole point of AI. The instinct is to build a prototype the same day someone describes an idea, because building has gotten fast enough that skipping the thinking feels like the responsible move. Before we make any move, we spend a few meetings just trying to zoom out and understand the whole picture behind the idea, not just the feature someone is asking for, but the business behind it.

The idea that shows up in the first meeting is rarely the real one. It is just how the partner understands it at that point. The real one tends to surface later, in the second or third conversation, usually as a correction to something we assumed too early.

This did not come from a book. In 2020 we worked on an esports platform for Logitech. We did not own the product, and we relied on our previous knowledge instead. In some way, all the decisions their team made seemed fine to us. We did not zoom out enough to see that player needs, the end users of the platform, mattered more than staff needs. After that, we changed how we work on projects. We look at the whole system before we build anything, and the first goal is to understand who the end user actually is.

Once we have that, we map out the whole system before we touch anything: what it depends on, and where it would quietly assume something that is not true.

A real systems map from an early scoping session

Then we spend about a week building a first version of the prototype. This is the same process we used before AI existed. AI just lets us move through it faster without changing what we are actually doing.

Based on that first version, we take it back to the partner early, before it is finished. What comes back is rarely about the interface. It is usually about a part of the plan that only became visible once there was something to react to. Over the next week or two we just refine it, sometimes a small adjustment, sometimes something closer to the center of it.

By about two weeks in, we have what I would call a ready to go prototype, not an MVP and not a finished product. Once we are on the same page and have a clear idea, that is when we define scope, not before. By that point we know what the real architecture needs to be and what infrastructure it depends on, because we are not guessing anymore.

If we had defined scope first, we would be building it around assumptions instead of around something that already exists and already sat in front of the partner and got a real reaction. The prototype is what makes the next decision possible to make honestly instead of hopefully, not the deliverable itself.

I still do not know how much of this is discipline, and how much is just fear of building the wrong thing quickly. From outside, both would look the same.

The hard part of AI development is not the agent

alex@ragebite.com — Fri, 03 Jul 2026 00:00:00 GMT

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.

Angelich

The first step in our process, in the era of AI

The hard part of AI development is not the agent