Category: My AI Experiments
There's a mental model most people use when working with AI: describe your problem, get a solution.
It works well enough, until it doesn't. And when it fails, the failure is invisible — because AI doesn't say "I don't have enough to go on." It gives you a confident, well-reasoned, completely wrong answer.
I learned this the hard way during a website security investigation. The AI and I ran a thorough analysis, reached a clear conclusion, and were wrong. Not because the AI was weak — because I gave it the wrong kind of input. When I changed the input, the same AI found the answer in seconds.
That gap — between the input that produces a wrong answer and the input that produces a right one — is what I want to talk about.
The Investigation That Almost Failed
My website was secretly redirecting visitors to a virus site. The attack was sophisticated: it only targeted specific browsers, fired at most once per device per day using a cookie-based cooldown, and left no trace in any file.
I asked AI to help investigate. I described the symptoms. We searched through files together — .htaccess, theme functions, plugin code. Everything looked clean. The AI identified the most suspicious external element in scope: a Chinese analytics script called 51.la. I removed it. The redirect stopped.
I called it solved.
Three weeks later, the identical attack appeared on another site I manage. No 51.la anywhere.
This time, instead of describing the symptoms, I gave the AI something different: the actual rendered HTML of an affected page, fetched using the exact browser User-Agent and IP type that triggered the attack.
The AI found an 83KB malicious JavaScript payload injected into every page. Inside it: a WeChat browser detector, a link-click hijacker, a cookie-based daily cooldown. The payload was stored in the WordPress database — in plugin configuration data — where no file-level search could ever find it.
Same AI. Same type of problem. Completely different outcome. The only variable was what I put in front of it.
Symptoms vs. Evidence: The Core Distinction
When you describe a problem to AI, you're giving it a symptom. When you give it raw data from the system that's failing, you're giving it evidence.
The difference matters because AI can only reason about what it can observe. Symptoms are your interpretation of what's happening — filtered, compressed, possibly wrong. Evidence is what's actually happening.
In my investigation:
Symptom: "My site is redirecting mobile visitors to a bad site, but only sometimes."
Evidence: The full HTML output of an affected page, captured from a device with the right browser, IP, and no prior visit cookie.
The symptom told the AI: something external is probably causing this. The evidence told the AI: here is the exact code running on the page, and here is the line that's doing it.
Symptoms invite guessing. Evidence enables diagnosis.
Three Reasons AI Defaults to Guessing
1. You constrain the search space without realizing it.
When I said "check these files," I was implicitly telling the AI: the answer is in these files. It accepted that framing and worked within it. It never questioned whether the real answer might be somewhere else entirely.
AI follows the scope you define. If your scope is wrong, the analysis is wrong — no matter how rigorous it is within that scope.
2. Confident output masks uncertain reasoning.
AI doesn't say "I'm guessing here." It generates fluent, well-structured explanations regardless of how much signal it actually has. A diagnosis built on thin evidence sounds exactly like a diagnosis built on solid evidence. You have to build in your own uncertainty.
3. Symptoms often point at the wrong layer.
In security problems — and many engineering problems — the place where failure appears is rarely the place where failure originates. My site redirected in the browser. The cause was in a database table. Describing what I saw in the browser pointed the AI at the browser layer. The actual problem was three layers deeper.
The Framework I Now Use
Before handing a problem to AI, I ask three questions:
What layer is this problem actually at?
Not where I'm observing it — where it originates. A redirect that appears in the browser might originate in JavaScript, in server config, in a database record, or in an external script. Identifying the right layer determines what evidence to collect.
Am I giving AI a symptom or evidence?
If I'm describing what I observed, that's a symptom. If I'm giving AI raw output from the system — logs, source code, rendered HTML, API responses — that's evidence. Default to evidence.
What would this look like from inside the system?
Before asking AI to diagnose, I try to observe the problem from the perspective of the thing that's failing. In the security case: what does the page HTML look like to an affected visitor? That question led me to the right evidence. "What do my files look like?" led me to the wrong one.
This Applies Far Beyond Security
The same principle shows up everywhere AI-assisted work breaks down.
Debugging code: Giving AI an error message is a symptom. Giving it the full stack trace, the relevant function, and the actual input that triggered the error is evidence.
Analyzing data: Describing a trend you noticed is a symptom. Giving AI the raw dataset — or at minimum a representative sample — is evidence.
Getting writing feedback: Saying "my intro feels weak" is a symptom. Pasting the actual intro and asking AI to identify specifically what's causing the weakness is evidence.
Medical analogies (for the metaphorically inclined): Telling a doctor "I feel tired" is a symptom. Blood test results are evidence. The doctor can work with either, but only one leads to a diagnosis rather than a guess.
In each case, the question is the same: are you describing what you observe, or are you showing AI what's actually there?
The Hidden Cost of Wrong Answers
One more thing worth naming: confident wrong answers have a compounding cost.
When I concluded the attack was caused by 51.la, I stopped looking. That conclusion felt solid — we'd done a thorough investigation, identified a suspicious element, removed it, and the problem appeared to stop. The investigation felt complete.
The cost of that wrong answer wasn't just that I misidentified the cause. It was that I stopped before finding the real one. A confident wrong answer doesn't just fail to help — it actively closes off further investigation.
This is why the quality of AI input matters even when the output seems correct. If you gave AI a symptom and it produced a plausible answer, you don't know whether that answer is based on real signal or a reasonable-sounding guess. The answer might be right. It might be confidently wrong. You can't tell from the output alone.
The only way to trust the answer is to trust the input.
What I Changed
I now treat AI-assisted investigation as a two-step process:
Step 1: Collect evidence first, before involving AI.
Fetch the actual output. Capture the real log. Get the raw data from the layer where the problem originates. Do this before describing anything to AI.
Step 2: Give AI the evidence, not the story.
Instead of "my site is redirecting," I paste the actual rendered HTML. Instead of "the function is slow," I paste the profiler output. Let AI read primary sources, not my summary of them.
The AI's reasoning ability isn't the bottleneck. The evidence pipeline is.
The Uncomfortable Implication
Thinking about AI this way puts more responsibility on the person using it, not less.
Collecting the right evidence requires understanding your system well enough to know where to look. Asking the right question requires knowing enough about the problem to frame it correctly. These are skills. AI doesn't replace them — it amplifies whatever you bring to the table.
If you bring symptoms, AI amplifies your guesses.
If you bring evidence, AI amplifies your diagnosis.
The investigation that almost failed taught me this more clearly than any tutorial could. The AI was ready to find the answer from the beginning. I just wasn't giving it anything to find it with.
This is part of an ongoing series on using AI as an ordinary person with no specialist background. Related:
