How to brief an AI coding tool so the code survives real users
Prompts get you what you asked for, which is rarely what you needed. Four things to state up front that cost nothing now and are expensive to add later.
· 6 min read
Most advice about prompting coding tools is about getting better output for the feature you asked for. This is not that. The features are usually fine. What sinks these projects is everything nobody thought to mention — and unlike a person, the tool will not stop to ask.
A competent contractor given a vague brief asks questions. A model given a vague brief produces something plausible and confident. That difference is the entire problem, and it is solved by saying four things up front.
One: who is allowed to see this
"Build a page showing orders" produces a page showing all orders. It is a correct response to the request. You meant the signed-in customer’s own orders, and you did not say so because it was obvious to you.
State the rule with the feature, every time: who may read this, who may change it, and what happens to everyone else. Say it even when it seems obvious — especially then, because obvious things are exactly what goes unsaid.
Two: what happens when it fails
Ask for checkout and you get the path where the card is accepted. Real payments decline, time out, succeed on the provider’s side while your request dies, and occasionally arrive twice.
So describe the failures with the feature: "if the payment provider times out, do not create the order, show this message, and make it safe to retry without charging twice." That sentence is the difference between software and a demo.
Describe the unhappy path or you will not get one.
Three: where this belongs
Each prompt starts fresh. Without being told, the tool has no reason to reuse the date helper it wrote last Tuesday, so it writes another. This is how codebases end up with five versions of the same idea and lose their speed around week four.
Point at what exists: "use the existing formatDate helper", "put this next to the other API handlers", "we already have a permissions check — use it." A sentence of location per prompt is the cheapest maintenance work you will ever do.
Four: what must not change
Given a feature that does not quite fit the current data model, a tool will often adjust the model to suit — reasonably, and without mentioning it. That is fine in week one and quietly destructive once real data exists.
Name the fixed points: "do not change the database schema", "do not alter how sessions work", "if this needs a schema change, tell me instead of doing it." You want the constraint surfaced as a question, which is exactly what it would be from a human collaborator.
A checkpoint worth keeping
Once a week, ask the tool three questions about its own work: what has been written more than once, what data is reachable by someone who should not have it, and what happens on the failure paths of anything touching money. It answers these well when asked. It will never ask them itself.
None of this slows you down meaningfully — it is four sentences of context, not a specification. What it buys is that the thing you built in a fortnight is still the thing you are building on in six months, rather than the thing you are explaining to whoever has to replace it.