AI Makes Better Software

AI can easily make software worse, you won’t get any argument from me there. But it can also make software better.

A lot of the marketing (and, thus, the discourse) around AI is about increased productivity, or velocity, but I believe if that is the only way how you’re measuring its value, you’re missing the point. Yes, AI can help you do things faster, but shipping faster is only one potential outcome of this. How about shipping better?

When I tell people that I’ve been working on Chatto for what is soon going to be a full year, sometimes the response is “okay, so AI doesn’t really make you that productive after all, huh!” But it does! I’m just using that increased productivity differently from what people seem to assume from a typical “AI coding project”.

Chatto hasn’t been in development for this long because building a chat app is inherently hard, but because the increased velocity of development that AI enables has allowed me to iterate on the product and its architecture in ways that would not have been feasible without it, allowing Chatto to not just be a chat app, but a really good one.

Some examples:

• An early version of Chatto went much more deeply into NATS than it does today, with the frontend itself being a NATS client that would directly connect to Chatto’s NATS server. It was an extremely fun architecture, but ultimately I decided that it would be more sustainable to shield the NATS server behind a more traditional API.
• For the longest time Chatto had a GraphQL API, which I felt was the right choice for an app like this, until I started running into issues with the Chatto client wanting to connect to servers running different versions. GraphQL, as much as I love it, simply isn’t the best fit for this sort of scenario, so I threw the entire API away and replaced it with ConnectRPC. (I’ve grown really fond of Protocol Buffers, both for their efficiency, but also their forward/backward compatibility properties, which make them really great for what Chatto is doing.)
• Right up until shortly before the release of Chatto 0.4, the backend was storing most things that weren’t chat messages in JetStream KV and essentially treating it as one big CRUD database. The number of headaches around having to migrate data from one shape to another was constantly increasing, so I eventually realized that Event Sourcing was the better approach, and rewrote the entire backend to make use of that pattern instead.
• Similarly, the upcoming Chatto 0.5 refactors the entire frontend to also fit into the Event Sourcing model, basically acting as a client-side projection instead of randomly requesting data from the backend all the time.

Each one of these was a significant undertaking and, even with the help of AI, took between a week or two to finish.

But what if I had not been using AI? Each of these would have easily taken me multiple months to plan, implement, test, and ship. I would have had a hard time justifying the time and effort to do them; they would have blocked heaps of other work; and they would likely not have been a lot of fun. The most realistic outcome would have been that I had not done them at all, and Chatto would simply not have been as good as it is today.

Ironically, it seems that agentic engineering, when used effectively and responsibly, delivers on the promises of agile development; ship a product, get feedback, iterate. Except those iterations can now involve significant changes to both the product and its architecture that would otherwise be hard, if not outright infeasible, to pull off.

Don’t use AI to ship software faster. Use it to ship better software.

(I’ve previously blogged in a little more detail about my agentic workflows. Also, do give Chatto a try. I hear it’s pretty cool!)

Discuss on Hacker News | Discuss on LinkedIn