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 appear neatly on screen. But the question on the table isn’t whether it works. The question is whether you want to let it loose on customer data and on the processes your organisation depends on.
You don’t need to be able to code to make that call. The mistakes experienced AI users make are predictable, precisely because working output hides them from view. Here are the five biggest pitfalls, turned into questions you can put to whoever built it.
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. Hardcoded access keys, missing input checks, or authentication that’s almost but not quite right: none of it shows up in a demo. It shows up in production, by which point the application is already processing customer data.
The first question to ask: who read the generated code line by line, and would that person have written it the same way themselves? If the answer comes down to trusting the AI, no review has taken place.
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 will fail on exactly the situations that come up every week in your day-to-day practice.
Under the bonnet, the debt keeps stacking up
Every prompt lays a new layer over the last one, 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 that technical debt in the pace of change: every adjustment takes longer and breaks something else more often.
So check whether anyone ever cleaned things up along the way, or whether it was only ever added to. 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 operating beyond the edge of what it actually knows. With a small component, you spot that quickly. With architecture, security or database design, a wrong decision only reveals itself once the application is already in use.
Ask which high-stakes decisions were checked against a second source: documentation, a colleague with the right expertise, an external review. If the AI was the only authority consulted, 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; we’ve written before about why vibe coding doesn’t mean you can stop learning. What matters for you is the consequence: 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 one: who can explain and fix this application without AI alongside them? If the answer is nobody, what you have isn’t software under management, it’s a risk in production.
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 actually need. A proven idea just isn’t production-ready software yet. We develop our own software AI-assisted, with engineers who can account for every line, so we know both sides of that boundary. Once your team’s prototype gets serious, we turn it into software you can put in front of your customers with confidence, through ongoing development and maintenance.