AI Prompts for Coding

Start with a clear task

AI writes plausible code very easily. The gap between plausible and correct is where all the difficulty lives — and it's almost entirely determined by what you put in the prompt.

The specific failure mode: you ask for a function, get something clean and idiomatic, and it ignores the error-handling pattern used everywhere else in your codebase, invents a utility that doesn't exist, or silently changes behavior at an edge case you didn't mention.

The prompts below are built around supplying constraints — existing conventions, the actual error, the surrounding code — rather than describing the task in isolation.

The technique: constraints over description

For code, what you exclude matters as much as what you ask for. A prompt that says "write a function that fetches user data" leaves the model free to choose the HTTP client, the error strategy, the return shape, and the naming convention — and it will choose differently from your codebase every time.

Supply the constraints explicitly: paste an adjacent function as a style reference, name the libraries already in use, state the error-handling contract, and say what must not change. This turns a plausible answer into a mergeable one.

• Weak prompt

  Write a function to fetch user data from the API.

• Strong prompt

  Here's an existing function from the same file, which shows our conventions: [paste]. Following exactly these conventions — same HTTP client, same error handling (we return a Result type, never throw), same naming and JSDoc style — write a function that fetches a user by ID from /api/users/:id. It must handle 404 as a non-error empty result. Don't add new dependencies.

• Why it works

  The model now has your conventions rather than the internet's average conventions. The 404 rule and the no-new-dependencies constraint prevent the two most common review comments before they happen.

The prompts

• Debug with context

  I'm getting this error: [paste full error + stack trace]. Here's the relevant code: [paste]. Here's what I expected to happen: [describe]. Walk through what's actually happening step by step, then give me the minimal fix — not a rewrite.

• Match existing conventions

  Here's an existing function showing our conventions: [paste]. Following exactly these conventions, write [describe function]. Don't add dependencies we don't already use.

• Adversarial code review

  Review this code as a skeptical senior engineer: [paste]. Focus on correctness bugs, race conditions, unhandled edge cases, and security issues — not style. For each finding, give me the specific input that triggers it.

• Explain unfamiliar code

  Explain what this code does and why it might have been written this way: [paste]. Flag anything that looks like it's working around a bug or a constraint I should know about before I change it.

• Test the edge cases

  Write tests for this function: [paste]. Cover the happy path briefly, then focus on edge cases and failure modes: empty input, boundary values, concurrent calls, and malformed data. Use [test framework].

• Safe refactor

  Refactor this for readability: [paste]. Constraint: the observable behavior must be identical, including error cases. List any behavior change you're unsure about instead of making it silently.

• Performance diagnosis

  This is slow: [paste code]. Here's the context: [data size, how often it runs, where]. Tell me where the actual bottleneck is likely to be and how you'd measure it before optimizing anything.

• Migration plan

  I need to migrate from [X] to [Y] in a codebase with [scale/constraints]. Give me a staged plan where each stage is independently shippable and reversible. Flag the stage most likely to cause an outage.

• Architecture trade-offs

  I'm choosing between [approach A] and [approach B] for [problem]. Our constraints: [team size, scale, timeline, existing stack]. Argue for each, then tell me which you'd pick and what would change your mind.

• Understand a codebase

  Here's the file structure: [paste tree]. Here are the entry points: [paste]. I need to add [feature]. Where does it belong, what will I need to touch, and what's likely to break?

• Regex explanation

  Explain this regex piece by piece: [paste]. Then give me 3 strings it matches and 3 near-misses it doesn't, so I can verify my understanding.

• SQL review

  Review this query: [paste]. Schema: [paste]. Check for: missing indexes it needs, N+1 risk, incorrect join cardinality, and anything that breaks at 100x current row count.

• Error-message audit

  Here are our error messages: [paste]. For each, tell me whether a user could act on it. Rewrite the ones that only make sense to someone who wrote the code.

• Convert with fidelity

  Convert this from [language A] to [language B]: [paste]. Preserve behavior exactly, including edge-case handling. Where the languages differ in a way that changes semantics, stop and tell me instead of guessing.

• Pre-merge check

  Here's my diff: [paste]. Play the role of the reviewer who'll block this PR. What's the most likely objection, what did I forget to update (tests, docs, types, migrations), and what breaks for existing callers?

Common mistakes

• Not pasting the actual error

  Describing an error in prose loses the stack trace, which is usually the part that identifies the real cause. Paste it in full.

• No style reference

  Without an example of your existing code, you get idiomatic-for-the-internet code, which is idiomatic-for-nobody in your repo.

• Accepting invented APIs

  Models confidently call methods that don't exist in your version of a library. Verify every unfamiliar API call before running it.

• Asking for a rewrite when you want a fix

  "Fix this" often returns a full rewrite that changes ten things. Say "minimal fix, don't restructure" when that's what you mean.

Frequently asked questions