Foundations10 minLesson 3 of 60
Prompting That Works for Code
Prompting for code is less about magic words and more about being a clear manager. You are briefing a fast, literal worker who will do exactly what you ask, including the parts you did not mean. Precision pays.
State the goal and the done condition
Always say what success looks like. Not just "add validation" but "add validation so empty emails return a 400 with a clear message, and the existing tests still pass." A done condition turns a vague request into something the agent can verify.
Give role, then constraints, then task
prompt skeleton
Role: You are a senior TypeScript engineer on this repo.
Constraints: No new dependencies. Match the existing test style.
Task: Add input validation to createUser and cover it with tests.
Done when: invalid input is rejected and the full suite is green.Show, do not just tell
One concrete example of the output you want is worth a paragraph of description. If you want a certain commit message format or a certain test shape, paste an example.
Ask for a plan before big changes
For anything non-trivial, ask the agent to outline its plan first and wait for your go-ahead. A bad plan is cheap to fix in one sentence. A bad implementation is expensive to unwind. This single habit prevents most large, wrong diffs.
Common mistakes
- Asking for too much in one turn. Break it into reviewable steps.
- Leaving the success criteria implicit, so the agent guesses.
- Not pointing at the relevant files, so it searches blind.
- Accepting the first answer without reading the diff.
