Coding AI prompts are worth writing when the task has a fixed shape: a diff that needs a message, a diff that needs scrutiny, a stack trace that needs hypotheses. They are worth very little when the prompt says "act as a senior engineer" and leaves the model to decide what to look at. These three prompts each state the input, the constraints, the output shape, and the things the model must not invent.
The rule underneath all three is the same. A model that has not read your code cannot review it, and a model that cannot see the relevant file cannot debug it. Both prompts below are built to refuse politely rather than to guess.
What these coding ai prompts have in common
Persona prompts ask for a stance: be a principal engineer, be a meticulous reviewer, think like a security researcher. The model responds in that register, which is pleasant and does not change what it examines.
A task prompt names the artefact and the defect classes. "Report correctness and security findings with a file reference and a line for each" gives the model something to check. "Be a meticulous reviewer" gives it a tone.
That difference shows up in the failure mode. Persona prompts fail by producing general commentary. Task prompts fail by producing nothing, or by producing findings you can verify. One wastes a few minutes of reading. The other occasionally catches a real defect that a tired human reviewer skimmed past.
A commit message prompt that explains the change
Write a commit message for the changes below. Produce: a subject line of at most [50 or 72] characters that states what changed and why in the imperative mood; and a body with one paragraph explaining the problem, one describing the approach taken, and one naming any behaviour, migration, or compatibility consideration the reviewer needs to know. Do not list the files. Do not describe how you arrived at the change. Do not add a ticket number unless one is present in the diff. Do not claim the change is tested, fast, or safe unless the diff contains evidence of that. Diff: [paste] Convention used in this repository: [conventional commits, plain imperative, or your own]
Fill in these details
- Character limit: Sixty or so characters keeps the subject readable in most log views and terminal widths. Longer works in web tools.
- Repository convention: If your project already uses a style, say so. Consistency inside a repository matters more than correctness in the abstract.
- Ticket reference: Ask for it explicitly if you want one. Do not let the model fabricate it.
The negative instructions carry the weight. "Do not claim the change is tested" prevents the phrase "tests passing" appearing in a commit where no test was run, which is the single most expensive habit in a commit message.
A code review prompt that reports findings, not verdicts
Review the code below for defects. Report each finding as: file and line, what the code does, the condition under which it produces the wrong result, and the smallest change that fixes it. Rank findings by severity, with correctness and security above style. Cover these classes explicitly: incorrect boundary or off-by-one handling, unhandled null, empty, or absent values, race conditions and ordering assumptions, error paths that swallow failures, resource and connection cleanup, and input validation on anything crossing a trust boundary. Do not rewrite the code. Do not comment on formatting or naming unless the naming hides a bug. Do not claim a performance cost or a security vulnerability without pointing at the line that causes it. If you find nothing, say so and list what you checked. Code: [paste the diff or the files] Language and version: [language, version, and framework]
Fill in these details
- Context: What the code is supposed to do, in two sentences. Most false positives come from missing context, not from a weak model.
- Boundaries: State where untrusted input enters. A review that cannot see the trust boundary cannot judge validation.
- Scope: Ask for one file at a time when the change is large. Reviewing twenty files at once produces shallow findings.
Ask for findings rather than an assessment. A model asked "is this code good?" will produce a paragraph. A model asked "what breaks?" will produce a list you can act on or dismiss.
A debug prompt for a stack trace
Here is a stack trace and the relevant source. Produce a ranked list of hypotheses for the cause, with the strongest first. For each hypothesis give: the specific frame in the trace that supports it, the code path that would have to run for it to be true, the single cheapest check that would confirm or eliminate it, and what the result of each outcome means. Then list the two or three pieces of information you still need, phrased as questions. Do not propose a fix before a hypothesis has a supporting frame. Do not invent source code, variable values, or API behaviour that is not shown. If the trace alone cannot distinguish between hypotheses, say so. Stack trace: [paste] Relevant code: [paste] Environment: [language and version, framework, database, where relevant]
Why hypotheses come before fixes
Ask for a fix and you will get one, immediately, with confident reasoning attached. Ask for ranked hypotheses and you get a cheap test to run first. The second question is usually answered in under a minute, and it frequently eliminates four of the five hypotheses before you touch the code.
Worked example: one trace, three hypotheses
A request times out inside a connection pool. A trace shows the failure at pool acquisition, with the originating call two frames up.
| Rank | Hypothesis | Supporting frame | Cheapest check |
|---|---|---|---|
| 1 | Pool exhausted by a caller that never returns connections | Frames above the acquisition point | Log checkout and return counts for one request cycle |
| 2 | A connection was leaked on an error path | Error-handling frame in the chain | Search for early returns between checkout and release |
| 3 | Pool size is simply too small for the traffic shape | Configuration rather than the trace | Compare configured size with concurrent request count |
The useful output is the third column. Checks one and two are minutes of work and eliminate the first two hypotheses. Only if both come back clean does the third deserve attention, and by then you know the problem is configuration rather than a leak.
How to check the output before you trust it
1. Verify every line reference
Open the file at the cited line. If the code is not there, the finding was generated rather than read, and the rest of the review deserves the same suspicion.
2. Reproduce the bug before the fix
A trace describes a symptom. Confirm you can trigger it, or you cannot tell whether your change fixed anything.
3. Run the checks yourself
A review that says no test covers a path is verifiable in seconds. A claim that the change is faster is not, unless the measurement is in the diff.
4. Keep the model out of the edit loop
Use it to locate, to hypothesise, and to review the diff. Make the edit yourself. The value is in the second pair of eyes, not in the typing.
What these prompts still cannot do
- Review code it cannot see. A partial diff invites confident findings about code that is not in front of the model.
- Know your runtime. Timeouts and memory behaviour depend on the environment, and the model will not ask about it unless the prompt insists.
- Replace tests. A generated test asserts your assumption back to you. Tests should fail first.
- Judge performance. It cannot measure your system, so it will not claim to.
Frequently asked questions
Is there a best code review prompt?
There is a structure rather than a wording. Name the input, list the defect classes you want checked, define the output shape per finding, and forbid invented claims. Any prompt with those four parts will outperform a persona prompt.
Should I paste a whole file or a diff?
A diff, when one exists. It bounds the review to what changed and keeps unrelated code from producing noise. When the code is new, paste the file and state what it is supposed to do.
Can AI fix my bug automatically?
Sometimes, and it will sometimes introduce a second bug in a place you were not looking. Use the debug prompt to narrow the cause, apply the change yourself, and rerun the failing case before you believe it. The prompts themselves are plain text and portable: all you need is somewhere to paste a diff, a trace, or a source file, and time to read the response in full.
Run the trace prompt on your next failure
Take the last bug that cost you more than thirty minutes, paste the trace and the relevant code into the debug prompt, and run the cheapest check on the top hypothesis before changing anything. For more prompts for day-to-day engineering work, browse the coding topic collection.