AI for coding
Start with the job to be done
Frame the outcome, evidence, and human decision before asking the model to produce anything.
1Try it yourself
Playground
AI coding assistant patterns
Same snippet — three safe workflows: explain, debug, test.
function total(items) {
let sum = 0
for (let i = 0; i <= items.length; i++) {
sum += items[i]
}
return sum
}Before you start
Why this matters
Without opening an AI tool, write the acceptance test for this job: diagnose and repair a wrong order-total function without widening the change. Name one fact that must be exact, one judgment a person must make, and one condition that should stop the workflow. Compare your answer with the professional standard below; the gap is what you should practice.
2Learn the idea
Read
Define the professional job
The working assignment is to diagnose and repair a wrong order-total function without widening the change for a developer reviewing a pull request. That sentence is narrower than “use AI for coding.” It identifies a deliverable and a reviewer. Write a definition of done with three layers: the output must satisfy the audience's need; factual or functional claims must be traceable; and a named person must own the final decision. A candidate patch is not working software until the local toolchain proves it. Prefer a five-line diff you understand over a polished rewrite you cannot defend.
Start by separating tasks. The model may draft, classify, transform, compare, or suggest. It may not silently approve, publish, grade, deploy, cite, or consent on someone's behalf. For this assignment the authoritative material is the function, failing test output, runtime and package versions, expected behavior, and the relevant API documentation. Anything absent from those inputs is either an explicit assumption or an unanswered question.
Read
Convert the job into a contract
Use this prompt as a realistic starting contract:
You are pairing on a TypeScript checkout service. The failing case has `shippingOverride=0`, but the result adds the default shipping fee. Explain the likely cause first. Then propose the smallest diff. Do not change public types or add dependencies. Return: diagnosis, unified diff, and three tests. Flag any assumption.
Notice what the prompt does: it states the setting, limits the output, names forbidden behavior, and requests evidence that can be reviewed. It does not ask the model to “make it amazing.” If a constraint matters, make it testable. Replace “be accurate” with a source boundary, formula check, test command, rights ledger, or approval step.
A useful response would look like this: The assistant identifies a truthiness fallback that replaces free shipping (0) with the default fee, changes it to a nullish fallback, and proposes tests for zero, undefined, and a positive override. That description is intentionally observable. “Looks good” is not acceptance. The operator must run the focused unit test, the full test suite, type-check, lint, and inspect the diff against the documented contract. Keep the source material beside the draft so review means comparison, not memory.
Read
Scope and stop rules
Run the work through reproduce → explain → patch → test → review. Stop when an authoritative input is missing, a high-risk claim lacks evidence, private material cannot be safely removed, or the proposed action exceeds the permission granted. Escalation is successful workflow behavior, not model failure.
Common framing mistakes are invented library methods; broad refactors disguised as fixes; tests that merely copy the implementation; ignored error output. Prevent them by writing a one-paragraph job card: user, decision, deliverable, source of truth, constraints, reviewer, and stop condition. This card becomes the anchor for every later prompt.
Continue learning · glossary & guides
- Can the job be completed and reviewed without guessing its purpose?
- Which action remains owned by a person, and what evidence will that person inspect?
- Reference · Related concept
- Next