A useful coding prompt reads like a small engineering ticket: it defines an outcome, supplies relevant context, and makes success observable. Before asking an assistant to implement your next change, take this seven-step pit stop. The goal is not a longer prompt. It is fewer assumptions between your request and the resulting patch.
1. Define one observable code change
Start with the behavior you want, not a broad instruction such as “improve this module.” Name the input, expected output, and boundary of the task. A focused request gives the assistant a clear stopping point and gives you something concrete to review.
Example: “Add a TypeScript function named parsePageSize that accepts a string or undefined and returns an integer from 1 through 100. Return 20 when the input is missing. Reject invalid values rather than silently correcting them.”
2. Supply the environment and relevant files
State the language version, framework, package manager, and test runner. Include the function signature, nearby implementation, and existing tests when available. Identify files by their actual paths so the assistant does not invent a directory structure.
For our example, useful context would be: “This repository uses TypeScript with strict checking and Vitest. Put the function in src/pagination.ts and tests in src/pagination.test.ts. Use named exports and follow the existing test style.” Exclude credentials, private customer data, and unrelated source files.
3. Turn ambiguous behavior into explicit rules
Words such as “valid,” “clean,” and “robust” hide decisions. Replace them with rules that settle edge cases. For numeric parsing, decide whether whitespace, decimal notation, signs, and leading zeros are acceptable. Otherwise, the assistant will choose behavior that may not match your application.
- Only undefined counts as missing input and returns the default value.
- A supplied string must contain only decimal digits, with no whitespace; leading zeros are allowed.
- Empty strings, signed numbers, fractions, and out-of-range values throw RangeError.
- Do not add dependencies or change unrelated exports.
These constraints make review more objective: each rule should correspond to visible implementation behavior or a test.
4. Specify the patch and explanation format
Tell the assistant what deliverable you need. An editor-integrated assistant might modify files directly; a chat interface might return a unified diff. Ask for the smallest relevant change, followed by a brief explanation of decisions and any unresolved assumptions.
Example: “Return a unified diff for the two named files. Preserve existing formatting. After the diff, list the tests added and any commands you actually ran. If you cannot execute commands, say so explicitly.” This separates generated code from verified results.
5. Require tests tied to acceptance criteria
Ask for tests that demonstrate your rules, not merely tests that exercise the generated implementation. For parsePageSize, cover undefined, both valid boundaries, a typical value, leading zeros, empty input, whitespace, fractions, signs, and values outside the permitted range.
Review those tests yourself before accepting the patch. A test can pass while encoding the wrong requirement. Require the assistant to distinguish tests it wrote from tests it executed, and inspect the actual command output when execution is available.
6. Iterate with evidence instead of broad corrections
If the first patch misses a requirement, provide the failing input, expected behavior, and observed result. Replace “try again” with “the input '2.5' should throw RangeError, but the function returns 2; correct the parser and add a regression test.”
Keep each follow-up narrow. Ask the assistant to inspect the cause before changing code, preserve passing behavior, and explain why the new test would fail against the previous implementation. This keeps a local correction from becoming an unnecessary rewrite.
7. Reuse the prompt across a consistent workflow
Save a template with fields for outcome, environment, relevant files, behavioral rules, deliverable, and verification. When evaluating another model, keep those fields and acceptance tests unchanged so you can assess the resulting patches against the same requirements.
SwiftRelay fits this workflow when you want access to different models through Claude Code, Codex, Gemini CLI, or an OpenAI-compatible SDK, with per-token billing. Sign up for SwiftRelay to try your next focused coding prompt with the small gift credit available to new accounts.
Before merging, inspect the diff, run the relevant checks, and confirm every acceptance criterion. A precise prompt improves the handoff; it does not replace engineering judgment.