Andrej Karpathy gave this way of building software with AI a name in early 2025. He described it as seeing stuff, saying stuff, running stuff and copy pasting stuff until it mostly works.
I wrote the first version of this post in July 2025. At the time I was using Cursor to build small custom WordPress plugins against real user stories, and it worked. My view has not changed much since, so this is a tidy up rather than a U-turn.
What it is
You describe the outcome you want. The tool writes the code. You run it, see what breaks and ask again. You are not designing the architecture up front. You are moving an idea forward one step at a time.
That is useful early on. It is a cheap way to find out whether an idea holds up before anyone commits a proper budget to it.
Where it stops
A working prototype is not a product. Generated code still needs review. It still needs someone who understands the data, the security and what happens when real customers use it at the same time.
The harder part has not moved either. Someone still has to decide what gets built, for whom, and what gets left out. I wrote more about that in a post on who owns the build.
How it fits the way I work
This way of working is not new to me. On What The Fork, where my role ended in June 2025, and now on Golf Sherpa, I have always sat in the product seat and the build at the same time. Tools that shorten the gap between an idea and a working screen suit that.
They do not replace review, testing and a proper release process. I treat a fast prototype as a way to learn, then build the real thing properly. You can see how I run a build on my process page.
If you are weighing it up
If you have a prototype you built yourself and want to know what it would take to turn it into something customers can rely on, start with the estimator. It gives you an indicative planning range from the features you choose.
Or book a 30 minute call and I will talk it through with you.
