When an AI builder gives you something wrong, it is usually doing exactly what you asked. The gap is between what you typed and what you had in your head. Closing that gap is a skill, and it is the skill that separates people who finish apps from people who get stuck in a loop of fixes.
This is the playbook I use and teach. It applies to Lovable, Bolt and most other AI app builders. The tools change. The habits do not.
Rule 1: Plan before you prompt
Before I write a single build prompt, I write a short plan in plain text. It answers:
- Who is the user?
- What is the one main thing they do in the app?
- What screens are needed for that?
- What data gets stored, and who owns it?
- What is out of scope for now?
Many builders have a chat or plan mode where the AI can discuss without changing code. Use it. Ask the AI to read your plan and point out anything unclear or missing. Fix the plan, then build. Ten minutes here saves hours later.
Rule 2: One feature per prompt
The fastest way to break an app is a prompt like "add user profiles, a dashboard, team invites and email notifications." The AI will try all four, change a lot of files and leave you with something half-working that is hard to untangle.
Instead:
- Ask for one feature.
- Test it.
- Save a working version or note the version history point.
- Move to the next feature.
Small steps make problems easy to find and easy to roll back.
Rule 3: Describe the behavior, not just the screen
"Add a settings page" leaves almost everything to the AI's guess. A better prompt describes what happens.
Add a Settings page reachable from the user menu. It shows the logged-in user's display name and email. The display name can be edited and saved. Email is read only. After saving, show a short success message. If saving fails, show the error message and keep the user's input in the field.
Notice what is in there: where it lives, what it shows, what can change, what happens on success and what happens on failure. Failure cases are the part people leave out most, and they are where AI builds tend to be weakest.
Rule 4: Be explicit about data and permissions
For anything that touches the database, say:
- Which table the data goes in, and what the columns are.
- Who owns each row.
- Who can read, create, edit and delete it.
For example:
Create a projects table with id, user_id, name, status and created_at. Each project belongs to the user who created it. Enable row level security. Users can only read, create, update and delete their own projects, using auth.uid() to match user_id. Do not use the service role key in any front-end code.
If you do not say this, the AI may write loose rules to make things work quickly. You will not notice until a user sees someone else's data.
Rule 5: Tell it what not to touch
AI builders love to "improve" things you did not ask about. Add guardrails:
- "Only change the Settings page and its related component. Do not change the layout, navigation or styles elsewhere."
- "Keep the existing database schema. Do not rename columns."
- "Do not add new libraries unless you ask me first."
This one habit stops a lot of surprise regressions.
Rule 6: Give examples
When words are fuzzy, examples are clear. If you want a certain format, show it.
- "Display dates like Oct 3, 2026."
- "Status badges: Draft is gray, Active is green, Archived is outlined."
- "Here is a sample row of data the table should handle: ..."
For visual design, a screenshot of a layout you like (that you have the right to reference) often works better than a paragraph of description.
Rule 7: Ask it to explain before it changes
For anything bigger than a small tweak, I ask first:
Before making changes, explain which files you will change and what you will do in each. Wait for my approval.
Reading the AI's plan shows you right away if it misunderstood. Correcting a plan is cheap. Correcting a dozen changed files is not.
Rule 8: Debug with evidence, not frustration
"It's still broken, fix it" is the least useful prompt you can send. The AI has no new information, so it guesses, and each guess can make things worse.
Give it evidence:
- What you did: "I clicked Save on the Settings page."
- What you expected: "The name should update and show a success message."
- What happened: "Nothing happened. No message."
- The error: paste the exact message from the browser console or the Supabase logs.
Then ask: "What are the likely causes? Check each one before changing code." That pushes it to investigate instead of guess.
When to stop and roll back
If you have tried three fixes on the same problem and it is getting worse, stop. Roll back to the last working version. Rethink the prompt, break the feature into smaller pieces and try again. Pushing forward through a broken state almost always costs more time than restarting the step.
Rule 9: Keep a project knowledge file
Most builders let you store project instructions or knowledge that gets included with every prompt. Use it for things that should always be true:
- What the app does and who it is for.
- Your tech stack and key services.
- Design rules: fonts, colors, spacing, tone of copy.
- Security rules: RLS on every table, no secrets in the front end.
- Coding preferences: reuse existing components, keep files small.
Update it when you make a decision. It keeps the AI consistent as the project grows.
Rule 10: Review like an editor
After each change, test it like a user who wants to break things:
- Try empty inputs and very long inputs.
- Try it logged out.
- Try it as a second user.
- Try it on your phone.
- Refresh the page halfway through.
Then tell the AI exactly what failed. This loop of small prompt, test, specific feedback is the core of building with AI.
A prompt template you can copy
Goal: [one sentence on what this feature does for the user]
Where: [page or component]
Behavior:
- [what the user sees]
- [what they can do]
- [what happens on success]
- [what happens on error or empty state]
Data: [tables, columns, owner, permissions]
Do not change: [areas to leave alone]
Before coding: explain your plan and wait for approval.It feels slower at first. It is faster by the end of the week.
We practice this live in our cohorts, with each builder prompting their own app.
What would have made it better?