When someone shows you an app they built with AI over a weekend, what exactly are you looking at? It might be a convincing demonstration, a useful personal tool, or something a business can safely rely on. Those are different achievements, even when the screens look much the same.
Part of why I'm writing this is the dismissive way people talk about "vibecoding".
Building software by describing what you want to AI, trying the result and asking for changes, often without reading the underlying code. Some are calling it "slop coding" or "prompt and pray" and these dismissive terms can obscure something incredibly valuable: someone who understands a problem can now build a version they can actually test.
There are legitimate concerns about security, reliability and maintenance, especially when other people are expected to depend on the result. But a prototype doesn't have to be ready for production to justify building it. I want us to be more precise about what someone has achieved, what they've learned and what responsibilities come next.
Often clients and training workshop attendees ask me:
- "Do I need to learn to code?"
- "Can we build this with AI ourselves in-house?"
- "Do we need a developer?"
This article, and its companion article on automation literacy approach these questions together:
- Automation literacy covers what you need to understand to turn work you understand into a repeatable system.
- This article looks at how to judge whether that system is ready for people to depend on, and where technical expertise is needed.
Both help you decide how far you can take the work yourself and when to bring someone else in. Here, I start with two questions: what have we actually proved, and what would happen if it failed?
Six stages, from mockup to production
I use these six stages to help clients discuss systems and workflows they've built and what still needs checking. These stages draw on familiar software-development terms, but this particular grouping here is a practitioner's guide rather than an established industry standard. It'll be useful but note that stages can overlap, and a project doesn't necessarily need to pass through all six.
The early stages each deal with a different unknown:
- A mockup helps you explore what people need and how they might use it, often the user interface or user experience (UI & UX).
- A proof of concept tests a technical uncertainty, such as whether two systems can exchange the information you need. Is it feasible?
- A working prototype brings the main workflow together so you can try it from beginning to end.
None of these removes all the risk. Each one gives you evidence for the next decision.
| Stage | What you have | The question you're testing |
|---|---|---|
| 1. Mockup | A representation of the screens or workflow, without the working system behind it. | Does this look like the right thing to build? |
| 2. Proof of concept | A focused experiment testing feasilibility a difficult or uncertain part. | Can this part work under the conditions we need? |
| 3. Working prototype | The main workflow works end to end, with known gaps. | Does this help someone do the job? |
| 4. Controlled pilot | A small group tries it in real work, with oversight and a fallback. | Does it help in practice, and can we contain failures? |
| 5. Limited release | A wider but bounded group uses it, with support and monitoring. | Can people use it reliably without the builder beside them? |
| 6. Production | A maintained service people can depend on for its intended purpose. | Can we meet our commitments and recover when something fails? |
Treat the stages as a guide to decisions. You won't always need every stage, and they don't always come in this order. Mockups and proofs of concept can happen either way round, and a small tool might not need a separate limited release.
Development teams often use labels such as "alpha" and "beta" in different ways. "MVP", or minimum viable product, is another label people use to describe a stage. An MVP is the smallest offering that lets you test an important assumption - often product-market fit - and it says nothing about how robust the software is. If real users depend on your MVP, their needs and the cost of failure still set the bar.
. Used with permission.](https://humanspark.ai/wp-content/uploads/2026/10/mvp-skateboard-HenrikKniberg.png)
Henrik Kniberg explains this well in Making sense of MVP, with his well-known skateboard-to-car illustration. Each version gives users something to try, so their feedback can shape what comes next. You might discover that a bicycle solves the problem and there's no need to build the car. Alongside that learning, you still need to judge whether each version is reliable enough for what you're asking people to do with it.
A proof of concept is often built to be thrown away. If you keep its code, review it for the job it's now doing. Proving that one part can work doesn't establish that the code is ready for wider use.
Internal software can already be production software
An internal tool isn't automatically less mature than a public product. If three people depend on it every day to run payroll or manage client records, it's already in production use. That's true whether or not the software is ready for that responsibility.
Equally, a personal utility may never need accounts for thousands of users, a polished interface or round-the-clock support, and building all that would waste effort. It still needs to handle the things that matter for its particular job.
You don't have to turn every useful tool into a commercial product. You do have to recognise when an experiment has become something people rely on.
The stakes decide how much checking you need
The stages describe how much you've established about a system. The consequences of failure tell you how much assurance you need.
Imagine a tool that renames files. Run it on disposable copies in a test folder and a mistake is an inconvenience. Point the same tool at your firm's client archive and incorrect names could make records difficult to identify or break links other systems rely on. The code is identical in both cases. What changed is what it can reach and how much an error would cost.
That's why "internal" and "external" aren't enough to judge risk. You also need to know what data the software handles, what it can change, whether you'd notice a mistake and whether you could undo it.
If an early version already touches real systems or sensitive information, check its security and privacy now, whatever stage you'd call it.
What AI changes about building software
AI lets more people turn their understanding of a job into something they can test. If you know the workflow, you can describe it, try a first version, spot what's missing and improve the brief. That's valuable even if the first build never goes into daily use.
AI helps with the later work too, including tests, debugging, code review and documentation. That help still needs checking, and how much it saves depends on the project and on who's directing the work.
Producing a working version and establishing that it's fit to depend on are separate pieces of work. A successful demo is good evidence of the first and tells you much less about the second.
You still need to find out what happens with missing information, duplicate requests, unexpected inputs or an unavailable service. Someone needs to notice failures, restore lost data where necessary and maintain the system as the services and libraries it relies on change. How much of this you need depends on what the software promises and who's relying on it.
You can contribute a great deal here without writing code, because you know which inputs are unusual and which failures would hurt. Someone does need to be able to check the technical work to the standard its consequences require. That might be you, a colleague or a specialist. An experienced developer can use AI throughout that work. Their contribution includes knowing what to check, spotting what hasn't been proved and judging which trade-offs are acceptable.
A useful prototype is a real achievement
If you bring me a prototype that demonstrates the job you need done, we have something concrete to examine together. We can find missing requirements, test whether it saves useful time and show a budget holder what the investment might achieve.
It won't prove the whole business case or settle every requirement, but it takes some of the guesswork out.
Even if the software needs rebuilding, what you learned making and testing was still useful!
This is where I think vibecoding is undervalued. Someone who couldn't previously build software can explore an idea, discover requirements they hadn't thought to mention and demonstrate a workflow that was difficult to explain in words. Even if a developer later rebuilds it, that learning can make the next investment better informed.
I don't think someone needs to read every line of generated code before they can learn from a prototype. They do need to keep the experiment within limits they understand: for example, using dummy data in an isolated environment, without access to live business systems. Trying a workflow can tell you whether it's useful. It won't, by itself, establish that the implementation is secure or maintainable.
If that prototype is going to become something people depend on, the technical work needs appropriate checking and ownership. That's a further responsibility, and recognising it doesn't diminish what the builder has already achieved.
What to do with your own project
If you've built something with AI, I'd start with five questions:
- What have we actually proved? Separate what you've observed from what you hope will work.
- Who depends on it, and what can it affect? Include data, money, other systems and people's work.
- What happens when it goes wrong? Check whether you'd notice, how you'd recover and what the fallback is.
- Who owns it after the demo? Name who looks after maintenance, access and changes, and who can check the technical work.
- What's the smallest sensible next step? That might be another test, a narrower scope, specialist help or a decision to stop.
The aim is to reach the standard your use requires and to have evidence that you've reached it. A modest tool that reliably solves one problem may be all you need.
-- Alastair
P.S. If you have an AI-built project and aren't sure whether it's ready for daily use, book a 25-minute Focus Call and we'll look at what you have and what's still unproven.