Today is consecutive day 2,142 of my daily barefoot-style running streak. I have now covered 16,455.40km of the 40,075km I need to complete a lap of the world, which leaves 23,619.60km. Every episode is part of a fundraiser for children's causes, with a goal of £1M. Today's episode was not about running. It was about testing, troubleshooting and scrutinising software built with Claude Code.

The problem with building fast

I am early in an experiment. I want to launch a new business, build the structure, deliver the product or service, and make a profit within 30 days, using AI for as much of the work as possible. I have seen evidence online of people doing this in less time. My business is more complex, which is why I gave myself 30 days.

The plan is to sell AI-created operating systems to small and micro business owners. Pricing is a one-off charge, not a subscription. The client owns everything we build from the start. I may offer limited support on a subscription basis later, but early on the model is build, deploy and monetise.

In the past week I have built a lot of operating infrastructure, first inside my existing property business and then for this new launch. Everything is tailored to me, but I can package it for other people. Volume, though, is not the same as quality.

Why AI builds go wrong

This is the frustration I hear most. You give the AI a prompt. It builds something that looks good, but it is not quite what you wanted. So you give feedback, and it iterates. Then you do it again, many times over days or weeks.

The first version might have been solid. After dozens of changes, the code sits in layers. Some parts are duplicated. Some are weaker than they were. The whole structure gets messy, and then something breaks. I do not think the AI is the cause. The cause is how we work with it: lots of small changes and no step back.

The prompt I use every time

So after I build anything, I ask Claude Code to audit what we have built. I ask for five things:

- Audit everything we have built. - Create a standard operating procedure, or SOP, if one does not exist, showing what was built and how it works. - Check the SOP against what we actually built, so the two match. - Test, troubleshoot and scrutinise everything, then list areas for improvement. - Give a percentage score out of 100 for how ready this is to be a saleable operating system.

I use this same prompt over and over. Claude Code goes back through the build, tidies it, tests it, brings the documentation in line, and returns a list of improvements that would raise the score.

The score matters because it gives me a metric. Without one, "looks fine" is a feeling. With one, I have a number to act on. My own rule is simple. If a build scores below about 80%, I do not sell it. Too many bugs. At 80% or above, the 80/20 rule says it will be effective for whoever buys it, and the list of improvements shows how to close the rest of the gap.

What I did today

I stopped building new things. I spent the day testing, scrutinising and troubleshooting everything we had already made. I brought each piece up to date so I can move forward from a position of strength, not from a pile of work with bugs, errors and glitches that I would find at the worst moment.

Having something look finished and having it work are different. I have been caught by that before, and it is frustrating. A client who pays for an operating system will not forgive a glitch the way I forgive my own.

What I took from it

Claude Code is strong at building software. It is equally strong at testing what it built, stress testing it, finding weaknesses, recommending improvements and fixing them. People from a software background know quality control matters, and they also know it is slow and tedious work. An AI agent now does much of that work for you, and in my experience often better than I would manage myself.

If you are getting into AI, or want to, build the audit into your routine. Do not wait until something breaks in front of a customer. Ask for the audit, the SOP, the test and the score every time you finish a build.

Why this connects to the streak

Running every day for 2,142 days has taught me the same lesson in a different form. Consistency is not about one big effort. It is about small checks repeated, so problems are caught before they stop you. The audit is the software version of that. A quick, regular look at what you have built keeps the whole thing standing.

The mission is the reason I keep doing both. The 40,075km lap of the world is a long-term commitment, and the £1M target for children's causes depends on showing up daily for years. More people watching means more support for the cause. That is why I record every day.

If you have questions or comments, leave them below and I will reply where I can relevantly help. If you believe in the mission, subscribe, share, like and comment. It helps more people see it.

Thank you, and I will see you tomorrow.

Watch the full episode: https://youtu.be/CgqYuTnHGmk