‘You no longer need to learn to code.’ That is the usual summary of vibe coding, and for building it holds up well: you tell an AI tool what you want, and something that works comes out the other end without writing a line of code yourself. For judging the result, the promise falls apart. Whether that working thing is any good is not something the tool tells you.
The knowledge for that judgement does not disappear. It shifts, from the hands of the builder to the judgement of whoever decides. Often, that is you. Sooner or later a vibe-coded prototype turns up in your organisation, and you decide whether it deserves to become something more.
Working is not the same as finished
AI coding tools optimise for a result that runs, not for software that is secure, maintainable and scalable. A prototype that looks flawless can store passwords unencrypted, give every user access to all the data, or grind to a halt the moment ten people log in at once. None of that shows up in a demo, and the builder often does not spot it either. You do not need to read a single line of code to catch this. You do need to know which questions expose the difference.
Five questions you can ask yourself
This checklist needs no technical background, only the willingness to keep asking. Put the questions to whoever built the prototype, and pay attention not just to the answers but to how confident they sound.
- Where are the passwords and API keys stored? The right answer is in a protected configuration, outside the code. If they sit in the code itself, the key is under the doormat.
- Who can see what? Create two test accounts and try to open one account’s data with the other. If that works, access control is not properly set up.
- What happens when something goes wrong? Ask about backups, error handling and incorrect input. A prototype without a safety net is fine, until someone trusts it with real data.
- What personal data does it contain? Customer data in a prototype means GDPR already applies, not only once it goes live. Also ask whether any data was pasted into an AI tool while building it.
- Can the builder explain it? Ask them to talk you through a random part of it. Whatever nobody can explain, nobody can maintain or fix either.
What vibe coding is for, and what it is not
For exploration, vibe coding is a useful tool: testing an idea, a demo for a client meeting, a throwaway tool for a one-off job. We develop AI-assisted ourselves too, and see every week how much pace that adds. But an engineer always reviews and steers the generated code on our end, because these tools make the same kind of mistakes whether the user is experienced or a beginner. You can read which ones in the pitfalls even advanced users fall into. The moment an application handles customer data, connects to other systems or carries a process the organisation relies on, that expert eye stops being a luxury and becomes a requirement.
What to do with the outcome
If the prototype passes the five questions, you probably have more than an experiment on your hands. If it fails, you know what needs to happen before colleagues or customers can rely on it. Either way, the next step is the same: have someone with expertise assess what it takes to turn it into properly engineered software. Sometimes that means cleaning up and filling gaps; sometimes rebuilding part of it is the more honest, and ultimately cheaper, choice. We handle that assessment and the build that follows under ongoing development and maintenance. The conversation then starts with what you want from the application, not with what is wrong with the code.