How to Prompt AI for Coding (From Someone Who Ships)

How to prompt AI for coding comes down to four moves, and not one of them is a magic phrase. Give the agent context before you give it a task. Hand it one narrow job instead of a wish. Spell out the constraints it would otherwise ignore. Then make it prove the work before you trust a line of it. That's the core of a good coding prompt. A good prompt doesn't make the model smarter. It makes the model's mistakes cheaper to catch, which turns out to be the thing that actually matters when you're shipping.

I do this most days. I build and run real products with Cursor and Claude Code, an AI creative studio called Apatero and a tool directory called Tool Index among them, and a lot of my week is spent writing prompts that either save me an hour or cost me one. If the whole idea of talking to your editor still feels fuzzy, I wrote a plainer piece on what vibe coding actually is that's a gentler on-ramp than this one. This piece is the hands-on version. How you word the thing.

The Search Results Are Mostly Templates

I looked at what ranks for this before I wrote a word, same as always. Two kinds of page, over and over.

Half of them are copy-paste prompt dumps. "50 best coding prompts," "35+ prompts every developer needs," grab-and-go lists you're meant to paste and pray. The other half are prompt-engineering playbooks that tell you to be specific and give context and use few-shot examples. Which is all true, honestly. The playbooks aren't wrong. They just stop at the exact point where it stops being theory, which is the moment the agent hands you a confident diff full of a method that doesn't exist.

So I'm going to skip the template list and spend the whole time on the part they skip.

Context First, Because the Agent Can't See What You Can

The single biggest thing you can do is stop assuming the agent knows your project. It doesn't. It knows what's in front of it and nothing else.

Anthropic describes Claude Code as an agentic tool that "reads your codebase, edits files, runs commands, and integrates with your development tools," and that reading-your-codebase part is doing heavy lifting. When the agent can see how your app already handles auth, or which HTTP client you standardized on, or that you never use the ORM's raw queries, it stops guessing. When it can't, it invents something plausible, because inventing something plausible is exactly what a language model is built to do.

I keep a context file in each project that the tool reads at the start of every session. Conventions, the stack, the one library I've committed to, the things I never want it to touch. It's boring to write and it pays for itself in about a day. Half of the invented-API problem, the calls to functions that were never real, quietly disappeared for me the moment the agent could actually see how the rest of the code does the thing. Not all of it. Most of it.

The Anatomy of a Coding Prompt That Works

Here's the part no ranking page lays out. A coding prompt has parts, and each part exists to kill a specific way the agent fails. Not "be specific" in the abstract. This specific clause stops this specific disaster.

Read that Proof row twice. Most of the advice out there ends at "write a good prompt and the agent does the rest," and the rest is where it quietly breaks things. A prompt that ends with make it prove the change is a different animal from one that just asks for the change.

A Bad Prompt and a Good One, Side by Side

Let me show it on something real, because abstract advice about specificity is easy to nod at and hard to use.

The lazy version looks like this. "Add rate limiting to my API." The agent will do something. It'll pull in a rate-limiting library you don't have, wire it into a middleware layer you don't use, and hand you back a diff that touches five files and imports a package that isn't in your lockfile. It ran. It looks great. It's also wrong in three ways you now have to go find.

Here's roughly what I'd actually send instead.

Add rate limiting to the POST /api/submit route.

Context: this is a SvelteKit app. We already use the `hooks.server.ts`
middleware pattern, and there's a Redis client exported from
`src/lib/server/redis.ts`. Look at how `src/lib/server/session.ts`
uses it before you write anything.

Constraints: use the existing Redis client, do not add any new
dependencies, and do not touch any files outside the submit route
and hooks. Limit to 10 requests per minute per IP.

When you're done, show me the diff and tell me exactly which files
you changed. Do not commit.

Same task. Wildly different odds. The second one names the file, points at an existing pattern to copy, bans new dependencies, fences off the blast radius, and ends by making the agent report back instead of running off. It took me maybe forty extra seconds to write. That forty seconds is the whole skill, pretty much, and it's the part the copy-paste lists can't give you because they don't know your codebase.

Show It the Failing Case

This is the move I almost never see written down, and it's the one that changed how much I trust these tools.

When something's broken, don't describe the bug. Show it. Paste the actual error message, the failing test, the stack trace, the wrong output next to the output you wanted. The agent is genuinely good at reading an error and working backward from it, and genuinely bad at guessing what you meant by "it's not working." A vague bug report gets you a vague fix, and then you're two prompts deep in a hole.

And here's the thing to watch for, because it burned me and it'll burn you. I once had an agent "fix" a failing test by deleting the assertion that was catching the bug. Green checkmark. Test passing. Bug still sitting right there, now with less coverage than before I asked. That's not a rare glitch, that's a whole category. So the fix in the prompt is to close the escape hatch. Tell it the test has to pass without changing what the test checks. Tell it to show you the assertion it kept. Make the proof harder to fake than the work.

The looping happens on the diff, not on the wish. You send the failing case, it sends a change, you read the change, you send it the next failing case. Round and round until the thing is actually right, not until the checkmark turns green. If you want the deeper version of how these tools work under the hood and where they fall over, I pulled that apart in how AI coding agents work.

Constraints Are the Part Everyone Skips

Constraints feel like extra typing until the first time one saves your afternoon. Then you never write a prompt without them again.

A few I reach for constantly. Pin the version, because the agent will happily write for a library major-version that came out after its training and confidently mix it with the one you actually have. Ban new dependencies unless you've said otherwise, because the easiest way for an agent to "solve" a problem is to import a whole package for a thing you could do in four lines. Fence the files. "Don't touch anything outside these two paths" stops the refactor you never asked for. And the underrated one, tell it to stop and ask before doing anything destructive, before deleting a migration, dropping a column, rewriting a working function it decided was "related."

I run agents with a hard personal rule that they don't commit or push until I've read the diff. Learned that the boring way, early on, watching a one-line config change balloon into a three-file refactor where one of the three files quietly broke something that had worked fine the day before. The constraint didn't make the agent dumber. It kept the agent inside a box small enough that I could actually check its work.

A Code Review Prompt You Can Steal

People search for a code review prompt specifically, so here's one that earns its keep. I paste this at a chunk of code, mine or the agent's, when I want a real second read.

Review this code like a skeptical senior engineer. For each issue,
tell me the severity, the exact line, and why it matters. Focus on:
bugs and edge cases first, then security, then anything that will
be painful to maintain in six months. Do not comment on style.
If you're not sure something's a bug, say so instead of guessing.

The "say so instead of guessing" line matters more than it looks. Left to its own devices an agent will manufacture confident feedback about nothing, because it never wants to come back empty-handed. Giving it permission to be unsure gets you honest answers.

Answering the Questions People Actually Search

A few things come up around this topic constantly, so here are straight answers.

Is AI writing 90 percent of code? That number gets repeated like somebody measured it, and as far as I can tell nobody did. It started as a prediction from people who sell the future, and a prediction is not a stat. In my own work the agent probably types eighty or ninety percent of the keystrokes on a good day, which sounds like the same thing and isn't. Keystrokes aren't decisions. What to build, whether the result is any good, when it's actually done, when to throw the whole attempt out and start over, all of that is still me, and it's the part that takes the real time.

How do I use AI for coding without it going sideways? The loop above is the whole answer. Context, one small task, hard constraints, show the failing case, read the diff, go again. Treat the agent like a fast junior dev who never gets tired and never pushes back, because functionally that's what you've got.

How should a beginner prompt AI for coding? Start smaller than feels worth it. Ask for one function, one component, one bug fix, and read every line it gives you back. You'll learn where the agent lies faster by watching it lie on a tiny task than by turning it loose on your whole app and drowning.

The Honest Ending

Prompting well is worth learning, and it also won't do the thing the hype promises. It doesn't build the business for you. My first sale on Tool Index was a grand total of $29.99, and it showed up roughly two months after I launched the thing, agent-written plumbing and all. Across every product I've shipped, the lifetime total is somewhere around ten grand, cumulative, not monthly, and I'll take it, but nobody's retiring on prompt craft alone.

What good prompts buy you is smaller and more real. Fewer afternoons lost to a diff you didn't read. Fewer invented methods in a commit. A junior teammate who never sleeps and saves you an hour here and there, as long as you keep a hand on the wheel. The typing it'll handle fine. What it won't do is decide which of those changes is actually worth shipping, and no clever phrasing hands that part off, so you might as well get good at the deciding.