Prompting AI for code

What does a coding prompt need that other prompts do not?

Code has a property most output does not: it either runs or it does not. That makes the requirements sharper, and it makes several kinds of vagueness immediately expensive.

• Environment. Language, version, runtime, framework. "Write a script" without this gets Python 3 code using a library you do not have.
• Surrounding code. What it has to fit into: existing types, naming conventions, the calling code.
• Error cases. Which failures matter and how they should be handled.
• Completeness requirement. An explicit ban on placeholder comments, which models emit freely otherwise.
• Uncertainty permission. Explicit licence to say "I am not sure this method exists" instead of inventing one.

How do you stop the model inventing API methods?

Fabricated method names are the most common and most annoying failure in AI-generated code. They happen because the model is asked for something specific it does not reliably have, and producing a plausibly-named method is the default behaviour. The name looks exactly right, which is what makes it costly.

Two things help, and both are one line each:

If you are unsure whether an API, method, or library version exists,
say so explicitly rather than guessing at a plausible-looking name.

After the code, list every external API or library method you used
that you are not fully certain about.

The second instruction is the more useful of the two: it produces a checklist to verify rather than requiring you to read every line suspiciously.

How much surrounding code should you include?

Enough to constrain the interface, not the whole repository. In practice that usually means the type definitions the new code must satisfy, the function that will call it, one nearby function that demonstrates house style, and any relevant configuration.

Pasting an entire codebase is context stuffing: it costs more, responds slower, and the important part gets lost among the irrelevant part. The relevant fifty lines beat the irrelevant five thousand.

How do you prompt for a code review?

Review prompts fail differently from generation prompts: rather than producing something wrong, they produce something useless — a list of style opinions when you wanted correctness bugs.

The fix is to name the lens and demand specificity:

Review the diff below for correctness only. Ignore style, naming and
formatting entirely.

For each finding, give:
- the exact line
- a concrete input that triggers the wrong behaviour
- what happens instead of what should happen

If you cannot produce a triggering input, do not report the finding.
Rank findings by severity. If there are none, say so — do not pad.

That last constraint matters more than it looks. Without explicit permission to find nothing, a model asked to review code will always find something, and the something is usually noise.

How do you prompt for debugging?

Supply the evidence, not your theory. A prompt that opens "I think the bug is in the parser" biases the model toward confirming that, which is sycophancy applied to debugging.

• The exact error message and full stack trace, not a paraphrase
• The code path involved
• What you expected and what actually happened
• What you have already ruled out, and how
• The environment: versions, OS, relevant configuration

Then ask for candidate causes ranked by likelihood, with a way to test each — rather than for the answer. Debugging is a search, and the model is better at generating hypotheses than at knowing which one is true.

Should you ask for tests at the same time?

Ask for them separately, and preferably first. Generated in the same response as the implementation, tests tend to assert whatever the implementation happens to do — including its bugs.

Writing the tests first, from the specification rather than from the code, gives you something that can actually fail. It is the same reasoning behind test-driven development, and it applies more strongly here because the implementation author has no memory of what the tests were meant to check.