Before asking AI to fix it again, write a debugging evidence note
“It still does not work” describes your frustration. It gives an AI coding assistant very little new information. Before the next attempted fix, collect something the assistant and a colleague can both inspect.
A debugging evidence note separates what you observed from what you think caused it. Debugging means investigating why software behaves differently from what you expect. The note is useful with an AI assistant, a mentor or your future self.
This exercise uses a fictional reading-list page. It focuses on investigation and communication, rather than teaching a particular AI tool or promising that one prompt will find every bug.
Describe one mismatch
Suppose selecting “Unread” should show only books that have not been marked as read. Instead, the page still shows every book. That is the mismatch. “The filter is broken” is less useful because it leaves the expected behaviour unstated.
Record where you saw it, the steps you followed and the result. Include the browser and relevant version details when known. Avoid guessing a cause in the observation field. “The database is ignoring the filter” is a hypothesis unless you have evidence from the database.
1. Capture a small repeatable example
Use a practice list containing one read book and one unread book. Load the page, choose “Unread” and record which entries remain visible. Repeat the steps to see whether the behaviour is consistent. Note anything that differs between attempts.
If the behaviour only occurs after a refresh or after changing another filter, record that sequence. The order may matter. Keep a copy of your work before making further changes, using a method you understand. Do not discard uncommitted work just to create a clean starting point.
2. Keep observation and explanation separate
Observation: both books remain visible after selecting “Unread”. Hypothesis: the selected value is not reaching the filtering function. Alternative hypothesis: the stored read status uses a different format from the comparison. Neither explanation is established yet.
Write a check that could distinguish them. For example, inspect the selected value and one item’s read status at the point where filtering occurs, in your own practice environment. If you do not know how, ask a mentor or the assistant to explain where to inspect before requesting a rewrite.
Practise choosing useful evidence
You have a screenshot of the two books and an error message copied from a different page. Which should go in the note?
Reveal the useful distinction
Include the screenshot if it shows the actual mismatch, plus the steps and expected result. Do not present the unrelated error as evidence for this bug. Record that it came from another page if you are keeping it for a separate investigation. Evidence should answer a specific question, not make the note look technical.
3. Ask for a diagnostic check
Try this prompt: “Expected: choosing Unread shows only unread entries. Observed: both test entries remain visible. Steps and relevant code are below. My hypothesis is that the selected value does not reach the filter. Suggest one check that would support or reject that hypothesis. Explain the result I should look for before proposing a code change.”
Provide only relevant, approved material. Remove credentials, private data and unrelated logs. If the assistant asks for more context, identify what question that context will answer. You are allowed to ask for an explanation of a proposed dependency or a larger edit.
Close the note with a result
After a change, repeat the original example and one nearby case. On the reading-list page, check “Unread”, “Read” and “All”, including an empty result. Record what happened rather than writing “fixed” because the assistant said it was.
If a check contradicts your hypothesis, keep that result. It narrows the investigation. A note saying “the selected value reaches the function, so I am checking the item status next” is progress, even when the screen still looks wrong.


