Prompt engineering for developers: 5 habits that work

A language model answers the question you asked, not the one you meant. When the output is vague, wrong or oddly generic, the cause is usually a prompt that left too much to guess. Five habits fix most of it.

1. Say exactly what you want

Compare two requests:

Generate Python code for sorting.

Write a Python function that sorts a list of integers with quicksort.
Include type hints and a docstring, and show one example call.

The second names the language, the algorithm, the input and the quality bar. The model no longer has to choose for you.

2. Give it the context you have

The model cannot see your project. Tell it what matters:

• the stack and versions, for example Node.js 22 with TypeScript in strict mode,
• the constraints, such as no new dependencies,
• the audience or role: "review this as a senior backend developer",
• the code or error message itself, pasted in full.

A role is not magic. It works because it tells the model which details to care about.

3. Show an example of the output

One or two examples do more than a paragraph of description. If you want commit messages in a certain style, paste two good ones. If you want JSON, show the exact shape:

Return JSON only, in this shape:
{ "title": string, "tags": string[], "summary": string }

4. Break big tasks into steps

"Build a login system" produces a wall of code that is hard to check. Split it: design the data model, then write the registration handler, then the tests. Review each piece before moving on. Small steps are easier for the model to get right and easier for you to verify.

5. Iterate, and ask it to check itself

Treat the first answer as a draft. Follow up with what is wrong: "the function fails on an empty list", "keep the public interface unchanged". It also helps to ask for a self review: "list the edge cases this does not handle". The answer often points to the real gaps.

A prompt you can reuse

Role: You are a senior TypeScript developer.
Context: Node.js 22, Express, PostgreSQL. No new dependencies.
Task: Write a function that validates the request body for POST /orders.
Rules: Return a list of field errors. Do not throw.
Output: Code first, then three test cases.

Know the limits

A good prompt raises the quality of the answer. It does not make the answer true. Run the code, read the diff, and never paste secrets or customer data into a tool your company has not approved.

For a practical use of these habits, see our workflow for refactoring with AI assistants.