Skip to content
WANCODE
BM

Writing Better Development Prompts

15 minIntermediateHTML · CSS · JS

In this lesson

  • Include the five ingredients of a useful development prompt: context, task, constraints, expected output and examples
  • Report a bug the way a good teammate would: steps, expected vs actual, exact error
  • Ask for small, reviewable changes instead of rewrites

The big idea

The assistant only knows what you put in its context. A prompt that a new teammate could act on — with the real error, constraints and the shape of answer you want — gets you code you can actually review.

Here's a real-looking bug. A small shop page has "Add" buttons. Kopi O and Teh tarik work, but clicking Add on Milo ais stops the total from updating.

cart.js
const products = {
  kopi: { name: "Kopi O", price: 2.5 },
  teh: { name: "Teh tarik", price: 2.2 },
  miloAis: { name: "Milo ais", price: 3.2 },
};

function renderTotal() {
  const total = cart.reduce((sum, line) => sum + products[line.id].price * line.qty, 0);
  document.querySelector("#total").textContent = "RM " + total.toFixed(2);
}
index.html
<button data-id="kopi">Add</button>
<button data-id="teh">Add</button>
<button data-id="milo-ais">Add</button>
Text
TypeError: Cannot read properties of undefined (reading 'price')
    at renderTotal (cart.js:8)

What the console shows after clicking Add on Milo ais.

Most people would type something like "fix my code it doesnt work". The assistant then has to guess which code, what "doesn't work" means and what a fix may change. Guesses produce large, confident rewrites that are hard to review.

Five ingredients

  1. Context — what the project is, the relevant code (or which files to open), versions if they matter.
  2. Task — one clear job. For bugs: steps to reproduce, expected vs actual, and the exact error text.
  3. Constraints — what must not change: no new libraries, keep the public function names, only touch one file…
  4. Expected output — the shape of the answer: "explain the cause first, then the smallest fix as a diff".
  5. Examples — an input and the output you expect. One concrete example removes a lot of ambiguity.

Vague prompt

Markdown
fix my code it doesnt work

Reviewable prompt

Markdown
Vanilla JS shop page. Clicking "Add" on Milo ais throws
TypeError: Cannot read properties of undefined (reading 'price')
in renderTotal() (cart.js). Kopi O and Teh tarik work.

Expected: total goes up by RM 3.20.
Code: <products object + the buttons' HTML>

Only fix this bug — no new libraries, don't rename products.
Explain the cause first, then give the smallest fix as a diff.

The second prompt is longer, but every line removes a guess.

Ask for small, reviewable changes

  • One concern per request. "Fix this bug" and "also refactor the cart" are two prompts.
  • Ask for an explanation or a plan before the code, so you can catch a wrong assumption early.
  • Ask it to say when it's unsure or needs a file it hasn't seen, instead of guessing.
  • With agent tools, point at files ("look at cart.js and index.html") rather than pasting huge chunks.

Never paste secrets

Don't put API keys, passwords, tokens, .env contents or customers' personal data into a prompt. Replace them with placeholders like <API_KEY>. Check your organisation's rules on what code may be shared with which tools.

A better prompt raises the odds of a good answer. It doesn't guarantee one. You'll still read, run and test the result — that's the rest of this track. For reusable templates, see the prompt library.

Rewrite prompt.md for the Milo ais bug described above. Your prompt must include:

- the exact error message (copy it), - where it happens (renderTotal, cart.js or addToCart), - expected vs actual behaviour, - enough context to stand on its own — at least 40 words.

The preview shows exactly what the assistant would receive. You can write in English or Malay.

Checks

  • Includes the exact error message
  • Says where it happens
  • Describes expected vs actual behaviour
  • At least 40 words of context

Check understanding

Q1

Why paste the exact error message instead of writing "it crashes"?

Q2

Which request is easiest to review safely?

What you learned

  • Context, task, constraints, expected output, examples — each one removes a guess.
  • For bugs: steps, expected vs actual, and the exact error text.
  • Ask for an explanation first and the smallest change as a diff.
  • Never paste secrets or personal data into a prompt.
Preview

Console output from your code appears here.

Step 1 of 2