How to Write Better Prompts for AI Coding Assistants

AI coding assistants are now part of most developers' daily workflow, but the quality of what you get back depends heavily on what you put in. The same model can produce a clean, idiomatic fix or a confident mess — and the difference is usually the prompt.

This guide is a practical framework that works across assistants, whether you use a chat window, an IDE extension or an agent in the terminal. It is built around one idea: treat the assistant like a capable new teammate who has never seen your codebase.

Why vague prompts fail

Language models predict a likely answer from the information they have. When the prompt is vague, the "likely" answer is the most generic one: a textbook solution in whatever language and style the model saw most often, ignoring your framework version, your conventions and your edge cases.

Compare:

❌ fix the login bug

✅ Users get "invalid token" right after logging in, but only in Safari.
   Stack: Next.js 15 frontend, FastAPI backend, JWT stored in an httpOnly cookie.
   Relevant files: api/auth.py (token creation) and web/lib/session.ts (cookie handling).
   Find the likely cause before changing anything, and explain it in 3–4 sentences.

The second prompt is longer, but it saves several rounds of back-and-forth.

The CCPV framework: Context, Constraints, Plan, Verify

1. Context: what the assistant cannot see

Give the assistant the information a new teammate would need:

• The goal, in terms of behavior: what should happen, what happens instead.
• The stack and versions: "React 19", "Python 3.12", "PostgreSQL 16". APIs change between versions.
• The relevant code: the file paths or snippets involved, not the entire repository.
• The error, copied exactly, including the stack trace.

If your assistant can read files itself, point it at paths instead of pasting code. If it cannot, paste the smallest piece of code that reproduces the problem.

2. Constraints: what "good" means here

Assistants will happily rewrite half a file or add a new dependency unless you tell them not to. Useful constraints include:

• "Keep the existing function signature."
• "Do not add new dependencies."
• "Match the style of the surrounding code."
• "Only touch billing/invoice.py."
• "Prefer readability over cleverness."

3. Plan: ask for the approach before the code

For anything bigger than a one-line change, ask for a plan first:

Before writing code, list the steps you would take and the files you would change.
Wait for my OK.

Reviewing a five-line plan takes seconds. Reviewing 300 lines of code built on a wrong assumption takes much longer, and the assumption is easy to miss.

4. Verify: make the output checkable

Ask for things that make verification easy:

• "Add a test that fails before the fix and passes after."
• "Tell me which edge cases you considered."
• "List anything you are unsure about."

Then actually run the code. The assistant's confidence is not evidence.

Prompt patterns that work

Explain before fixing

Here is a function and the error it throws. Explain what is going wrong, step by step,
before proposing a fix.

Forcing an explanation first surfaces wrong assumptions early.

Give an example of the output you want

Write a function that parses log lines like this:
  2026-10-28T09:15:02Z WARN payment-service timeout after 30s
into a dict like this:
  {"time": "2026-10-28T09:15:02Z", "level": "WARN", "service": "payment-service", "message": "timeout after 30s"}

One concrete input/output example is worth a paragraph of description.

Ask for the test first

Write pytest tests for a slugify() function covering: spaces, accents, repeated dashes,
leading/trailing symbols and empty strings. Don't write the implementation yet.

Agreeing on the tests first gives you a precise spec and an automatic check.

Code review mode

Review this diff as a senior engineer. Focus on correctness bugs, security issues and
missing error handling. Ignore formatting. Rank findings by severity.

Refactor with guard rails

Refactor this module to remove the duplicated validation logic.
Behavior must stay identical; the existing tests must pass without changes.

What not to delegate blindly

Assistants are good at boilerplate, refactors, tests, explanations and first drafts. Be more careful with:

• Security-sensitive code: authentication, cryptography, input sanitization, permissions. Review every line.
• Code that touches data: migrations, deletions, anything irreversible. Run it on a copy first.
• Unfamiliar libraries: models sometimes invent functions or parameters that do not exist. If an API looks unfamiliar, check the official docs.
• Licensing: if a generated snippet looks like it was copied from a specific project, treat it with the same care as copying code from the web.

A reusable prompt template

Goal: <what should happen>
Current behavior: <what happens instead, with exact error>
Stack: <languages, frameworks, versions>
Relevant files: <paths or snippets>
Constraints: <what must not change, style, dependencies>
Output: first a short plan, then the change, then how to test it.

Save it as a snippet in your editor. You will not fill every line every time, but going through it takes ten seconds and improves results noticeably.

Iterating when the first answer is wrong

When the result is off, do not just repeat the request. Tell the assistant what is wrong and why:

This works for the happy path but fails when the list is empty — it raises IndexError
on line 12. Handle the empty case by returning None, and add a test for it.

If a conversation has gone in circles for several turns, start a new one with a better first prompt that includes what you learned. Long, confused conversations tend to stay confused.

FAQ

Do longer prompts always work better?

No. Relevant detail helps; irrelevant detail dilutes it. Include what affects the answer (versions, constraints, errors) and leave out the rest.

Should I paste my whole codebase?

Usually not. Point the assistant at the files that matter. Tools that can search the repository themselves work best when you name a starting point.

Is it safe to paste company code into an AI assistant?

It depends on your company's policy and the tool's data handling terms. Check both before sharing proprietary code, and never paste secrets such as API keys or passwords.

Further reading

• Related: 25 Git commands every developer should know — useful for reviewing and undoing AI-generated changes
• Related: SQLite vs PostgreSQL for side projects