The demo is convincing. Someone on your team shows off an application that’s largely AI-written, and everything works: logging in works, the numbers add up. But the question on the table isn’t whether it works. It’s whether you want to let it loose on customer data and the processes your organisation depends on.
You don’t need to code to make that call. The mistakes of vibe coding, letting AI generate code with no expert checking it, are predictable; they just stay invisible as long as the output works. Here are the five biggest pitfalls, turned into questions for whoever built it, plus the agreements that prevent them next time. Whether vibe coding suits your project at all is covered in when vibe coding suits your project and when it does not; this article is about the step after that.
Nobody has read the code
An AI tool is satisfied the moment the outcome does what you asked; security and maintainability play no part in that judgement. A developer builds in safety nets such as input validation as standard; an AI tool only if someone asks, and if you don’t know to ask, you won’t get them. The demo shows the route where everything goes right; the mistakes live on every other route.
The first question to ask: who read the generated code line by line, and would that person have written it that way themselves? If the answer comes down to trusting the AI, there has been no review.
Two checks you can do yourself, with no technical knowledge. Ask where the passwords and API keys live, the credentials the application uses to talk to other systems. The right answer: in a protected configuration, outside the code. If they sit in the code itself, the key is under the doormat. Then create two test accounts and try to open one’s data with the other. If that works, access control isn’t in order.
The application doesn’t know how your business actually works
Without context, AI delivers a generic solution: technically correct, built for an average company that doesn’t exist. Think of a login screen with no roles or permissions, or an integration that only handles the error-free path and trips over everything outside it.
Ask what context the AI was given about users, business rules and exceptions. The vaguer the answer, the greater the chance the application fails on exactly the situations your people run into every week. Also ask what happens with incorrect input, and whether there’s a backup.
Under the bonnet, the debt keeps stacking up
Every prompt lays a new layer over the last, and the AI has no memory of yesterday’s choices. After dozens of iterations the application still works, but internally it’s held together by duplicated logic and contradictory patterns. You notice it in the pace of change: every adjustment takes longer and breaks something else more often.
So check whether anything was ever cleaned up along the way, or only added. And whether the key decisions are written down anywhere outside the chat history.
A confident answer is not proof
AI presents a flawed approach just as confidently as a sound one, and gives no signal when it’s working beyond what it knows. With a small component you spot that quickly; with architecture, security or database design, only once the application is in use.
Ask which high-stakes decisions were checked against a second source: documentation, an expert colleague, an external review. If the AI was the only authority, the foundation rests on a convincing story.
Nobody actually knows the system
The stealthiest pitfall isn’t technical, it’s organisational. Build mostly with AI, and you train your own problem-solving ability less and less. If the application goes down and the AI has no useful answer, someone needs to be able to reason about the system unaided.
Which makes the final question the simplest: who can explain and fix this application without AI alongside them? If nobody can, what you have isn’t software under management, it’s a risk in production.
How much a disappointing answer weighs
That depends on what’s at stake. An internal prototype for a small team, with no sensitive data and easy to replace, can get by with a quick check. A tool colleagues use every day, or a first version for customers, calls for a thorough code review and security check. Once customer data, payments or medical or financial information are involved, or the application is live for a wider audience, a full technical review up front is the minimum. Personal data also means the GDPR already applies, not only once it goes live; so ask whether any data was pasted into an AI tool during the build.
Integrations push a tool straight to the heavy end of that scale. As long as it stands on its own, the damage stays contained. If it writes to your CRM or accounting package without checks, an error spreads quietly through your entire back office; if the connection falters, one without error handling keeps going on half the data. So ask, per integration, what is checked before anything is written, what is logged, and how you recover after an outage. That is what makes a data integration proper software, and exactly what an AI tool skips on its own.
Agreements that prevent it next time
These pitfalls arise because a prototype quietly grows into something colleagues rely on every day. A few agreements up front prevent that.
- Treat every vibe-coded prototype as disposable, even when it seems to work well.
- Passwords and API keys never sit in the code, but in protected settings outside it.
- Prototypes run on test data or a copy, never on production systems.
- The key decisions are recorded outside the chat history.
- If a tool touches customer or personal data, an experienced developer reviews the code first.
- If a prototype turns serious, it gets rebuilt professionally before it goes live.
From proven idea to production-ready software
If several answers fall short, that’s no reason to throw the project away. A vibe-coded application is often a decent prototype: it proves the idea works and makes concrete what you need. A proven idea just isn’t production-ready software yet. We develop AI-assisted ourselves, with engineers who review and fit in every generated line. Once your team’s prototype gets serious, we turn it into software you can confidently put in front of your customers, through ongoing development and maintenance. We’re happy to think it through with you: is it worth the rework, or is starting again the smarter move.