Why we build our own tools

Today most of our software engineering has AI agents helping to write the code, and we usually run several at once. One writes a database migration, another writes the tests that check that migration, another reads a vendor’s documentation, and a dev server stays open beside them.

At first we ran all of this in a pile of terminal tabs. The work got done, but once several tasks were open at the same time, we started losing track of who was doing what. It was like a restaurant kitchen with nowhere to line up the order tickets. Everyone is working, food keeps going out, but it is hard to say which table is still waiting.

So we built Helm, a desktop app that brings all of this into one window. Each agent lives in its own pane, a working slot of its own, and the panes are laid out so we can see them all at once. It is now the tool we write code in every day.

We don’t sell Helm. This note is about why we were willing to spend the time building it, and what a tool that fits the way we work helps with, from agreeing the scope of a project to delivering it to a client.

The problems around the agents

Agents like Claude Code, Codex and others help a lot. Explain the task and give them enough context, and work like writing a migration comes out well. But once we ran several at the same time, we found that many of the problems happened in between.

I had to open each window in turn to find out what the four agents were doing: some were working, some were waiting for me to answer. Passing work along meant copy and paste. At the end of the day I had only a rough idea of what we had spent, and I still had to look back to see which work had been checked and which only had a message saying it was done.

For work that goes to a client, we need to know more than that.

Off-the-shelf tools helped with parts of this, but the ones we tried still didn’t fit the way we work. With the same problems coming up almost every day, we decided that building our own tool was worth the time it takes to develop and maintain.

A schematic of one Helm workspace. Each pane has a short name you can call it by and its own cost figure, and a green status is designed to be tied to a receipt for work that has been checked.

One glance, whole crew

Helm puts all the panes on one rack. We designed each pane to have its own separate working context, and made passing work between panes a step you can see and follow.

Some small details mattered more than we expected. Early on, a new pane took its engine label as its name, so the header read something like “Claude Code, Opus, high”. You could tell which model it used, but it was awkward to call on, especially with several of the same kind open.

Try directing work with “the second Claude, no, the other one”.

So we gave every pane a call-sign when it is created: a short word you can say out loud and type after an @ to call it. Atlas looks after the migration, for example, and Vega writes the tests. When work gets handed on, we can name the pane directly instead of describing where it sits on the screen.

The notification bell follows the same idea. We wanted the number on its badge to answer one question: how many agents are waiting for a person to reply. So it is calculated from the panes’ status when it is read, instead of keeping a separate counter that has to be incremented and decremented on its own.

That lowers the chance of the counter and the work status disagreeing, though it still depends on each pane’s status being correct. What we want to be clear is this: if the badge shows two, you should be able to find the two agents that are waiting.

Hand-offs you can trace

Agents passing work to each other is another point that needs care. A message can land in the wrong pane, or a conversation can run on until it is unclear who started it and what question it is answering.

So we set the messaging rules in Helm around one principle: it must be possible to trace back to the instruction of the person who started the work.

A pane working on a person’s instruction can call any other pane in the crew by call-sign.
A pane answering work from a peer can only send its answer back to the pane that called it.
No pane talks to itself, and fanning work out to the whole crew is the job of a person or the orchestrator.

Our orchestrator is called Vesper. There is one per workspace, and it helps organise and route work within that space.

We keep typed and spoken instructions clearly separate. When I type a request, Vesper shows me a plan first and waits for my okay before it types anything into a pane. A spoken request goes into the pane straight away.

That gives the two a different moment for review. People need to know in advance which one waits for approval and which one starts right away. We treat this as part of the tool’s behaviour that has to be defined clearly from the start.

Seeing cost while the work runs

Each pane shows a cost figure on the main screen, so we can watch what work costs while it runs, without opening a settings page or waiting for the monthly total.

The figures available during a run let us see trends and compare different kinds of work. The amount actually billed still has to be checked against the provider’s own data.

Seeing the number next to the work makes us look again at how we brief it. If a research agent has spent more than the agent writing the feature, for example, we ask whether the brief was too broad, whether it really needed to read that much documentation, or whether we could have pointed it at the sources we needed more precisely.

A high cost doesn’t always mean poor work; some tasks genuinely need a lot of research. But it is a cue to look at what the resources went into and whether they produced the result we wanted. As experience builds up across different kinds of work, we have more data to draw on when estimating the next job.

Receipts: green has to be explainable

If I had to pick the part of Helm that matters most to me, I would pick receipts.

A receipt is a structured record of what a piece of work has done: what ran, what cost data there is, what was checked, and which evidence each conclusion came from. We read it alongside an agent’s summary to see what actually backs a message that says the work succeeded.

The principle we set for a green status is that it has to be tied to a specific check result: which test suite passed on which version of the code, what a security scanner checked and found no problems with, or under which conditions a repeated build produced the same result.

Each result confirms only what it checked. Passing tests don’t cover every behaviour of the system, and a security check that finds nothing is still limited by the tools and methods used. So we read the details in the receipt as well, rather than stopping at the colour of the status.

Where there is no evidence yet, we should be able to see that the work still needs checking, however confident the agent’s summary sounds.

This matters more when several agents run at once, because we get a lot of code and a lot of summaries. It is easy to read only the summary and assume the work is ready to use when some steps may never have actually run. Receipts let us look back at what has been done, what hasn’t, and what still needs checking.

When we deliver a project, these records are part of what we give the client, so they can check what we did and what came of it themselves.

What changed in our projects

Before Helm, adding a second or third agent meant more windows and more messages for me to follow. Some of the time saved on writing code went straight back into checking status and handing work along.

With the work in one place, we can organise parallel work more tidily and see who owns each track and what each one is waiting on from the others. The way of working we set is that each track gets its own copy of the repository, and work is reviewed before it is merged, deliberately looking for mistakes and for effects on other parts.

The tool makes those steps easier to follow, but we still have to check what each piece of work has been through and what is still outstanding before merging code or delivering.

So what we hand a client is more than the code files. We can attach the trail of the work: what request it started from, which person or agent did it, what cost data there is, and how we verified that it works. That helps both when the client accepts the work and when someone has to come back and change it later.

Why build instead of buy

People ask whether building our own tools costs us focus. Sometimes it does. It takes time to develop, fix bugs and keep maintaining, like any other piece of software.

So our test is fairly simple. If a tool is involved in almost every piece of work we deliver, and the options available still don’t fit the way we work well enough, we consider whether building it ourselves is worth it. For us, Helm passed that test, as did the voice and screenshot tools we use alongside it.

Another thing we get from using what we built every day is that we keep running into its rough spots: a pane that is awkward to call, a status that is hard to read, a hand-off we can’t trace. We hit those problems ourselves and have to come back and fix them.

Living with those details makes us pay more attention to the small things in software, and the same attention carries over into the work we do for clients. That is one more reason we still choose to build and use our own tools.