Most AI coding prompts produce garbage. Not because the AI is bad, but because the prompts are bad. "Build me a login page" gives you a generic form with no connection to your project. "Add authentication" gives you a tutorial-grade implementation that doesn't account for your database, your framework version, or your existing user model.

The difference between a prompt that produces throwaway code and a prompt that ships a feature comes down to four elements: context, task, constraints, and output format. Miss any one of them and you're rolling dice.

Why Most Prompts Fail


When you type "build me a dashboard" into an AI chat, the model has to make hundreds of assumptions. What framework? What data? What layout? What authentication? What database? What styling approach? Every assumption is a coin flip, and you only need a few wrong ones before the output is useless.

The fix isn't longer prompts — it's structured prompts. A good prompt is short but specific. It tells the AI exactly what exists, exactly what you want, and exactly what constraints to respect. Here are ten that I use constantly.

The 10 Prompts


1. The Feature Builder

"I need to add [feature]. My app uses [tech stack]. The relevant existing code is in [file paths]. The feature should [specific behavior]. Don't create new utility files — use what exists. Match the existing code style."

This works because it eliminates the most common AI failure mode: creating new abstractions instead of building on what you have. The constraint "don't create new utility files" alone prevents half of all AI code from being thrown away.

2. The Bug Hunter

"There's a bug where [exact symptom]. It happens when [steps to reproduce]. The relevant code is in [file]. I expect [correct behavior] but instead get [actual behavior]. Find the root cause and fix it. Don't refactor surrounding code."

The key constraint: "don't refactor surrounding code." Without this, the AI will rewrite your entire function to fix a one-line bug. You want a surgical fix, not a rewrite.

3. The Refactor Without Breaking Things

"Refactor [specific file or function] to [goal: improve readability / reduce duplication / extract logic]. Keep the public API identical — nothing that imports this should need to change. Show me what changes and confirm no behavior changes."

Refactoring is where AI shines, but only if you constrain the blast radius. "Keep the public API identical" is the guardrail that prevents the refactor from cascading through your entire codebase.

4. The API Route

"Create a [method] API route at [path]. It should [behavior]. Auth: [auth requirement]. Input validation: [what to validate]. Database: use the existing [model/table] via [ORM]. Return [response shape]. Handle errors with [your error pattern]. Follow the pattern in [existing route file] exactly."

API routes have the most potential for inconsistency. "Follow the pattern in [existing route file] exactly" is the sentence that keeps your codebase coherent. The AI will mirror your error handling, your response format, your middleware pattern — everything.

5. The Database Schema

"Add a new [table/model] for [purpose]. Fields: [list fields with types]. Relations: [describe relationships to existing tables]. Add an index on [field] for [query pattern]. Use the same migration tool and conventions as the existing schema in [schema file path]."

Database changes are high-stakes. Specifying field types, relations, and indexes up front prevents the AI from making schema decisions that you'll have to undo later. Always reference your existing schema file so naming conventions stay consistent.

6. The Auth Flow

"Implement [auth feature: login / signup / password reset / OAuth]. Use [auth library/approach]. Store sessions in [storage]. Protect these routes: [list]. Redirect unauthenticated users to [path]. Match the form styling in [existing component]. Don't add any auth library that isn't already in package.json."

Auth is where AI most wants to install new dependencies. The constraint "don't add any auth library that isn't already in package.json" forces it to work within your existing setup instead of pulling in a different auth framework.

7. The UI Component

"Create a [component name] component. Props: [list props with types]. It should render [description]. Use the same styling approach as [existing component]. No new CSS files or style libraries. Keep it under 80 lines. Make it accessible (proper aria labels, keyboard navigation)."

The line count constraint ("under 80 lines") is surprisingly effective. It prevents the AI from creating a 300-line monolith with every possible feature baked in. You can always add complexity later.

8. The Error Handler

"Add error handling to [file/function]. Catch [specific error types]. Log errors to [logging destination]. Return user-friendly messages (never expose stack traces or internal details). Follow the error handling pattern already used in [reference file]."

The critical constraint here is "never expose stack traces or internal details." AI-generated error handling often returns raw error messages to the client, which is a security issue. This prompt prevents that.

9. The Test Writer

"Write tests for [file/function]. Test these scenarios: [list specific cases including edge cases]. Use [test framework] with the same setup as existing tests in [test directory]. Mock [specific dependencies] but use real [other dependencies]. Each test should be independent."

Listing specific test scenarios is essential. Without them, the AI writes tests for the happy path and calls it done. You need to specify the edge cases — empty inputs, invalid data, auth failures, race conditions — because those are the tests that actually catch bugs.

10. The Closing Handoff

"Update STACK.md with everything we built this session. Include: what's now working, what files were changed or created, any new issues or bugs discovered, and what should be tackled in the next session. Keep the format consistent with the existing STACK.md structure."

This is the most important prompt in the list, and it's not even a coding prompt. It's the bridge between today's session and tomorrow's. Running this at the end of every session means your next session starts with full context instead of a blank slate. It takes 30 seconds and saves 20 minutes.

Adapting These to Your Stack


Every prompt above has the same skeleton: context (what exists), task (what to build), constraints (what not to do), and reference (what to match). Fill in your specific tech stack, file paths, and conventions and these prompts work for any project.

The constraints are the secret weapon. Without them, AI code is generic. With them, AI code fits your project like it was written by someone who's been on the team for months. Every constraint you add is an assumption the AI doesn't have to make — and assumptions are where bugs come from.

The One Prompt to Rule Them All


If you take nothing else from this article, take prompt #10 — the closing handoff. It's the compound interest of vibe coding. Every time you run it, your next session gets slightly better, your context gets slightly richer, and your AI gets slightly more accurate. Over weeks and months, the gap between "AI-generated code" and "code that fits my project perfectly" closes to almost nothing.

Ship the feature. Close with the handoff. Repeat. That's the whole system.