Good Enough Is the Hardest Thing to Replace

Recently, I applied for an AI Enablement role. It’s a type of role I’ve started to see more often, where companies are looking for people who understand AI beyond just using ChatGPT or calling an API. There’s the engineering side of using agents and building better workflows around them, but also the product side of implementing AI natively inside web applications.

As part of the application process, I was asked to record a short video walking through some of the tools I’ve built and use across both. One of those tools is something I’ve been using for agentic engineering for about ten months, and it started off very small. At the time, I was really just trying to solve a few practical problems around how I worked with coding agents. Over time I added more to it, changed parts of the workflow and built more structure around it. Eventually, what started as a small process grew into something much bigger and now does a lot more than it was designed to.

It worked well enough

The interesting part is that it worked the whole time. There were things about it that bothered me, but never enough to stop what I was doing and rewrite it. Some parts were awkward, and there was friction I’d learned to live with, but I understood how the system worked and why it had ended up that way. It still passed the whiteboard defense: I could explain how it worked, why the decisions had been made and where the weak points were. None of those issues felt significant enough on their own to justify rebuilding it.

That reminded me of something called the region-beta paradox. The example usually given is that if somewhere is less than a mile away, you walk, but if it’s further away, you drive. That can create a situation where you get somewhere two miles away faster than somewhere one mile away, because the worse situation crosses the threshold where you do something different about it.

I think developer tooling can end up in the same place. If a tool is genuinely bad, you’ll probably replace it. If it wastes enough time or gets in your way often enough, eventually fixing it becomes worthwhile. The harder case is when it works well enough, because the individual annoyances never quite become serious enough to force a change. That’s where this tooling had ended up.

I’ve always thought good tools should mostly stay out of the way. That applies to build tools, developer tools and, increasingly, AI tooling as well. If I’m using an agent to work on something, I don’t want to spend half my time managing the tooling around the agent. The orchestration should help the process without becoming the process. The tools I’d built did that reasonably well, which is probably why I’d been happy to live with the friction that was there.

What the demo showed me

Preparing the demo made me look at the tooling differently. It had grown up inside the projects where I used it, and it fit them well. But every time I wanted to use the same process somewhere new, I had to stop and adapt it first. Nothing was broken. It just never picked up and moved as easily as it should have. The workflow was portable. The tooling wasn’t. I could have fixed that incrementally, and over that time there have already been plenty of incremental improvements. I think I’m on roughly the twelfth iteration of it at this point.

That’s when it clicked that if the process was useful enough to keep coming back to, it should be a tool I could use anywhere, not something tied to one project. There are good options out there, like Conductor and LangGraph, and I looked at them. But what I liked about my own setup was its shape. It was built around a queue of tasks that needed doing, worked through one by one, and that model had held up the whole time. I didn’t want to trade it for someone else’s idea of how agents should be orchestrated. I wanted to keep it and make it better.

Would I build it the same way?

Applying for AI Enablement roles also meant I was seeing more questions around orchestration, agentic workflows and the tooling people are using to build them today. That made me realise that the foundation of my own orchestration tooling had been put together around ten months ago, which is a long time in this space. There are now agent SDKs, better primitives and different approaches to orchestration that either didn’t exist then or weren’t mature enough for me to build around.

The question stopped being how I could remove a few bits of friction from the existing tooling. It became whether, knowing what the system now needs to do and what is available today, I would build it the same way. The answer was no. After roughly a dozen iterations, I had a much better understanding of the workflow, but I also had a much better set of tools available to implement it.

Rebuilding with what I know now

Before the next round of interviews, I decided to take the concepts from the existing tools and rebuild them as a dedicated CLI written in TypeScript. I’m not starting from scratch in the sense of starting with no knowledge. It’s almost the opposite. The existing tooling has given me months of real usage to work from. I know which parts of the process I use constantly, which abstractions have held up, where the friction is, and what I’d now do differently if I were designing the system today.

I generally think rewrites should be treated with some suspicion. Existing software contains a lot of decisions that are easy to underestimate until you try to replace it. But there’s also a point where an early version of a tool has done its job. Sometimes the first version is how you learn what the thing actually needs to become.

I couldn’t have designed the CLI I’m building now ten months ago because I hadn’t used this workflow enough to understand it properly, and some of the tools I can build around today either weren’t available or weren’t where they are now. The older tooling is what gave me that understanding, and the incremental improvements over that time are what showed me which parts were worth carrying forward.

Fresh eyes

What I hadn’t expected was that an interview exercise would be what made all of this obvious. I thought I was going to record a video showing how the tooling worked. Instead, it gave me a reason to look at the whole thing again with fresh eyes and ask whether I would still build it the same way today.

I wouldn’t.

So I’m rebuilding it.