What's the smallest, dumbest thing that made you completely lose trust in an AI agent mid task?
by•
It doesn't even have to be a big dramatic failures, more the small moments where something clicked and you went from trusting the output by default to double checking everything. For me it was watching an agent confidently rename a function across twelve files, then leave the original function untouched in a thirteenth file it apparently didn't search, with zero indication anything had been missed. It wasn't even a hard case, the file just wasn't in the directory it happened to grep first.
What was your moment? And did it actually change your workflow afterward, or did the trust creep back in after a week like it always seems to for me?
502 views
Replies
Mine was catching an agent "fix" a reconnection race by adding a half-second sleep, described in the summary as "improved connection stability." It technically made the symptom disappear, which is somehow worse than failing loudly; if I hadn't read the diff I'd have shipped a timing bug wearing a trust-me coat. What changed for me wasn't trust creeping back, it was the checkpoint cadence: I stopped reviewing at the end of long runs and started glancing at diffs mid-task, usually from my phone while the agent keeps going. Trust the direction, verify the diffs, never trust the adjectives in the summary.
Mine was similar, but the thing I stopped trusting wasn’t the code — it was the word “done.”
Agents often collapse “the command returned 0” into “the task is complete.” Those are different claims. A grep may have searched only one subtree; a test suite may have skipped integration tests; a deploy command may succeed while the wrong target is selected.
The workflow change that stuck for me is evidence-first completion: show the search scope, files touched, tests/commands run, exit codes, and any assumptions that could not be verified. I care less about a model confidence score because it can be confidently wrong about its own coverage. Structured proof is harder to fake accidentally.
An agent wrote a "benchmark" report with precise numbers. It was totally believable. Plus we spent a full day chasing pipeline anomalies before we realized. It had hardcoded placeholder values in the collection scritp instead of actually querying the system.
It wrote a fix and a new test to prove it worked. I reverted the fix out of habit to watch the test fail. But it stayed green). And the agent wrote an assertion that did not test the faliure path at all, just manufactured a passing suite
mine was almost the same shape as yours, one layer down. it fetched a page, parsed it cleanly, and told me a thing wasnt there. the fetch returned 200 and the parse was fine. the page just renders its content client side, so the server response only ever carried a subset of it, and everything downstream of that was confidently wrong. what got me was that nothing in the chain failed. a crash i can handle. this one returned success at every single step and produced an answer i repeated to someone else before i checked it. it did change the workflow. i stopped treating a successful fetch as evidence of anything and started confirming against the rendered page instead. your thirteenth file is the same bug wearing different clothes, the tool reported on what it searched rather than on what existed, and nothing in the output tells you which one you got.