Prompting for Code That Ships
Context, specs, plans, and the case for small diffs
Context is the whole game
Strip away the folklore and prompting for code is one skill: getting the right context in front of the model. It cannot read your architecture docs, your team's taste, or your dependency versions unless you put them there. A vague prompt does not produce vague code; it produces confident code aimed at the wrong target.
Think about what you would hand a capable contractor on day one: the constraints, the versions in play, the conventions the team actually enforces, and an example of code the team considers good. That is your context payload. The model needs the same onboarding, except it needs it every conversation, because it remembers nothing between them.
language and framework versions, hard constraints (no new dependencies, must stay backward compatible), house conventions, one or two examples of house style, and the failing test or error output if one exists. Thirty seconds of pasting saves three rounds of correction.
Spec first, code second
Describe the behavior before you ask for the implementation. Inputs, outputs, edge cases, and what should happen when things go wrong. If you cannot write two sentences about how the function behaves on empty input, you are not ready to review the model's guess about it, and it will guess.
The single highest-leverage artifact you can paste is a failing test. It is an executable spec: unambiguous about the expected behavior, and it hands you the verification step for free. When you have one, lead with it.
Ask for the plan before the code
For anything non-trivial, make the model describe its approach before writing the implementation. Reviewing a five-line plan takes seconds; reviewing three hundred lines built on a wrong assumption takes an afternoon and ends in a rewrite anyway. Catch the wrong turn while it is still cheap.
In the same breath, ask it to state its assumptions. Models fill every gap in your prompt with a guess and never volunteer which guesses they made. Forcing the assumptions into the open turns silent failure into a two-line correction: no, we are on the older major version, and that config flag does not exist here.
Iterate, or start clean
Iterating in one conversation works while the model's mental picture is basically right and you are refining. But a long conversation accumulates every wrong turn and half-corrected idea in its context, and quality decays. When you notice the model relitigating an approach you already rejected, stop steering.
The sunk-cost trap: spending an hour correcting a degraded conversation because the first twenty minutes went well. A fresh start with a better prompt, informed by everything the first attempt taught you, is usually faster than turn fifteen of a salvage operation. Conversations are disposable. Treat them that way.
Small diffs beat big bangs
Request changes at the size you can actually review, because you are going to review them, right? A focused diff to one function gets real scrutiny. A two-thousand-line generation gets a skim and a prayer, which is how slop ships with your name on the commit.
This is the same discipline you already apply to human PRs, applied to a collaborator with infinite stamina. The model will happily generate the big bang. Your job is to not ask for it. Decompose the work, review each piece, keep the pieces honest.