MODULE 03 / 18 · PART 2 · BUILD & REFACTOR
Code Generation & Implementation
Constrain the diff, preserve the invariant, and make the agent show its assumptions.
THE SHORT ANSWER
What this module changes.
The agent's default is to write more than you asked for. The prompt is the brake: smallest diff, named scope, explicit error paths, and an assumption list you can verify.
Implementation prompts should constrain the diff, not just describe the feature. The agent's default is to write more than you asked for; your prompt is the only brake.
Generated code looks plausible everywhere; it fails quietly at the edges that matter here — phone-number formats, currency rounding, East Africa Time, duplicate payment callbacks, and users on intermittent 3G. Constrain the diff and force the agent to name what it could not verify.
THE MODULE PROMPT LIBRARY
20 prompts for code generation.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Implement [feature] with the smallest possible diff. Do not touch files outside [scope]. Show me the diff before you explain it.
Why it worksConstraining the blast radius is the single most effective way to keep a change reviewable.
Implement [feature] following the existing patterns in [file/module]. Point out where the codebase has no pattern and you had to invent one.
Why it worksConsistency by default, and an explicit flag where a new convention was introduced.
Write the implementation, then write the one-paragraph explanation of why this approach over the obvious alternative.
Why it worksForces a justification you can paste into the PR description.
Implement [feature] with no new dependencies. If you believe a dependency is unavoidable, stop and tell me why.
Why it worksDependency additions are architectural decisions and should not be smuggled in.
Add [feature] behind a feature flag, defaulting to off, with the flag name and cleanup ticket noted in the code comment.
Why it worksMakes the change reversible and schedules its own removal.
Implement this and handle every error path explicitly. No silent catches, no bare excepts, no swallowed promises.
Why it worksError handling is where generated code is weakest; naming it up front fixes that.
Write the code so that [invariant] can never be violated. If that requires a type, a constructor, or a guard, add it.
Why it worksEncodes the invariant in the structure rather than in a comment.
Implement [feature] and list every place where you made an assumption about the surrounding code that you could not verify.
Why it worksUnverified assumptions are the top source of plausible-looking broken code.
Give me the implementation in two passes: first the naive correct version, then the version you would actually ship, with the differences called out.
Why it worksSeparates correctness from optimization so you can review each on its own terms.
Implement [feature] using only the APIs already imported in this file. If you need a new import, list it separately for my approval.
Why it worksKeeps the agent inside the dependency surface you have already vetted.
Write this function so it is pure and testable: [function]. Push all I/O to the edges and inject it.
Why it worksTestability is a design property; asking for it explicitly produces it.
Implement [feature] and annotate every non-obvious line with a comment explaining the why, not the what.
Why it worksComments that explain intent survive refactors; comments that restate code do not.
Add [feature] and make sure it is idempotent. Show me what happens if it is called twice with the same input.
Why it worksIdempotency is a requirement in distributed systems and rarely stated.
Implement this change and tell me which existing tests should now fail, and why they should not.
Why it worksPredicting test impact catches unintended behavior changes early.
Write the code for [feature] and include the structured log lines and metrics you would want when it misbehaves at 3am.
Why it worksObservability written with the code is observability that actually exists.
Implement [feature] with explicit input validation at the boundary and trust nothing inside. Show the validation code.
Why it worksPushes validation to the edge where it belongs and makes it reviewable.
Generate the implementation and then generate the minimal reproduction case that would prove it works.
Why it worksGives you a runnable proof rather than a claim of correctness.
Implement [feature] and keep every function under 30 lines. If you cannot, tell me which function resists and why.
Why it worksA size constraint that surfaces genuine complexity instead of hiding it.
Write this as a pure refactor plus a separate behavior change, in two commits, so I can review them independently.
Why it worksSeparating mechanical change from semantic change is what makes review possible.
Implement [feature] and give me the rollback: the exact steps to revert this change in production without a redeploy.
Why it worksEvery change should arrive with its own undo button.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Take a small feature. Run prompts 1 and 8. Read the diff before the explanation, list every assumption, and verify one of them directly in the codebase.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.