You can have a prototype in a day. That doesn't get it into production.
With AI, even someone from finance can click together a working app today. It's a great way to find out what you really want. But before you roll it out to the whole company, you need to pull out what it taught you and write it down.
A 44-year-old idea finally works
In 1982, a book came out with a title that sounds like an AI ad today: Application Development Without Programmers. Its author James Martin later turned it into a method called rapid application development, RAD for short.
Its core idea: people don't know what they want until they see it. So there's no need to plan for months. Build a clickable prototype quickly, put it in people's hands and keep building based on their reactions.
The promise didn't come true back then. The tools of the time couldn't build anything complex from a description. Today AI builds a working prototype in minutes. Developers call this vibe coding: you say what you want, AI builds it, you react and it adjusts.
With a person
When you buy a flat in a new building, the developer shows you renderings and a show flat. Only when you walk through it do you notice the kitchen is in the wrong place next to the bedroom.
With AI
The prototype is that show flat. You have it in a day, click through it with colleagues and immediately see what doesn't work. There is no cheaper way to find mistakes in a brief.
What a quick prototype is ideal for
Building an app quickly with AI is excellent where a mistake costs nothing:
- testing an idea before you invest in it,
- showing management or a client what it could look like,
- building a simple internal tool for a few people,
- finding out what you forgot in the brief.
“A car service wants customers to book appointments online. The workshop manager clicks together a prototype with AI in an afternoon: a calendar, a choice of service, email confirmation. The mechanics try it for a week, and it immediately turns out that a tyre change and a service inspection can't have the same slot length. In a meeting, nobody would probably have noticed.”
The problem is the rule you can't click on
The prototype looks finished. And this is exactly where every managing director asks: “It works, when can the whole company have it?”
Back to the car service. Nobody wrote in the brief that a customer must not cancel someone else's booking. Or that they can't see other customers' names. So AI didn't write such a rule. Nobody runs into it while testing, because you can't click on a rule that doesn't exist.
In 2025, Veracode tested more than 100 language models, and in 45% of tasks the generated code had a security flaw. That's no reason not to use AI. It's a reason not to put a prototype into production without checks.
Building quickly also skips everything that makes software reliable:
- tests that verify it does what it should,
- code review by someone other than the author,
- a history of changes so you can roll back,
- safe handling of passwords and access.
Keep the prototype. What goes into production is what it taught you
The solution isn't to throw the prototype away, but to write down what you learned from it. Business rules, conditions under which you accept the result, security requirements. For example: a customer sees and cancels only their own bookings.
Once a rule is written down, someone who never tried the prototype reads it too. And asks: “What if someone enters another person's booking number?” Every written rule can be turned into a test that the finished app must pass. We describe what such a brief looks like in our article on spec-driven development.
| PROTOTYPE | APP FOR THE COMPANY | |
|---|---|---|
| Time | hours to days | weeks |
| Who builds it | anyone with AI | AI led by a developer |
| Rules and security | only those someone wrote | written down and tested |
| What it's for | testing and showing | relying on it |
“We work the same way when building for clients: a demo every 1 to 2 weeks, so you react to something you can see. Code and access are in your name, and we give a 60-day warranty. A prototype is the start of a conversation, not the end of a project.”
Programmers haven't disappeared. And they're not the only ones you need
A 1982 book promised development without programmers. 44 years later, writing code really is cheaper. But programmers haven't disappeared, and their work is still demanding. They may write less code and review more, but they have to understand it: the architecture, the links between systems and what breaks with every change.
Just as important are people who can put a product together. A product person knows how to ask the right questions, decides what belongs in the tool and what doesn't, and assembles the prototype so that people actually use it. Marketers are trying vibe coding today too, building their own tools. It's a good start, but a tool made by marketing for marketing is not yet a product the whole company will use every day.
A product manager, a developer, a marketer, a generalist who can do a bit of everything and a company owner each do different work. Faster prototyping doesn't replace these roles and this experience. That anyone can build a prototype today is great. But on its own, it doesn't create a product.
Nor does it mean you shouldn't ask about price. When a supplier works faster and more efficiently with AI, it's fair to expect that to show in the cost of development.
For management, there's a simple rule. An AI prototype is great for finding out what you want. To rely on it, you need a brief, tests and someone responsible for the result.
Ask yourself
Is anything running in your company today that started as a quick experiment, and nobody knows anymore which rules really apply in it?
