Prompt Engineering for Developers: Prompts That Ship Working Code

Start every code prompt with a short, factual environment block. It takes fifteen seconds and eliminates most of the wasted round trips:

"Stack: TypeScript 5.4, React 18, Vite, Tailwind 3. State via TanStack Query. No class components. Strict mode on, no `any`. Tests in Vitest with React Testing Library."

Include versions where behaviour differs between them, and include the one house rule that would make an otherwise-correct answer unusable — a forbidden dependency, a required error-handling pattern, a naming convention.

Dumping a 900-line file rarely helps. The model spends its attention parsing irrelevant code and still lacks the piece that matters. Paste instead:

• The type or interface the new code must satisfy.
• The signature of the functions it will call, not their bodies.
• One existing example of the pattern you want it to imitate.
• The exact error message and stack frame, verbatim.

A single representative example of your conventions does more for consistency than a paragraph describing them.

"[Environment block]. Task: implement a hook `useInvoiceTotals(invoiceId)` that returns subtotal, tax, and total. It must satisfy this type: [paste type]. Use the existing query pattern shown here: [paste one example]. Requirements: handle loading and error states, no new dependencies, memoise derived values. Return only the hook file plus a one-line note on any assumption you had to make."

Two details do the heavy lifting: the type it must satisfy, and the instruction to surface assumptions instead of silently inventing them.

Bad debugging prompts say "this does not work". Good ones give the model the same information you would give a colleague:

"Symptom: the list renders twice on first load. Expected: renders once. Environment: [block]. Relevant code: [paste 20-40 lines]. Error/console output: [verbatim]. Already ruled out: it is not StrictMode double-render (reproduces in production build) and not a key collision. Give the three most likely causes ranked, the evidence for each, and the smallest change to test the top one."

The "already ruled out" line is what stops the model from suggesting the same three obvious answers you tried an hour ago.

Review is a different task from generation and deserves its own prompt with an explicit rubric, otherwise you get style opinions instead of risk assessment:

"Review this diff as a senior engineer on this codebase. Check in this order: 1) correctness and edge cases, 2) error handling, 3) security (input validation, injection, secret exposure), 4) performance for realistic data sizes, 5) test coverage gaps. For each finding: severity (blocker/major/minor), the exact line, why it matters, and the concrete fix. Do not comment on formatting. If something is fine, say nothing about it."

"If something is fine, say nothing" removes the padding that makes AI reviews tedious to read.

Refactors go wrong when the model changes behaviour while tidying. Constrain it explicitly:

"Refactor this module for readability with zero behaviour change. Rules: keep all public signatures identical, keep existing error messages verbatim, do not add dependencies, do not reorder side effects. Output a list of the changes you made and why, then the refactored code. Flag anything you believe is a latent bug rather than fixing it."

Separating "report bugs" from "fix bugs" keeps the diff reviewable.

Invented methods and options usually come from version blending: the model has seen several major versions of a library and produces a plausible average. Countermeasures, in order of effectiveness:

1. State the exact version in the environment block.
2. Paste the relevant signature or docs snippet you are targeting.
3. Require it to mark any API it is not confident exists with a `// verify` comment.
4. Ask for standard-library or first-party solutions unless you explicitly allow dependencies.

None of these are perfect, which is why the final rule stands: compile and test before trusting anything.

1. Write the environment block once and keep it in a scratch file for reuse.
2. Prompt for a plan before code on anything touching more than one file.
3. Generate the smallest unit — one function, one hook, one endpoint.
4. Run it. Feed real errors back verbatim rather than paraphrasing.
5. Run a separate review prompt on the final diff.
6. Ask for tests last, with the shipped implementation in context.