Prompting for code

1. What's different about code

Code prompts are easier in one way and harder in another.

Easier: the success criterion is often binary. The test passes or fails. The function returns the right value or it doesn't. You don't have to argue about whether the output is "good" — you run it.

Harder: code has a huge implicit context. Style conventions, file layout, naming patterns, the rest of the codebase. The model can't see any of it. Anything load-bearing has to be written into the prompt.

2. The defaults for code prompts

A short checklist. Most code prompts get noticeably better when you include these:

• The signature. Function name, parameter types, return type. Removes the model's guessing.
• The test or the verification. What it should do, in concrete terms. Ideally a test case (when input is X, return Y).
• The shape of the surrounding code. One example from your codebase showing style, naming, error-handling pattern.
• What's off-limits. External dependencies you don't want added. Patterns you don't want copied. Files that can't change.
• The output format. Code only, no commentary. Or: a diff against the existing file. Or: the new file in full.

3. The default template

A clean code-prompt shape, adaptable to most tasks.

Stack: TypeScript, Node 20, strict mode.

Task: write a function with this signature:
function chunkBySize(items, maxBytes): items grouped into sub-arrays where each sub-array's JSON-serialized length is <= maxBytes.

Behavior: don't split single items, even if one item exceeds maxBytes (put it in its own sub-array).

Test case:
chunkBySize([{a:1},{b:2},{c:3}], 10) should return three sub-arrays if each is over 5 bytes when serialized.

Style: match this nearby helper —

export function chunkByCount(items, count) {
  const out = [];
  for (let i = 0; i < items.length; i += count) {
    out.push(items.slice(i, i + count));
  }
  return out;
}

Output: function only, no commentary, no usage example.

Every part of the template earns its place. The stack rules out wrong defaults. The signature names the interface. The test case grounds the behavior. The style example transfers your conventions. The output format prevents extra prose.

4. The two common code-prompt failures

The first: asking for behavior without a test case. Write a function that handles edge cases properly. What edge cases? Empty input? Null? Unicode? Very large input? Pick one and write it as a concrete test, or the model picks for you.

The second: not stating what's off-limits. The model will helpfully add a try/catch, helpfully import a library, helpfully add input validation — sometimes all three. If you didn't want those, say so. No try/catch. No external dependencies. No input validation.

5. Try it