12 prompts that get working code.

The best prompts for coding agents have four parts: the goal, the context the agent cannot guess, the limits it must respect, and a check that proves the work is done. Leave one out and the agent fills the gap with a guess. That is where “almost right” code comes from.

Below are twelve prompts built that way, from the first plan to the commit message. Copy one, fill in the brackets and send it to any agent.

01What makes a good prompt for a coding agent?

A coding agent can read your files, so you rarely need to paste code. It needs what the code cannot tell it: what you want, what to leave alone, and how to know it is finished.

The check matters most. Without something to run, an agent stops when the work merely looks done. With a test, a build or a script, it keeps going until the check passes.

02Prompts to plan before you code

1. Plan first

Before writing any code, read the relevant files and propose a plan for: [task].
1. The files you will change or create, and why.
2. The steps, smallest and safest first.
3. Questions about anything you are unsure of.
4. The tests or commands that will prove it works.
Do not edit any files until I approve the plan.

When to use it. Any change that spans several files, or when you are unsure of the approach. If you can describe the whole diff in one sentence, skip the plan.

Why it works. You catch a wrong approach while it is one paragraph long, not four hundred lines. For a bigger feature, turning that plan into a written spec first is worth it; see our guide to spec-driven development.

2. Explain a codebase

Without changing anything, explain this codebase to a new teammate:
1. What it does, and how a request flows from entry point to storage.
2. The 5 to 10 files that matter most, one line each.
3. The exact commands to install, run, test and lint it.
4. Anything surprising or risky.
Cite a file path for every claim. Say "not sure" rather than guess.

When to use it. Your first session in an unfamiliar repository.

Why it works. File paths make every claim checkable in seconds. Permission to say “not sure” gives the model an alternative to inventing an answer.

03Prompts to build with tests

3. Tests first

We are doing test-driven development for: [behavior].
1. Write the tests only: the normal case, these edge cases [list], and invalid input. No implementation yet.
2. Run them and show me that they fail, and why.
Then stop, so I can review the tests before you write any code.

When to use it. New functions with clear inputs and outputs, and bug fixes.

Why it works. The tests become a spec you can read in a minute, and you fix the spec before any code depends on it. Our guide to test-driven development with AI walks through a full example.

4. Fix a failing test

This test fails: [test name, or paste the output].
Find the root cause and fix the code, not the test. Do not change, skip or delete any test. If you think the test is wrong, stop and tell me why.
When you are done, run the full test suite and paste the result.

When to use it. A red build, or a change that broke something that used to pass.

Why it works. Editing the test is the easiest way to turn it green, so the prompt forbids it by name. The full suite catches a fix that breaks something next door.

5. Refactor safely

Refactor [file or function] to [goal, such as removing duplicated logic].
1. Behavior must not change: the existing tests pass before and after, unedited.
2. If the code has few tests, first add tests that record what it does today.
3. Work in small steps and run the tests after each one.
4. No new dependencies, no renamed public functions, no unrelated reformatting.

When to use it. Cleaning up before a feature, or code nobody wants to touch. Our guide to refactoring legacy code with AI has a full worked example.

Why it works. Tests prove the behavior stayed put. Rule four keeps the diff small enough to review.

04Prompts to review and harden a change

6. Review a diff against the request

Review the diff between [branch] and main against this request: [paste the task or plan].
Report, most severe first:
1. Requirements that are missing or half done.
2. Changes I did not ask for.
3. Bugs, each with the file, the line and an input that triggers it.
Only report what affects correctness or the request. If the change is sound, say so.

When to use it. Before you merge, ideally in a fresh session or with a different model.

Why it works. A fresh session has no stake in the code it judges. The last line matters too: a reviewer told to find problems will report some even when the work is sound. For the full method, see how to review AI-written code.

7. Security pass

Review [files, or the current diff] for security. Assume every input is hostile.
Check for injection (SQL, shell, HTML), missing authorization checks, secrets in code or logs, unsafe file paths, and unknown or unmaintained new dependencies.
For each finding: the file and line, how an attacker would use it, and the smallest fix. Change no code yet.

When to use it. Anything touching login, payments, uploads or user input, and any new package.

Why it works. A named list of threats beats “make it secure”, and asking how an attacker would use each finding filters out vague warnings.

8. Find what is slow

[What is slow, and by how much. For example: the orders page takes 4 seconds with 500 rows.]
Measure first: add timing or run a profiler, and show me where the time goes.
Then propose up to three fixes, ranked by expected gain and by risk. Change nothing until we agree on the cause.

When to use it. A slowdown you can measure, not a hunch.

Why it works. Agents tend to guess at speed problems and add caching everywhere. Measuring first ties the fix to evidence.

05Prompts for migrations and docs

9. Migrate to a new version

Migrate [such as library X from version 2 to 3] across the codebase.
1. Read the official migration guide at [URL]. List the breaking changes that affect us, with file paths.
2. Migrate one module, run its tests and show me the diff.
3. Do the rest in batches, testing after each.
Only use APIs that appear in the guide or in the installed package.

When to use it. Version upgrades, framework switches and deprecated APIs.

Why it works. The model’s training data may predate the version you are moving to. The real guide replaces its memory, and one pilot module surfaces surprises early.

10. Write the docs

Document [module or feature] for [reader, such as a new teammate], based only on the code as it is now.
Include what it does, one runnable example, the options, and the errors it can return.
Mark anything you could not confirm from the code with "TODO: confirm". Stay under [N] words.

When to use it. After a feature lands, or when teammates keep asking the same question.

Why it works. The TODO markers stop confident fiction. The runnable example is the part readers copy, so it is worth testing.

06Prompts for bugs and the finish line

11. Debug from the logs

Here is the error and the logs around it: [paste]. I expected: [behavior].
Before you change any code:
1. List the three likeliest causes, with evidence for each from the logs or code.
2. For each cause, name a command, log line or test that would confirm or rule it out.
Then run those checks, and fix only the cause the evidence supports.

When to use it. A crash, a stack trace, or a job that fails only some of the time.

Why it works. It stops the shotgun fix, where the agent changes five things and hopes. Our step-by-step method for debugging with AI builds on this prompt.

12. Write the commit message

Write a commit message for the staged changes. Read them with git diff --staged first.
Use the Conventional Commits format: a type such as feat, fix or refactor, a colon, then a short summary.
In the body, explain why the change was made and what a reviewer should check. Flag any breaking change. Describe only what is in the diff.

When to use it. Every commit.

Why it works. Reading the diff first stops the agent from describing what it meant to do instead of what it did. The “why” is the one thing a future reader cannot recover from the code.

07Keep your best prompts close

A prompt you retype is a prompt you will shorten, and the short version drops the limits and the check. Save the ones that work as snippets or saved commands.

Rules for every task belong in your project’s instruction file, not in each prompt: the test command, the lint command, “never edit tests to make them pass”. Our guide to AGENTS.md shows what to put there.

08FAQ

Next, put these prompts into a daily rhythm with our AI pair programming workflow, or read how context engineering shapes what the agent sees.