​

I’ve started experimenting with using LLMs to help me build software. One of the first things I did was to watch the video of Llewellyn Falco’s talk about using process files as blueprints for Agentic AI, from Craft Conference 2025. I learnt a lot from this, and it was a great starting point to get me going with LLMs.

In that video, Llewellyn does over an hour of live augmented coding on stage. And one of the first things I noticed was that he uses the LLM for almost everything. I was about to list the things he uses it for, but then I thought instead, I’d take you through one of my first LLM coding sessions, and how I deliberately tried to be more Llewellyn.

Do LLMs save you time?

One of the things I’ve noticed is how much people argue over whether LLMs can genuinely save them time and effort when coding. My goal is to have the machine do the boring fiddly stuff for me, so I can focus on the more interesting stuff.

“Time and effort when coding” are notoriously difficult to measure, but one of the things I do consistently already (because I’m me) is time everything I do (spreadsheets ftw). So one of the things I’ve been doing is deliberately experimenting with different approaches and timing the results. Time is one metric I’m using to track any benefit I’m getting from the LLMs.

In one of those first coding sessions, I was experimenting with different approaches to a coding task. I chose the Fizzbuzz kata. Using LLMs for katas is kind of pointless (I agree with Emily Bache on this), but my goal was not to practice the kata. My goal was to use the LLM in different ways and measure the results, to see whether and how it could make coding easier and more fun. ## Be More Llewellyn

So. As well as using a standard Test Driven Development (TDD) approach (which I’ll write about separately), I also asked it to write the code first and then write the tests. I’m not generally a fan of writing code first and tests second, but I was deliberately comparing and measuring different approaches. And here’s where I had to keep reminding myself to be more Llewellyn, in the following ways:

Temptation: To describe the FizzBuzz challenge to the LLM, manually, myself.
​Danger: Nope. Too time-consuming. Unnecessary effort. ​
Solution: Get the LLM to go find its own FizzBuzz specification. Ask it to implement it.

Temptation: To look at the code Claude generated for me.
​Danger: Nope. I’ve never been quick at reviewing code. It’ll take me a while to get my head into it, and then I’ll get distracted by trying to understand and critique every tiny detail.
​Solution: Just run the code! Does it work?

Temptation: To look at the code.
​Danger: Nope. Same problem still applies. Too slow.
​Solution: Get the LLM to write tests to prove it works.

Temptation: To look at the test code. I’m already pretty confident I won’t like it.
​Danger: I’ll have to work out which tests are redundant, and manually make sense of the code to work out whether it does what I want it to.
​Solution: Just run the tests! See what happens!

Temptation: Surely now it’s time to dig into the code? Work out exactly why these tests are failing?
​Danger: Still slow.
​Solution: Ask Claude to work out why the tests are failing.

Temptation: Ask Claude to try again to spot the problem.

Danger: Claude will continue to miss it, because Claude is not clever in the way you might think. Note that in other LLM coding sessions, this has been a real flashpoint for me. Getting sucked down a rabbit-hole is always a danger when building software, but it’s particularly easy to get pulled into the death-loop of “we’re almost there, let’s try one more thing” when working with LLMs. Even though the cost is small, the sunk cost fallacy still applies. Kent Beck has interesting things to say about it in this podcast conversation with Jessica Kerr (which I’ll write more about another time).

Solution: Finally, now it’s time for me to read and understand the code.

The Jagged Frontier

Ethan Mollick, author of Co-Intelligence (which I recommend) talks about the jagged frontier. LLMs are great at some things and terrible at others, and the line between the two is jagged and constantly changing. You have to keep pushing and experimenting and working out what they’re good at and what they’re really not good at. As well as how to give them what they need to exploit their strengths and mitigate their weaknesses (process files are great for this - more on this in another post).

In Llewellyn Falco’s coding demo, there are several other examples of asking the AI to do something rather than do it himself - most notably in the creation and refinement of process files. There are many things we’re used to doing ourselves, but when we’re working with LLMs it can be unnecessary and slow us down.

At this point in the Fizzbuzz example, I’m not done. The code isn’t great and the tests are problematic. Getting the LLM to do as much as possible is only one useful principle when working with these tools. There are many others. But it’s a useful example of a broader principle, which is:

Don’t take anything for granted

• What’s the LLM doing for you? Why? What’s the benefit?
• Is this really helping you, or has it started to hinder you without you even noticing?

Speed isn’t everything in software development. Far from it. Often you want to deliberately slow down and take your time. But if the LLM can do things fast and you don’t need - at this point - to do those things yourself, don’t. Let the LLM do its thing.

Come on this journey with me

I plan to keep writing about this. 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:

• ​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
• ​Fill in this form​
  • …to register an interest in potential upcoming classes
  • …and have a say in how they might be structured
• ​Host a workshop​
  • …in your own organisation
• Keep an eye on my socials (LinkedIn, BlueSky, Mastodon)
  • …and my events page…
  • …for new workshops and training sessions
• ​Read the testimonials​
  • …about these workshops and others