Prompting Patterns That Produce Reviewable Code

Most of the "AI is making developers faster" framing skips the part where the prompt itself does the work. A vague prompt produces vague code that takes longer to review than to rewrite. A well-shaped prompt produces a diff you can read line by line and decide on. The difference is not the model. It is the shape of the ask.

The six prompt shapes that hold up

Across enough sessions you start to notice the same six shapes producing the most reliable output. Each one moves the model from inventing a spec to executing against one you supplied.

1. Write the test first

Ask the model for tests against a contract you have described, then ask it to implement against those tests. Two prompts, but the second one is heavily constrained by the first. The before/after is stark.

Before: "Write a function that parses a CSV line." You will get something plausible that may or may not handle quoted commas, escaped quotes, or empty trailing fields.

After: "Write Jest tests for a function parseCsvLine(line: string): string[] that handles: unquoted fields, double-quoted fields containing commas, escaped double-quotes inside quoted fields, and trailing empty fields. Then implement the function so the tests pass." The output is now reviewable because the contract is explicit.

2. Function signature first

Give the model the signature plus a two-line description. Let it fill the body. This is the smallest unit of work the model is consistently good at.

// Implement this. Throws if the input is not a finite number.
// Returns the value rounded to 2 decimal places as a string with a leading currency symbol.
function formatCurrency(value: number, currency: "USD" | "EUR" | "GBP"): string {
  // ...
}

The signature plus the two comments leave the model very little room to invent. The result is a body you can read in five seconds.

3. Explain this in four sentences

For understanding unfamiliar code, ask for a short explanation first. The four-sentence limit forces the model to pick the load- bearing facts. Long explanations tend to summarise; short explanations tend to explain.

Before: "Explain this code." You get paragraphs of restated control flow.

After: "Explain in exactly four sentences what this function does, why it uses a Map instead of a plain object, and what would change if the input was unsorted."

4. What can go wrong here

Before committing a function you wrote yourself, ask the model to enumerate failure modes. The output is a checklist you can walk through. The model is much better at listing what could go wrong than at writing code that gets everything right the first time, and this prompt leans into that asymmetry.

A useful follow-up: "For each failure mode, write the smallest test that would catch it." Now you have a working test suite for code you wrote yourself.

5. Show me three approaches

For design decisions, never ask for the recommended approach. Ask for three approaches with trade-offs. The model is much more calibrated when generating alternatives than when picking a winner; the calibration comes from the comparison being explicit.

"Show three approaches to client-side caching for this list view — local state in the component, a context-based cache, and a query library. For each, name two trade-offs that would matter at 1,000 concurrent users."

6. Rewrite this paragraph to...

For editing your own code or text, never ask the model to "improve" it. Give it the change criterion. "Rewrite this paragraph to remove every adverb" is a workable prompt. "Make this better" is not. The same principle applies to code: "Rewrite this function so it returns early on the error paths and never nests more than two levels deep" produces a specific diff. "Refactor this function" produces noise.

What makes a prompt produce reviewable code

The six shapes share three properties. Once you can name them you can recognise a good prompt before sending it.

• Small scope. One function, one paragraph, one test file. Anything bigger and the verification cost catches up with the generation cost.
• Named conventions. The framework, the version, the test runner, the naming style your codebase uses. Models default to majority-vote conventions; if your codebase is in the minority you have to say so.
• Explicit constraints. "Throws if the input is not finite" is a constraint. "Handles edge cases" is not. The model cannot read your mind about what counts as an edge.

The anti-patterns

Three prompt shapes consistently waste time. They feel productive and produce output that looks reasonable until you read it.

Vague asks. "Make this faster." "Clean this up." "Add error handling." The model has to guess what "faster" means, what "clean" looks like in your codebase, what errors are worth handling. The output reflects the guess.

No context. Pasting a function with no surrounding file produces code that ignores the conventions of the file. Paste the imports. Paste the adjacent function. The model is good at matching local style; it cannot match what it cannot see.

Asking the model to invent specs. "Design the data model for a calendar app" hands the most important decision in the system to the system least equipped to make it. Decide the spec, then ask the model to execute against it.

When the routine fails

The patterns above are reliable in the centre of what the model knows. There are three domains where even a well-shaped prompt produces unreliable output.

The first is libraries the model hallucinates. Less popular libraries get treated as if they shared an API with their more popular cousins. The model will confidently call methods that do not exist. Verify against the actual documentation before trusting any unfamiliar library call.

The second is domains the model has shallow exposure to — niche industry rules, internal company conventions, recent framework changes. The output reads as confidently as anywhere else but is closer to a plausible guess than a correct answer.

The third is the verification cost of long completions. A 200-line output can take longer to read than to write. If you find yourself accepting output you have not read, that is a signal to shrink the prompt, not a productivity gain.

The habit that compounds

The developer who treats every prompt as a small spec rather than a wish becomes consistently faster over months. The compounding comes from a quiet feedback loop: each well-shaped prompt teaches you what the model can do reliably, and each poorly-shaped prompt teaches you which assumption was load-bearing. After a few hundred rounds, the prompts get shorter and the output gets more reviewable. The habit is small — write the spec before you write the prompt — but it is the difference between AI making you faster and AI making you confidently slower.

Related reading

Prompting is half of the AI-assisted workflow. The other half is knowing when to distrust the output — covered in the five ways AI-generated code goes wrong. For the broader workflow of using an LLM as a pairing partner rather than a generator, the AI pair-programming workflow guide covers checkpoint loops and the diff discipline. Both posts sit inside the ai-assisted-development topic.