How to prompt an AI coding tool well: the method that changes everything

“Build me a to-do list” and “write an addTask function that adds a task to an array, with a title and a date, and write three tests to check it works” don’t produce the same result, with the same AI, on the same project. The difference isn’t luck; it’s method. Here’s the one Anthropic and GitHub each document, independently, in almost the same words.

Give context, not just a request

Claude’s official documentation offers a useful image: treat the AI like “a brilliant but new employee who lacks context on your norms and workflows.” The more precisely you explain what you want, the better the result. It even suggests a simple test for your own prompt: show it to a colleague with almost no context on the task. If they’d be confused, the AI will be too.

In practice, that means stating the expected output format, the constraints, and giving examples where you can. GitHub Copilot’s documentation recommends the same logic from the other direction: start with a general description of the goal, then add the precise requirements one by one, and avoid vague terms like “that” or “this thing” when several elements could match.

Before: “improve the signup form” After: “the signup form should reject a password under 8 characters and show the error message under the relevant field, not in a popup”

In both cases, ask yourself the same question before you hit send: if you gave this exact prompt to a classmate who’s never seen your project, would they know precisely what to do? If the answer is no, the AI will trip over the same blind spots they would.

Give the AI a role, and say why

Claude’s prompt engineering documentation offers another simple trick: give the AI a role at the start of the conversation. A single sentence already changes the outcome, for example “you are a patient coding tutor: whenever you propose code, explain in two sentences why you made that choice rather than another.” For a student who’s learning at the same time as building, that one setup line turns the AI into something that explains, not just something that produces.

The same documentation adds a principle that pays off every day: explain the why, not just the what. Its own example makes the point well. Instead of writing “never use ellipses,” it’s more effective to write “your response will be read aloud by a text-to-speech engine, so never use ellipses, since the engine won’t know how to pronounce them.” An AI coding tool reacts the same way: if you explain that a given file should never be touched because it’s auto-generated, or that a certain library should be avoided because it’s abandoned, the AI generalizes that reason to cases you didn’t think to spell out, instead of just obeying once.

Break a complex task into small ones

GitHub Copilot’s documentation is direct about this: “if you want Copilot to complete a complex or large task, break the task into multiple simple, small tasks.” One example it gives: instead of asking for “generate a word search puzzle” in one go, ask first for the letter grid, then for finding the words, then for combining the two.

Claude Code’s documentation shows the same idea with a before/after table: instead of “add tests for foo.py,” be specific: “write a test for foo.py covering the edge case where the user is logged out, avoid mocks.” The level of detail changes everything: the first version leaves the AI guessing at what actually matters; the second leaves nothing to chance.

Ask for a plan before any code

A common mistake is asking directly for code on a project you don’t yet know well yourself. The result can look correct without solving the right problem. Claude Code’s documentation recommends a four-step flow: explore (read the project, ask questions, without changing anything), plan (ask for a detailed plan), implement (execute the approved plan), commit (save the result with a clear message).

A prompt that follows this flow:

Explore the src/auth folder and explain how login
currently works.

then, once you’ve read the answer:

I want to add email login. What files need to change?
Propose a plan before touching any code.

Only after reading and approving that plan do you ask for the implementation.

Demand a way to verify the result

An AI coding tool stops when the result “looks” done. Without anything to check that objectively, that impression is the only signal available, and it’s sometimes wrong. Claude Code’s documentation advises always giving it a way to verify: a test, a screenshot to compare, a precise expected result.

Before: “implement a function that validates email addresses” After: “write a validateEmail function. Test cases: user@example.com should be true, invalid should be false, user@.com should be false. Run the tests after implementing.”

The second version gives the AI, and you, a clear criterion for knowing whether it’s actually done, instead of just an impression.

Review, and iterate without losing patience

No official guide claims an AI coding tool is always right. GitHub Copilot’s documentation says so plainly: “while Copilot is powerful, it can make mistakes, so you should always validate the code it suggests and understand suggested code before you implement it.” And if the result isn’t right on the first try, the same documentation simply recommends rephrasing and trying again, rather than pushing harder on a prompt that already failed.

Claude Code’s documentation goes a step further on this exact point: if you’ve corrected the same mistake more than twice in one conversation, the context is probably cluttered with failed attempts. It’s better to clear it (/clear) and start over with a more precise prompt, one that includes what you just learned, than to keep insisting indefinitely. None of this is a sign you’re bad at this; it’s simply what working with these tools looks like in practice, even for the people building them.

Key takeaways

• Give context as if explaining the task to someone encountering it for the first time: expected format, constraints, examples.
• Break a complex task into several simple requests instead of asking for everything at once.
• Ask for a plan before any code as soon as the task touches several files or a project you don’t yet know well.
• Always give a way to objectively verify the result: a test, a precise case, a reference screenshot.
• Review what the AI proposes before using it, and if it’s still not working after two corrections, start over with a more precise prompt instead of insisting.

Ready-to-copy prompt templates for each of these steps are available in the prompts-vibe-coding skill.