Prompting for Code: Getting Useful Output Instead of Guessing and Retrying
The gap between a vague prompt and a useful one is almost always missing context, not a smarter model.
Early on, my prompts to a coding assistant looked like "fix this" pasted above a broken function, and I'd retry three or four times with slightly different wording when the result missed what I actually needed. What changed the hit rate wasn't a better model — it was giving it the context I already had in my head but hadn't written down.
The single highest-leverage addition is constraints the model can't infer from the code alone: the language version you're targeting, a library you're deliberately not allowed to add, a performance requirement, or an existing pattern elsewhere in the codebase it should match. A model can read your function; it can't read your team's style guide or the ticket that specifies the actual requirement, so state whatever of that applies.
Second is showing, not just describing, when the task is about matching an existing shape. "Write a new endpoint like the one in orders.py" and pasting orders.py gets a far more consistent result than describing the pattern in prose, because the model is matching concrete structure instead of guessing at your description of it.
Third is scoping the ask to something checkable. "Refactor this file to be cleaner" invites the model to make judgment calls you didn't actually authorize; "extract the validation logic in this function into a separate function with the same behavior" gives it a concrete, verifiable target — you can check whether the behavior is actually the same.
None of this replaces reading the output. Prompting well changes how often the first draft is close to right, not whether you still need to review it — treat a well-specified prompt as a way to spend your review time on real judgment calls instead of on obvious misses the model made because it was guessing at missing information.