Developing PruneOps with AI (and the frustration that comes with it)

Since I started the PruneOps project, I’ve written all of its code with AI. Like everyone else, I’ve tried a few different models and clients, we won’t get into that (nor into token usage and their prices), everyone has their own opinion and preference there. But what I have found is that all LLMs do the same thing: they generate. It doesn’t matter if you have generic functions, class abstractions or anything else: they always generate new code from scratch, ignoring all of it.

At first it wasn’t a problem, it would start generating and I’d move on, but as you grow you realize this isn’t sustainable. I’ve spent (and still spend) entire days doing refactors to standardize code, forcing it to create and use generic functions, and not out of habit or to look good, but because otherwise it becomes impossible to change things afterwards: you have a thousand different places to review and one always slips through.

An example: at one point I had dozens of templates for the platform’s audit pages, each with its own independent table. After a lot of effort, all audit pages now share a single template (and the overview ones, another) and all the information arrives and is displayed in the same format.

I’ve also realized that I need to keep tasks small, so I can control changes in detail. Maybe it’s not the best way, I’m sure there are people who know much more about this, but deep down I’m a systems administrator who plays at programming in his free time.

Still, I’m not going back: the balance remains positive. I’m having a lot of fun and I hope to turn it into something worthwhile.

If you want to see what comes out of this intense relationship, on the PruneOps blog I write about FinOps, cloud costs and cloud infrastructure management:

• Blog: pruneops.run/blog