Giving the AI What It Needs

The Three-Part Report

The AI cannot see your screen. It does not know what you clicked, and it has no memory of your last session unless you provide it. So give it the same three things you would give a colleague: what you did, what you expected, what actually happened. "I filled in the booking form and pressed Confirm. I expected a confirmation page and an email. Instead the page went blank, and this appeared in the console: [full message]." That report is enough to work with. Compare it with "the booking is broken", which forces a guess at which of a dozen possible failures you mean. The quality of the fix you get back is almost entirely set by the quality of this description.

• What I did, what I expected, what actually happened — every time
• It cannot see your screen; nothing is obvious unless you say it
• Attach the full error text to the report rather than describing it
• The fix you get back is only as good as the description you gave

Say What Changed Since It Worked

Add one more thing whenever you can: what was different the last time it worked. "This worked before I asked you to add the date filter" narrows the search enormously, because the cause is almost certainly inside that change. If you have been making several changes without checking, you will not have this information. That is the practical reason for checking after each one. It is also worth mentioning things that seem irrelevant. You updated something, you moved a file, you were on a different network. Beginners consistently leave out the detail that turns out to matter, on the grounds that it could not possibly be related. Say it anyway, and let the AI decide.

• Name the last change made before it broke — usually the cause
• Mention anything else that changed, even if it seems unrelated
• Checking after each change is what keeps this information available
• The detail you assume is irrelevant is often the one that matters

Ask What It Is Doing

When a fix comes back, ask a short question before accepting it. What was wrong, and what did you change? You are not auditing the code. You are building a mental model of your own project, and a written record you can look back at. It also catches a specific failure worth catching: the fix that solves the symptom by removing the feature. It quietly deletes the check that was inconveniently failing, rather than making it pass. A one-paragraph explanation in plain language costs you fifteen seconds. Over weeks it turns an opaque pile of files into something you have at least a rough map of.

• Always ask what was wrong and what changed, in plain language
• Watch for fixes that remove the feature instead of repairing it
• You are building a map of your own project, not reviewing code
• The explanations accumulate into real understanding over weeks

Try It Yourself

The worst moment to learn how to report a bug is while something is broken. Set the report up now, calmly, so the panicked version of you only has to fill in blanks.

What I did: [the exact steps, in order, ending with what you pressed]

What I expected: [what should have happened]

What happened instead: [what you actually saw on screen]

The full error, pasted: [the complete message — file names, line numbers, all of it]