Stop Asking AI to Fix Things. Ask It to Look First.

Something breaks. You paste the error into your AI assistant. It hands you a fix. You apply it, and now two other things are broken that were working five minutes ago. If this has happened to you, the AI was not being careless. You asked it to solve a problem before either of you actually understood it.

Fixing and understanding are two different jobs

When you ask an AI to fix something, you are asking it to change code, a document, or a workflow, before it has a clear picture of what is actually going wrong. A capable model will still try, because that is what you asked for. It makes a plausible guess, writes a plausible-looking fix, and hands it back with total confidence. Confidence is not evidence. The model pattern-matched to something that resembles your problem. That is not the same as identifying your actual problem.

I run into this constantly building across my own projects, whether it is a small script or a full app. The fastest way to lose an afternoon is accepting the first fix offered for a bug nobody has actually diagnosed. The symptom gets patched, it resurfaces somewhere else, and now you are debugging a problem one layer deeper than the one you started with, and harder to explain to anyone, including yourself.

What “look first” actually means

Before you ask for a fix, ask for an investigation. Tell the AI to reproduce the problem, trace what is actually happening step by step, compare that against what is supposed to happen, and report back with evidence before it changes anything. This one change in sequencing does most of the work. It forces the model to build an accurate picture of the problem instead of jumping straight to an answer dressed up as certainty.

Here is the difference in practice.

Weak: “This button is not working, please fix it.”

Strong: “Investigate why this button does not work. Reproduce the issue, trace what happens when it is clicked, compare that with what should happen, check the console and network logs, and tell me the most likely root cause with evidence. Do not change any code yet.”

The strong version costs a few extra seconds to type. It saves you from a fix aimed at the wrong problem, which almost always costs more than a few seconds to undo.

Why this matters more with agents than with chat

This gets more important once you move from a chat window to a coding agent that can actually open files, run commands, and make changes across a project. A chat assistant that guesses wrong wastes a few minutes of your time. An agent that guesses wrong can touch five files instead of one, and by the time you notice, you are untangling a confident wrong answer instead of your original bug. The more capable the tool, the more it matters that you make it show its reasoning before it acts.

Try this the next time something breaks

Split the request into two steps, even when it feels slower. Step one: diagnose only, no changes, evidence required. Step two: once you have a root cause you actually believe, ask for the fix, and ask the AI to verify the full affected behaviour afterward, not just the line it changed.

This is not really a productivity trick. It is the same judgment you would use with a person. You would not want someone changing your code, your document, or your product before they understood what was actually wrong with it. AI is fast enough that skipping that step is tempting. It is also fast enough that the cost of skipping it shows up just as quickly, usually in the form of a new bug wearing the old bug’s clothes.