Recap and Practice
Key takeaways
- Give context before the task: state the stack, conventions, and existing pieces to reuse — or paste the actual signature the code must fit.
- Define the boundaries: inputs, outputs, and cases. The interesting behavior of software lives at its edges, so spend your words there.
- Work in small, verifiable steps and ask for a plan before code; it's far cheaper to fix a plan than a .
- Iterate on targeted diffs, not full rewrites, and use concrete examples (ideally as tests) to pin down anything words leave fuzzy.
- Manage the as a resource, and say what not to do — explicit negative constraints keep the output tight.
Try it
Take a vague one-line request you might normally type ("add search to the list") and rewrite it as an engineer's before sending anything. Add the context (stack, the file it touches), the inputs/outputs, two or three edge cases, one example of the desired result, and one negative constraint (what not to touch). Send the rewritten version and compare it to what the lazy version would have produced. Do this for three real requests and the upgrade becomes automatic.
Prompt of the chapter
Context: <language + framework + version>, working in <file/module>.
We already <relevant existing pattern or library to reuse>.
Task: <one clear thing to build>.
Inputs / outputs: <types and shapes>.
Edge cases to handle: <list the ones that matter>.
Example: <one concrete input -> expected output>.
Constraints:
- No new dependencies — use <what we already have>.
- Touch only <this file>; don't refactor anything else.
- Keep existing names and signatures unchanged.
Before coding, give me a 3-4 line plan and wait for my "go".