Features, Not Demos

Yesterday I had to build an entire billing module for an ongoing software-as-a-service product. It came with a few gates and drawbacks, meaning the code is not fully optimized, because I had to get the whole feature alive within a couple of hours. This is not really about the hours though. It is about what I felt while I was building it.

During the development process, I saw that Claude Code on Opus is genuinely good for this kind of work. And it did not take anywhere near the token usage I expected. I even reached for Fable, the most efficient model I have, and it held up too. What surprised me most was PHP. For this kind of ongoing product work it is pretty good, so I am going to run more experiments on it from here.

I also want to push more experiments and innovation around the Fable model. I think we can get the same look and feel, that same deeper thinking Fable does, by leaning on more orchestration and giving each agent its own sub-context window. That is the direction I am chasing next.

The reason is simple. We are still fighting the fundamental issue of agents, which is memory and context persistence. Every agent starts fresh, and holding the whole thing in view across a real task is still the hard part. So I am going to keep working on this going forward.

But here is the part that stuck with me. With this one piece of work, I felt we can ship an entire product, an entire feature, especially for ongoing projects. Not just beautiful demos. That is a real shift, and it is the thing I did not fully believe until I watched it happen.

The beautiful part is the artifact. I can generate an HTML artifact and share that one file with my team. Usually I build it in HTML, drop it in the group, and everyone can see how many PRs are already open and exactly what they have to review. No confusion, and no conflict after that. That one file keeps the whole team in sync.