Most bugs in AI-generated apps do not start as bugs. They start as vague prompts. You ask for “a login form” and get one, but it has no rate limiting, no password validation, and it stores the session token somewhere it shouldn’t. The AI did what you asked. The problem is what you asked for was underspecified, and the model filled the gaps with whatever pattern was statistically common in its training data, not whatever your app actually needed.
Better AI code prompts will not eliminate bugs. Nothing does. But a few habits of prompt engineering for coding tools like Cursor, Bolt, and Lovable will cut down the mess considerably, and they take about thirty extra seconds per prompt. We spend our days fixing what came out the other end of sloppy prompts, so we have a fairly clear view of which habits actually move the needle and which are just superstition.
Why vague prompts produce fragile code
When you write “build a signup page,” the model has to guess at dozens of decisions you never made. Should the email be verified before the account is active? What happens if the password field is empty? Should duplicate emails throw a friendly error or a raw database exception? None of these are coding questions. They’re product questions, and if you don’t answer them, the AI answers them for you, usually by picking the simplest path that makes the demo work.
This is the core issue we cover in why AI coding tools keep making the same mistakes: the model isn’t wrong, it’s unconstrained. It optimises for “runs without erroring in the next five minutes,” not for “handles the messy inputs real users will throw at it in six months.” A vague prompt gives it permission to stop at the first version that compiles.
The fix isn’t to become a professional prompt engineer overnight. It’s to close the specific gaps that reliably cause trouble, which we’ve grouped into four habits below.
Habits that cut bugs
State your constraints up front, not as a follow-up. If you need the API to handle 500 requests a minute, say so before the first line of code gets written, not after you notice it falling over. Retrofitting constraints into existing code is where AI tools genuinely struggle, because the model has to reason about code it already committed to rather than a blank slate. Tell it about rate limits, expected data volumes, required browsers, and any compliance requirements in the very first prompt.
Ask explicitly for error handling. This is the single highest-leverage habit we know of. AI models default to the happy path unless told otherwise. If your prompt is “add a function that fetches the user’s orders,” you’ll get a function that assumes the fetch always succeeds, the user always exists, and the response always has the shape you expect. Add one sentence: “handle network failures, missing data, and empty results explicitly.” That sentence alone prevents a huge share of the runtime crashes we see in vibe-coded apps.
Make one change at a time. It’s tempting to ask for five things in one prompt: add a feature, refactor a component, fix a styling bug, and update the database schema, all in one go. Every additional instruction in a single prompt increases the odds the model drops one silently or tangles two changes together in a way that’s hard to unpick later. One change per prompt is slower to type but dramatically easier to review, and easier to roll back if something breaks.
Demand the edge cases by name. Don’t just say “validate the form.” List what you mean: empty fields, malformed emails, special characters in names, extremely long inputs, duplicate submissions. If you can’t think of the edge cases yourself, ask the model to list them before it writes any code, then review that list critically. This is essentially the same discipline we describe in how to review AI-generated code even if you’re not a developer: you don’t need to write the code, but you do need to interrogate what it’s supposed to handle.
Prompts that quietly cause trouble
Some prompt patterns feel reasonable but reliably produce fragile results. “Make it work like [competitor app]” sounds efficient, but it hands the model an enormous, ambiguous spec with no detail on your actual data model or business logic, so it improvises heavily and inconsistently.
“Just get it working for now, we’ll clean it up later” is another one. AI tools take this instruction literally and it shows: hardcoded values, skipped validation, credentials pasted directly into the code rather than pulled from environment variables. The “later” cleanup rarely happens, because by the time you’re back in that file three weeks on, you’ve forgotten it needs cleaning. If you know a shortcut is temporary, say so in a comment in the prompt itself, so at least there’s a trail.
Broad prompts like “fix the bugs in this file” without specifying which bugs are also risky. The model will find something to change, because that’s what you asked for, even if the real bug is somewhere else entirely. Be specific about the symptom: what did you click, what did you expect, what actually happened.
The limits of prompting
Here’s the part we’d be lying if we skipped: no prompt, however carefully worded, replaces someone actually reading the output. Prompting shapes what the model attempts. It does not verify what the model delivered. We’ve seen founders write genuinely excellent, detailed prompts and still ship apps with SQL injection holes, because the AI’s implementation quietly diverged from the instruction and nobody checked.
Prompting also can’t fix architectural decisions made three prompts ago. If your data model was set up wrong in session one, no amount of careful phrasing in session twenty fixes the underlying structure. At some point the accumulated shortcuts need a person with security and architecture experience to go through the codebase directly, not another prompt. That’s really the boundary of the whole exercise, and it’s one we walk through in more detail in what is vibe coding and why your app has bugs.
It’s also worth being honest that this discipline gets harder to maintain as a project grows, not easier, which is part of why we’re sceptical of claims that AI will simply fix its own bugs without a human in the loop. The tools are improving. The need for review isn’t disappearing at the same rate.
Even great prompts leave gaps. Get a free review of what yours missed.