9/ AI allows me to add features that I would have never considered because they were just too much work for too little gain. I can hear my old colleague saying "Stop goldplating it!" But now that cost is no longer an issue, I can spend 2h on building my idea and if it is not useful we just throw it away.

8/ After about 20 releases I performed some code hygiene, looked at the package structure, told AI to move things around, apply consistent naming, use latest Go features and SDK functions, and added some structure. Other than that I have left it alone.

7/ I did not point AI at an existing tool and say "Rewrite in Go". Instead, I am using AI to understand the existing codebase, think about which features to build next, understand the use cases and make the tool incrementally better. Significantly better with every release. This is not vibe coding or one-shotting a tool but deliberate and focused improvement delivered quickly.

6/ Being able to release 1-4 times per day with fix after fix after fix is what allowed me to build the trust that whatever the engineers find will get fixed immediately.

5/ But mostly they use it because it is fast and reliable. The speed would not matter if it would not work.
This is where AI comes in. First, by analyzing how the original tools work and what hard-coded workarounds they perform. And then by building a tool that does it better and faster.

4/ In the last 30 days, I have released 43 versions of my tool during a 5 day workweek. No night and evening sessions. It has about 15,000 lines of Go code most of which I did not read. It has built-in service registries, parallel processing, logging, web ui, fuzzy finders, and a lot more - and it is fast! Very fast. About 5-10x faster. Tasks that took several hours are now done in minutes. Developers love it.

3/ Building tools is easy. We do it every day. Your shell script is a tool, and so is your colleague's python script. Building good tools is hard, especially since you need user interfaces, input verification, log files, and reliability. Also, tools need to be flexible and you do not want to be the only person maintaining them.

2/ Infrastructure has the habit of being complex. Nothing is ever clean and by the book. There are always exceptions. Someone solved a problem two years ago, found a clever solution, forgot about an edge case, and then another feature solves it in a slightly different way. It is complex.