Frank Schröder 🌻Mar 19

1/ Building Tools in the Age of AI

Over the last month I have been working on a deployment tool. Something that copies files from here to there, creates files and symlinks, and restarts services. It is a replacement for a collection of tools which are slow and show their age. However, they work and our developers have come to trust them. It is their tool to release their work to the public.

https://magiconair.net/blog/2026-03-19-building-tools-in-the-age-of-ai

#ai #softwaredevelopment

Building Tools in the Age of AI | Frank Schröder

Building Tools in the Age of AI - On building a deployment tool with AI, delivering fast, and earning trust through reliability

Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻
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.
Mar 19 at 6:48pmWeb
Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻Mar 19
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.
Show threadFrank Schröder 🌻Mar 19

10/ The best thing happened a couple of days ago when some of my colleagues started to make changes themselves. The tool has become an inspiration and they add new features to make their lives even better.

That is the most I can hope for: Having built something useful and being no longer the only one responsible for it.

Thank you Claude!