How to Write AI Coding Prompts That Get You a Real Fix, Not a Guess

Ask an AI tool to "fix this bug" and paste in a stack trace, and you will almost always get something back — a code block, formatted correctly, that looks like a fix. Whether it fixes your actual bug is a different question entirely. Vague coding prompts fail in a specific way: the model has to guess which language version you are on, which lines are actually relevant, what you already tried, and whether you wanted a full rewrite or a one-line patch. It fills every one of those gaps with the most common assumption in its training data, and the result compiles, looks reasonable, and is frequently wrong for your specific codebase.

Why "fix this bug" produces a guess dressed up as a fix

The core issue is that a bug report to a human colleague and a bug report to an AI model need to contain almost the same information, but people routinely give the model far less. A colleague who sees "TypeError: Cannot read properties of undefined" would ask what changed recently, which function, which line, what framework version — and would not attempt a fix without that context. A model asked the same question with no context does not ask; it answers anyway, using the statistically most common cause of that error message across millions of examples, which is very often not your cause. The fluency of the answer disguises how little it actually knows about your code.

The six layers a technical prompt needs

Language, framework, and version — "Python" is not enough when the fix for a dict ordering quirk is different between 3.6 and 3.9, and "React" is not enough when a hook behaves differently between React 17 and 18’s strict mode. Version-specific behavior is one of the most common sources of a technically-correct-sounding answer that is wrong for your setup. The exact error or symptom — the full error message and stack trace, verbatim, not a paraphrase in your own words; a stack trace carries file names, line numbers, and a call chain that "it crashes when I click save" throws away entirely. The relevant code, and only the relevant code — the function or component where the error originates, plus its immediate callers or type definitions if they matter, not the whole file and not the whole repository. What you already tried — ruling out one or two things you already checked saves the model from proposing them again and keeps the answer moving forward instead of backward. Constraints — what must not change: the public API, an existing test suite, a dependency you are not allowed to add, a performance budget you cannot regress. Output format — a unified diff, a full replacement function, or a plain-language explanation of the cause are three different deliverables, and the model will pick one arbitrarily if you do not.

Four coding prompt tasks worth knowing how to structure

Debugging a specific error: give the model the exact error text, the function where it originates, the language and version, and one sentence on what changed right before the bug appeared — a regression is far easier to diagnose than a bug with no timeline attached. Code review: instead of "review this," specify what to review it for — correctness, security, readability, or performance are four different passes with four different useful outputs, and asking for all of them at once tends to produce a shallow pass at each rather than a deep pass at one. Refactoring toward a stated goal: "make this more readable" is vague enough that the model will restructure things you did not want touched; "extract the validation logic into its own function without changing the function’s public signature or its return type" gives it an actual boundary to work inside. Writing tests for existing behavior: name the specific function, state whether you want the happy path, edge cases, or both, and specify the testing framework already in use in the project — a model given no framework will often default to the most popular one for the language, which may not be the one your project actually uses.

How much code to paste: more is not automatically better

There is a common instinct to paste an entire file, or several files, on the theory that more context can only help. In practice this often makes an answer worse, not better: a model working through six hundred lines to find the fifteen that matter has more surface area to misread, more unrelated functions it might "helpfully" suggest changing, and a much longer response to generate, most of which restates code that was never broken. The opposite mistake — pasting a single line with no surrounding context — is just as costly, because the model loses the type definitions, imports, and calling context it needs to reason about the line correctly. The right amount is usually the function or component where the symptom appears, plus its signature and any type or interface it depends on, plus the exact call site if the bug is about how it is being invoked rather than what it does internally. That is normally ten to sixty lines, not an entire file.

A worked example, before and after

Weak prompt: "why is this broken" followed by a 400-line React component pasted in full, with no error message and no description of what "broken" means. The model has to guess which of the four hundred lines is relevant, what "broken" refers to, and what a fix should look like, so it will likely propose changes to code that already worked. Structured prompt: "TypeScript, React 18. Error: Cannot read properties of undefined (reading ‘map’) at UserList.tsx line 42. This started after I added an optional filters prop to this component (code below) — before that change it worked fine. Do not change the component’s public prop types. Return a unified diff only, no explanation." followed by the ~25-line component. The second version tells the model exactly what broke, exactly when, exactly what boundary not to cross, and exactly what shape the answer should take — there is very little left to guess, which is the entire point of writing it this way instead of pasting the whole file and hoping.

Common mistakes

Pasting an entire file or repository and asking the model to "find the bug," which spends its attention on hundreds of lines that were never broken instead of the handful that matter. Describing an error in your own words ("it crashes when I save") instead of pasting the actual error message and stack trace, which throws away the exact file, line, and call chain the trace already gave you for free. Omitting the language version, especially on stacks with meaningful behavior changes between major versions, and getting an answer that is correct for a version you are not running. Asking for "a fix" with no output format and being surprised you get three paragraphs of explanation when what you actually wanted was a diff you could paste directly into your editor.

None of this is unique to any one language or framework — the same six layers apply whether the bug is in Python, TypeScript, Go, or a SQL query. What changes is which specifics matter (a Python version bump, a React strict-mode quirk, a SQL dialect difference), not the underlying structure of a prompt that actually tells the model what it needs to know before it starts guessing.