I’ve started experimenting with using LLMs to help me build software.

One of my background goals in life is to remove or reduce the labour-intensive tasks that hog my time. One way of doing this is to automate. I already have tons of little scripts that do things for me... but I've always found that I'm sloooow at creating those little tools and automations.

So, recently I've started getting LLMs to help me build stuff to simplify my admin, and I admit I've been getting mixed results. I've already written a little about how easy it is to get pulled down a rabbit hole by an LLM, and sometimes that effort-in-vs-results-out trade-off gets made worse by LLM-augmentation. But as I've got better at directing an LLM to harness its strengths and mitigate its weaknesses, I've also got better at either building tools quickly - so they genuinely do save me time - or abandoning ship and quitting while I'm ahead.

So, how do you build a useful thing quickly?

I'm going to share one simple workflow, which in itself was a learning experience for me.

What I wanted was a tool that would help me deduce the url for one of these blog posts before it had been published. It's not rocket science, it's just that Kit doesn't let you know the url until after publication. And I want to know in advance, because I like to put the following text at the bottom of every post:

The pattern is always the same: The same prefix (https://queen-of-questions.kit.com/posts/), followed by the post title but with the following changes:

• Punctuation removed
• Apostrophes replaced with hyphens
• All lower case
• Words separated by hyphens

I could build the url myself by taking the post title and manually making those changes. But that's fiddly, annoying and error prone.

I could use regex. But I really hate regex.

So wouldn't it be lovely if I had a little tool that could do this for me? But this is such a tiny task. A whole tool feels like overkill. Then I remembered, LLMs are really good at regex. OK! So I added this section to my notes on using Kit to write blog posts:

I gave the above prompt to the LLM (in this case, GPT-5 in Windsurf). It "thought" for 22 seconds, and then created the correct url for me. I was about to leave it there.

But. Every time I want to repeat this process, I'll have to go fetch that prompt from my Obsidian notes. Why keep it there? Why not put it in a process file and have it always on hand for the LLM? I learnt about process files from Llewellyn Falco, and I use them a lot now. So I created this process file and changed my notes:

I was going to stop there. This is a tiny tool. I was mindful of that xkcd cartoon I've pasted above. I had other things to be getting on with. I didn't want to over-egg this pudding. But... that's quite a long wait. Twenty-two seconds.

Every time I follow this process I'm going to be asking the LLM to reinvent this wheel. Why not, instead, ask it to create a lasting utility, one that'll give consistent results every time and won't require LLM interaction every time it's used?

So I gave the LLM the following prompt:

I got on with what I was doing and left the LLM to it. No more of my time was taken up with this task, but the LLM "thought" for 14 seconds, then another 9 seconds, then gave me this neat little tool, which works delightfully:

...and now my Kit post creation notes look like this:

What I love about this, is that the above is a screenshot from instructions on how to generate links for posts like this, in which I have embedded a link to this very post, even though I haven't published it yet, because I used that tool to generate that link to refer to this post about how I created a tool to generate links to posts like this so I could generate them in posts like this... [deep breath]. How meta is that?

Scripts vs user interfaces

But why an HTML tool? Why not a simple command line script?

I started my software engineering life in 1994, building desktop Windows software. I always preferred what an ex colleague used to call "the clicky-clicky" to the DOS prompt. I used to see colleagues whizzing their way around the command line with a ton of esoteric indecipherable commands. I could never understand why they wouldn't prefer a nice user interface with buttons and labels and a clear visible flow of what was expected from the user*. After all, this is what we software engineers do. We build neat little usable tools with good user experience (UX), to make our users' lives easier. Why wouldn't we want the same for ourselves?

I used to feel insecure, ashamed, embarrassed about my preference for nice UX. Like if I wasn't communicating with my machine via opaque gobbledygook, I wasn't a real engineer. But these days I try to quell that voice, remind myself that people are different, shrug and move on.

*The answer to "why not clicky-clicky" is often because of the value of config as code. And this is why yes, these days I prefer scripts to clicky-clicky for things like cloud config. But whenever I can wrap that stuff in a nice UI, I totally do.

So what's the code like?

Honest answer: I have no idea.

I still haven't looked*. I don't want to look. I don't care. You can look if you like. It's probably horrible. But so what? It's a very simple tool. It works. I can bookmark it and run it whenever I like, at the click of a button. I always have a browser open, no matter what I'm doing. This way I don't have to spin up a terminal and remember a command. And look at that xkcd cartoon. I'm trying to make my life easy, save time and avoid rabbit holes. I don't need to spend my time looking at the code.

And no, there aren't any tests. For anything even slightly bigger or more complex, I would use TDD (test driven development). But I didn't see the need in this case.

*Well OK, I have now had a quick look - to check I'm not about to unleash some kind of hideous virus or DOS attack on my machine and the rest of the world.

This process works on larger projects too

As mentioned above, for a larger project I would absolutely use test driven development. I would move in small iterative steps, I would ask the LLM to write tests before every coding step, and I'd make sure those tests passed one at a time.

But there were three basic steps I used here that work really well whenever you ask an LLM to make you a thing:

1. Use an impromptu prompt to describe what you want.
2. Create a project spec that summarises step 1. This becomes a persistent description of the project. It's reusable, and can exist independently of any LLM context.
3. Ask the LLM to use the project spec to create a lasting reusable tool.

This was such a tiny project that I missed a few details out of what has become my normal process. So ,below is a more comprehensive set of steps. I've highlighted the additions in bold:

1. Use an impromptu prompt to describe what you want. Encourage the LLM to ask clarifying questions. Have a bit of a back and forth to get more clarity.
2. Ask the LLM to create a project spec that summarises step 1. This becomes a persistent description of the project. It's reusable, and can exist independently of any LLM context.
3. Ask the LLM to use the project spec to create an outline set of tests.
4. Move gradually through the tests, seeing each one fail before it passes, refining as necessary, and in the process create a lasting reusable tool.
   ​

That's it!

Come on this journey with me

I plan to keep writing about this topic. I’ve already got a raft of draft posts in pocket. I love to learn, and I love to teach (and I’m really bloody good at it). I use teaching as a way of deepening my own knowledge and pushing me to learn things more effectively.

If you want to know more, you can do the following:

• Read some advice on getting started with LLM-augmented coding​
• ​Subscribe to this newsletter​
• Sign up for a workshop in building robust maintainable software using genAI:
  • 18th to 19th Nov 2025: A two-day workshop for Trifork Academy in Amsterdam
  • 25th Nov 2025: A one-day workshop at Software Architecture Gathering in Berlin
• Keep an eye on my socials (LinkedIn, BlueSky, Mastodon)
  • …and my events page…
  • …for new workshops and training sessions
• ​Read the testimonials​
  • …about the above workshops and others

🔗 Want to share this article or save it for later? Here’s a handy link for you!​