Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersCoding prompts: 14 copyable prompts for debugging, refactoring, tests and more
The best coding prompts state the goal, point to the code, set limits and say how to check the result. Below are 14 you can paste into any AI coding tool: four for debugging, four for changing code, three for tests and review, and three for explaining and documenting. Each has a template with placeholders, a note on when to use it, and a follow-up for when the first answer is not enough.
What makes a good coding prompt?
A coding prompt is an instruction to an AI model that asks it to read, write or change code. The wording matters less than the information in it. A model cannot see your screen, your terminal or your intent. It sees what you give it, so most weak answers trace back to missing information, not clumsy phrasing.
Every prompt below follows the same anatomy. Learn it once and you can write your own for any task, which is the real subject of prompt engineering for coding.
| Part | What to write | Example | What goes wrong without it |
|---|---|---|---|
| Goal | The outcome, in one sentence | Make the invoice total ignore refunded lines | The model solves a different problem |
| Context | Files, versions, the error, what you already tried | src/billing/total.ts, Node 22, TypeScript, test output below | It guesses your stack and invents details |
| Constraints | What may and may not change | No new dependencies; keep the public function signature | Rewrites, renames and new packages |
| Output format | What you want back, and in what shape | A unified diff, then a two-line explanation | Long essays, or code with the changes hidden in it |
| Check | How you will know it worked | pnpm test billing passes, with a new test for a refunded line | The model says it works; you find out later it does not |
These prompts are tool-agnostic and work in a chat window, an editor assistant or a coding agent. If you use one agent daily, there are sets written for it: Claude Code prompts, Cursor prompts and, for whole-app starting points, vibe coding prompts. The AI coding prompt builder assembles a first prompt for a new app.
Which prompts help with debugging?
Debugging prompts work when they include the evidence: the exact error, the input that triggers it and what you expected instead. Ask the model to reason before it edits, because an instant fix to a misread problem makes things worse.
01 Diagnose an error from a stack trace
Turns an error message and the code around it into a plain-language cause and a ranked list of fixes.
- Use when
- You have an error message and do not know what it means.
- Give it
- The full error, the file it points to, the relevant 20 to 50 lines.
- Watch for
- A fix that silences the error instead of removing the cause.
I get this error: <paste the full error and stack trace> Relevant code (<file path>): <paste the function and its caller> Environment: <language and version, framework and version>. Do this in order: 1. Explain in plain words what the error means. 2. Say which line most likely causes it and why. 3. Give the smallest fix, as a diff. 4. Tell me how to check the fix worked. Do not change anything unrelated to this error.
That did not fix it. New output: <paste the new error or behavior> List three other possible causes, ranked by likelihood, and for each give one quick check that would confirm or rule it out. Do not edit code until I report the results.
02 Rank hypotheses before touching code
Forces the model to propose causes and tests for them, so you debug like a scientist instead of guessing.
- Use when
- The bug is intermittent, or the cause is not visible in one file.
- Give it
- What happens, what should happen, when it started, what changed recently.
- Watch for
- Confident answers with no way to test them.
Bug: <what happens>. Expected: <what should happen>. It started after <change or date>. It happens <always / sometimes, when ...>. Do not propose a fix yet. Give me: 1. Five possible causes, ranked by likelihood. 2. For each, one cheap test (a log line, a query, a command) that proves or disproves it. 3. The order I should run the tests in. Relevant files: <paths>.
Add temporary logging for the top two hypotheses only. Mark each added line with the comment TEMP-DEBUG so I can remove them all afterwards. Tell me what output to look for.
03 Reproduce a bug with a failing test
Converts a bug report into a test that fails now and passes when the bug is fixed.
- Use when
- You have a bug report and want proof of the fix.
- Give it
- The report, steps to reproduce, and the test framework you use.
- Watch for
- A test that fails for the wrong reason, such as a typo in the setup.
Bug report: <paste report> Write one failing test in <test framework> that reproduces it. Put it in <test file path>. Follow the style of the existing tests in that file. Rules: - Do not fix the bug yet. - Run the test and show me that it fails, and that the failure message matches the report. - Use the smallest input that triggers the bug.
Now fix the bug with the smallest change that makes the new test pass. Run the full test suite. Report any other test that changed status.
04 Find why a deploy or environment differs
Compares a working setup with a broken one to find the difference that matters.
- Use when
- It works on your machine and fails elsewhere, or worked yesterday and fails today.
- Give it
- Both outputs side by side, plus config and recent changes, with secrets replaced.
- Watch for
- Pasting real environment values. Replace them first.
Environment bugs often come from a variable, a version or a build setting rather than the code. A developer tool that diffs two environments, like the one posted on the board as "Which env var changed between the deploy that worked and the one that didn't", exists because this search is so common.
Working setup: <versions, config files, environment variable NAMES with values redacted, build command> Broken setup: <same information> Error in the broken one: <paste> List every difference between the two, ordered by how likely each is to cause this error. For the top three, say how I can confirm it. Do not suggest code changes yet.
Which prompts help with refactoring and new features?
Changing code is where models add the most unrequested work. These prompts fence the task in: what to keep, how big a step to take, and how to prove nothing else moved.
01 Refactor without changing behavior
Cleans up a function or module while keeping its behavior identical, proven by tests written first.
- Use when
- Code works but is hard to read, long or repetitive.
- Give it
- The file, the pain point, and which public names must stay.
- Watch for
- Renamed public functions and quietly changed edge-case behavior.
Refactor <function or file> for readability. The behavior must not change. Steps: 1. First write characterization tests that pin down what the code does today, including odd cases. Run them and show they pass. 2. Refactor in steps of one idea each (extract function, rename variable, remove duplication). After each step run the tests. 3. Keep public names and signatures: <list>. Do not add features, change dependencies or touch other files. Finish with a summary of what moved.
The diff is too large to review. Redo it as the three most valuable changes only. Leave the rest as a numbered list of suggestions I can approve one at a time.
02 Add a feature in small, checkable steps
Gets a plan first, then implements one step at a time, so you review a small diff after each.
- Use when
- The change spans several files or you do not know how the codebase is laid out.
- Give it
- The behavior you want, with examples, and the done-check.
- Watch for
- A plan that adds a framework or a pattern the project does not use.
Feature: <behavior, with two example inputs and the outputs you expect>. Done when: <command or manual check>. First read the code around <area> and tell me how similar features are built today. Then propose a plan of at most six steps. For each step list the files it touches and how I can check it. Follow the existing patterns. Do not write code until I say go.
Go. Implement step 1 only. Run the checks. Show me the diff summary and wait.
03 Upgrade a dependency or migrate an API
Moves code from an old library version or API to a new one with the breaking changes listed first.
- Use when
- A library released a major version, or an API you use is deprecated.
- Give it
- Old and new version numbers, the changelog or migration guide text, the files that use it.
- Watch for
- Changes based on the model's memory of the old docs. Paste the real migration notes.
Upgrade <library> from <old version> to <new version> in this project. Here are the official migration notes: <paste the notes> 1. Search the code for every use of the affected APIs and list them with file and line. 2. For each, say which breaking change applies. 3. Update one file at a time, running `<test command>` after each. 4. Stop and ask if a change would alter behavior, not just syntax. Do not upgrade any other dependency.
04 Improve performance with a measurement
Finds a slow path by measuring first, then optimizing only what the numbers point to.
- Use when
- A page, query or function is slower than it should be.
- Give it
- How you measured, the numbers and the target.
- Watch for
- Optimizing code that is not the bottleneck.
<Operation> takes <measured time> on <input size>. I want it under <target>. Before changing anything: 1. Suggest how to profile or time the steps (a command or a few timing lines). 2. Tell me what output would show the bottleneck. After I paste the numbers, propose the single change most likely to help, estimate the gain, and implement only that. Then show me how to re-measure. Do not make readability worse for gains under 10 percent.
Which prompts help with tests and code review?
Tests and review are where AI output earns your trust or loses it. The aim is to make the model look for faults. For a longer treatment of checking a diff, see AI code review.
01 Write unit tests for existing code
Produces tests for a function covering normal input, edge cases and failures, with the reason for each case.
- Use when
- Code has no tests and you need to change it safely.
- Give it
- The function, the test framework and one existing test as a style sample.
- Watch for
- Tests that repeat the implementation's logic and can never fail.
Write unit tests for <function> in <file>, using <test framework>. Match the style of this existing test: <paste a short existing test> Cover: a normal case, the smallest valid input, an empty or missing input, an invalid input, a boundary value and one realistic case from production. Name each test after the behavior it checks. Use literal expected values, not values computed by the same logic as the function. Run the tests. For each one, add a one-line comment saying what bug it would catch.
Introduce one deliberate bug in <function> at a time (off by one, wrong comparison, missing check). Show which tests fail for each. Revert every bug afterwards. Tell me which bugs no test caught and add tests for them.
02 Review a diff as a strict reviewer
Asks for ranked problems in a change, with failing examples, and bans praise.
- Use when
- Before you merge anything an AI wrote, or to second-check your own change.
- Give it
- The diff and the task the change was meant to satisfy.
- Watch for
- A reviewer in the same session as the author, which tends to defend the code.
Review this diff as a strict senior engineer. The task it should satisfy: <task>. Report, in order of severity: bugs with a failing input, missing edge cases, security problems (secrets, injection, missing authorization), and anything the task did not ask for. Quote the line for each point. No praise, no style nitpicks. If a category is clean, say what you checked. <paste diff>
03 Security pass on one route or function
Walks through a single endpoint and asks who can call it, what it trusts and what it leaks.
- Use when
- You added a route, a form handler or a file upload.
- Give it
- The handler and the code it calls.
- Watch for
- A clean bill of health on code that handles money or identity. Get a human review for those.
Audit this handler for security problems: <paste code>. Answer each question with the lines that support your answer: 1. Who can call this, and where is that enforced? 2. Which inputs come from the user, and where is each validated? 3. Can one user read or change another user's data through it? 4. Does it log, return or store anything sensitive? 5. What happens with a very large or malformed input? Then list fixes by severity. Do not rewrite the file; give the minimal change for each.
Which prompts help with understanding and documenting code?
Reading unfamiliar code is a bigger share of the job than writing it. These prompts turn a model into a guide, and they help you hand work over to the next reader.
01 Map an unfamiliar codebase
Produces a short guide to how a project is organized and where to start reading.
- Use when
- You inherit a repository or open a library to fix one thing.
- Give it
- Access to the repository (an agent) or the file tree and key files (a chat).
- Watch for
- Invented structure. Ask it to cite file paths for every claim.
I am new to this project. Read the repository and write a one-page guide: 1. What it does, in three sentences. 2. The main folders and what each holds. 3. How a request or user action flows through the code, for one example: <e.g. 'user signs up'>. Name the files in order. 4. How to run it and run the tests. 5. The three files I should read first, and why. Cite a file path for every claim. If you are unsure, say so rather than guess.
02 Explain code line by line
Walks through a block you do not understand and then checks that you do.
- Use when
- You must change code you did not write, or the AI wrote something you cannot follow.
- Give it
- The block and your level.
- Watch for
- Explanations that restate each line without saying why it exists.
Explain this code for someone who knows <language> basics but not this project. For each block say what it does, why it is needed and what would break without it. Point out anything unusual or risky. Finish with three questions to check my understanding. <paste code>
03 Write the commit message, PR description and README section
Drafts the words around a change from the diff, so the next reader knows what happened and why.
- Use when
- A change is done and the description is the last thing left.
- Give it
- The diff and the reason for the change, which the diff does not show.
- Watch for
- A description of what changed with nothing on why.
From this diff and the reason below, write: 1. A commit message: a subject under 60 characters in the imperative mood, then a short body explaining why. 2. A pull request description with sections: Problem, Change, How to test, Risks. 3. If behavior visible to users changed, two lines for the changelog. Reason for the change: <why> Do not describe changes that are not in the diff. <paste diff>
What do you do when the first answer is wrong?
Do not repeat the same prompt louder. Change one of the five parts.
- Wrong problem solved: the goal was vague. Rewrite it with an example input and the output you expect.
- Invented details: context was missing. Paste the actual error, file and version.
- Too much changed: the constraints were missing. Add "change only X" and "do not touch Y".
- Confident but unverified: the check was missing. Ask the model to run it, or to say exactly how you can.
- Going in circles: the conversation is polluted by earlier attempts. Ask for a five-line summary of the goal and what failed, and start a new session from it. Context engineering explains why.
A larger practice is to keep your best prompts in a file and reuse them. When a prompt works, save it with the placeholders in place. For project-wide habits that apply without retyping, put them in an instructions file, covered in how to write a CLAUDE.md.
Prompts work best with something real to build. The developer tools ideas on the board are small enough to try several of these prompts on, and every idea has a generated build prompt to start from. If you would rather learn than only ship, the prompts under how to code with AI are written as a tutor.
Frequently asked questions
What is a coding prompt?
A coding prompt is an instruction that asks an AI model to read, write or change code. Good ones state the goal, include the relevant code and error, set limits on what may change, specify the output format, and name a check that proves the result works.
What is prompt engineering for coding?
Prompt engineering for coding is the practice of writing instructions so an AI produces correct, reviewable code. In practice it comes down to supplying context, constraining the change, asking for small steps and defining how to verify the output, rather than searching for magic wording.
Do these prompts work in ChatGPT, Claude, Cursor and Copilot?
Yes. They are tool-agnostic: they contain no commands specific to one product. Agents that can read your repository and run tests can follow every step, while in a plain chat window you paste the code and run the checks yourself.
How long should a coding prompt be?
As long as it needs to carry the goal, context, constraints, output format and check, which is often six to twelve lines. Do not paste whole repositories. Point to specific files or paste the relevant function and the exact error.
Should I tell the AI to act as a senior engineer?
A role line like that helps a little with tone, but concrete instructions help more. Say what to check, what to leave alone and how to report. A strict reviewer prompt works because of its list of things to look for, not the title.
Why does the AI keep changing code I did not ask about?
Models tend to add improvements unless told not to. State the boundary in the prompt: change only this file, no new dependencies, keep the public names, do not refactor unrelated code. Then check the diff size against the task.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.