Prompts for AI Coding: How to Get Apps That Actually Run

Good prompts for AI coding say what the app does, who uses it, what must not break, and how to tell when a step is done. Then you build in small steps and check each one before the next. Most broken apps come from vague, oversized prompts, not from a bad model.

Below is a structure you can reuse, a prompt to paste, and the habits that keep a project from falling apart around prompt twenty.

Why big, vague prompts break apps

"Build me a habit tracker with accounts, payments and a dashboard" gives the AI a hundred decisions to make for you. It will make them all, quietly, and you'll find out which ones were wrong later.

Lovable's docs make this point from the other side: its guidance is one change per prompt, verify in the preview, then move on. They also say big prompts turn into changes you didn't ask for and can't untangle. That matches my experience, and it applies to every tool, not just Lovable.

There's a second reason. Claude Code's docs say the context window fills up fast and performance degrades as it fills. A long, rambling session gets worse over time. Short, focused prompts help with that too.

The five parts of a prompt that works

1. Goal. One sentence on what you're building or changing, written as what a user can do. "A user can add a habit and tick it off each day" beats "habit tracker."
2. Stack and constraints. Name the framework, database and styling approach. If you don't care, say "pick the simplest option and tell me what you picked."
3. Scope. What to touch and what to leave alone. This is the line that stops a small request from rewriting working code.
4. Real content. Actual field names, labels and sample data. Lovable's docs note that placeholder text like "lorem ipsum" gives the model nothing to respond to, and the same goes for data models.
5. A check. How the AI (or you) can tell it worked. More on this below.

A useful trick from Lovable's guide is to tell a story instead of writing a spec. A story covers who is on the screen, what they're trying to do and how it should feel. A bullet list usually leaves those out.

A first-build prompt you can paste

Use this to start a project. Replace the bracketed parts.

I'm building [one-sentence product] for [who it's for].

The one key thing a user should be able to do: [core action].

Stack: [e.g. Next.js, Postgres, Tailwind]. If you'd choose differently, tell me why before building.

Build ONLY this first slice:
- [Screen or feature 1, with real field names]
- [Screen or feature 2]

Do not build yet: auth, payments, admin pages, settings.

Done means:
- The app starts with no errors
- I can [do the core action] end to end with sample data
- You tell me the exact command to run it

Before writing code, ask me any questions you need answered. Then give me a short plan.

The "do not build yet" list does more work than it looks like. Without it, the AI tends to add auth and an admin panel nobody asked for.

Make it ask first, plan second, code third

Letting the AI jump straight to code can produce code that solves the wrong problem. Claude Code's docs recommend exploring first, then planning, then coding. Lovable's library suggests ending larger prompts with a line like "Ask me any questions you need before building," or using plan mode first.

It takes a couple of minutes and it often surfaces choices you hadn't thought about: how users sign in, what happens when a list is empty, where data lives. Answer them in your own words. Those answers become the spec.

Give the AI a way to check its own work

"Make it work" isn't testable. "Run the tests and keep going until they pass" is. Claude Code's docs list that kind of instruction (run the auth tests after, and keep going until they pass) as one way to get the agent to verify itself.

You don't need a full test suite on day one. Cheap checks that help:

• "Start the dev server and tell me if there are any console or terminal errors."
• "Write one test for the happy path and run it."
• "List what you changed and what you did not touch."
• For UI work, paste a screenshot of what you see and say what's wrong.

If you can't tell whether it worked, the AI can't either. It will tell you it did.

Weak prompts vs. better prompts

Put the repeat stuff in a rules file

If you keep typing "use TypeScript" or "don't add new dependencies," stop. Every major tool has a place for standing instructions.

• Claude Code reads a CLAUDE.md file. The docs suggest including commands, code style and workflow rules, things Claude can't infer from the code alone.
• Cursor uses project rules in .cursor/rules/. Per Cursor's rules docs, they must use the .mdc extension, and a plain .md file in that folder is ignored. Cursor also supports a plain AGENTS.md in the project root for simpler cases.
• Lovable has project knowledge, where its prompt library suggests saving decisions that should persist, like design direction and product context.

Keep these short. A rules file is a prompt that gets read every time, so treat it like one. If the AI ignores a rule, rewrite it more plainly rather than shouting. Claude Code's docs say current models follow a plainly worded line, and piling on ALL CAPS mostly makes them over-apply it.

A starter rules file might look like this:

- Use TypeScript. No new dependencies without asking.
- Keep components small, one job each.
- After any change, run the dev server and report errors.
- Never edit files outside the feature I name.
- Don't commit secrets. Use environment variables.

When something breaks

Resist "it's broken, fix it." Give it the evidence:

1. Paste the exact error message or describe what you did and what happened.
2. Say what you expected instead.
3. Ask for the cause first: "Explain why this happens before changing code."
4. Then approve a narrow fix.

If the same fix fails twice, don't try a third time in the same thread. Start a fresh session, paste a short summary of the problem, and name the file. A long failed attempt in context often makes the next attempt worse.

A quick checklist before you hit enter

• Does the prompt describe one feature or change?
• Did I say what not to touch?
• Did I use real names and sample data?
• Is there a way to confirm it worked?
• Is my last working version saved (git commit or a restore point)?

That last one isn't about prompts, but it saves more projects than any wording trick.

FAQ

How long should a prompt for AI coding be?

As long as it needs to be to cover the goal, scope and a check, and no longer. For a small change that's two or three sentences. For a first build, the template above is about right. If your prompt describes several features, split it into several prompts.

Do I need different prompts for Cursor, Claude Code and Lovable?

The core habits carry over: be specific, keep scope tight, build in small steps, verify each one. What changes is where you put standing instructions (CLAUDE.md, .cursor/rules/, or project knowledge) and what the tool can do for you, like running tests or previewing the app.

Can I ask the AI to write my prompts for me?

Yes, and it works well for a first draft. Describe your idea, then ask it to turn that into a short build plan and a list of questions for you. Read the result and edit it before you run it. You're still the one who knows what the app is supposed to do.

Cover photo: freestocks on Unsplash