Building your AI toolkit

Another way to use AI to make your life easier!

Over the years I’ve often found a need for a software tool to do a thing. Sometimes the tool exists - e.g. unix2dos for converting file endings. Sometimes a tool exists but is extremely complex (e.g. adjusting EXIF information in photos when I forgot to change the time on the camera when travelling). And sometimes the tool doesn’t exist (e.g. converting mp3 → mp4 and adding visualizations for uploading to YouTube).

In the past finding a tool involved an hour or two of Google searching, downloading something and then experimenting. Sometimes it worked. Sometimes it didn’t.

But AI changes all that. Over the past few months I’ve created twenty plus little tools that do exactly what I need. It’s the composition model I talked about in this post: The Future of Software Development. Creating little self-contained blocks of code up to 1kloc that do precisely what I need. It’s magical. Maybe even transformative.

This article is the low-down on how you can do this yourself.

Pre-requisites

• Use Claude. I’m still amazed how many people haven’t used Claude. Many folk I talk to have only used the stumble-across-able models - Copilot in Windows and Gemini in Google. If you’re still in this stumble camp then I strongly recommend you go get a Claude account and try it. There’s a free version to get you started. I biased, but the Pro version seems a bargain to me at ~£20 a month for the utility it offers.

• Don’t get hung up on prompting. There’s no magic. The key is short, sweet and precise. And persistence - if you don’t get the result you want try again. But prompt engineering is vastly over-rated. You don’t need magic incantations to get useful results. Anyone who tells you otherwise is wrong.

• Use Rust, but don’t worry if you don’t understand it. That’s the AI’s job :).

Why Rust? Three reasons:

• Rust has a lot of safeguards built in to stop accidental coding mistakes. Those safeguards help the AI too. The compiler is very thorough and will spot errors made by Claude. Other languages (cough, Python, cough) don’t have anything nearly as good.

• Rust has a brilliant built-in test framework. So we can easily get Claude to generate tests for us. If those tests pass then it’s much more likely that Claude has implemented what we asked for.

• Rust has a lovely build manager called cargo. It makes building and running tests easy. No more horrid makefiles!

Step 1 - install Rust

Installing Rust is trivial. Go to https://rustup.rs/, download the installer and follow the instructions.

Once the install has completed run the command:

cargo

If it works you’ll get something like this:

cargo is Rust’s package manager. It can create new projects for you, compile projects and run tests. It’s the only Rust command you need to know. It’s your new friend!

Step 2 - create a new project

Make a new directory to store your tools in. I store my projects in c:\language.

Then run:

cargo new <toolname>

(note: best to use snake case - lowercase - otherwise Rust will complain).

This creates source code directories, build files etc for you. To build:

cd <toolname>
cargo run

Now we’ve got a new Rust project ready to update.

Step 3 - get Claude to build a tool for you

For my test tool I’m going to build my own version of unix2dos - a tool that converts file line endings from unix format to dos format. It’s a good example of the simple kinds of tools Claude is great at creating.

A few seconds later I had code! Then I got Claude to review the code.

I find this is a useful step - LLMs have no way to go back and adjust earlier output. Giving Claude the chance to review enables it to adjust anything it got wrong the first time round.

I’ll often repeat this step multiple times until it stops finding bugs (or stops finding serious bugs).

Then I got it to add UTs.

You’ll also need a cargo.toml file. This defines the project and tells the Rust compiler which 3rd party libraries you want to use. More often than not Claude forgets to generate this so you have to remind it.

Time to compile and test the code. Do that with:

cargo test 

And would you believe it - the code built first time and passed all tests. Hurrah!

However cargo test only builds a temporary executable. So you need to run

cargo build --release 

to build the optimized final version. And that gets placed in c:\language\unix2dos\target\release. There’s also a target\debug directory - where the debug version goes (you can build this with cargo build).

Here’s a handy summary flowchart - thanks Claude!

What goes wrong?

Partial files

Claude has a limit on how much output it can generate at once. It’s a subtle message that’s easy to miss (at least, I’ve missed it more times than I care to admit).

If Claude is generating code, then you’ll get a part generated file which won’t compile. Fortunately, the solution is simple, although mildly tedious:

And then glue the two parts together. I use vscode to merge them. The break is normally very obvious. I suspect it’s just a matter of time until Claude will produce longer outputs by default… …but for now I just accept it.

Broken code

Claude isn’t perfect. Sometimes it’ll generate code that doesn’t compile. I find repeating the “review this code thoroughly” prompt before trying to compile effective at getting rid of most of the bugs. I’ve also found it useful to explicitly tell Claude not to refactor unless it has to - otherwise it has a tendency to needlessly change code (a tendency not confined to LLMs)…

If after all this you get stuck in a “generate-copy-compile-error” loop then that’s probably a sign you’re trying to do something too hard for current LLMs.

UI formatting

Claude’s not great at visualizing how output will look on the screen. To be honest, I’m not great at this either - it’s something I always need to iterate. So expect to play around with this. For now I find it easier to ask Claude where the output code is and then tweak it manually.

Occasionally Python is better

Python lacks UTs. It’s more fragile than Rust. But sometimes it’s the right choice - especially if you are integrating with third party libraries.

For example Claude wrote a very complex mp3→mp4 conversion tool in Rust that attempted to use a graphics library to create visualizations. It was a struggle to get it to build and after all that the visualizations were, err, not brilliant.

Claude then tried again with Python, found a visualization library and the results were great.

So while I prefer Rust, sometimes Python is the pragmatic choice!