Four projects gave me results I wanted to believe. Each needed a different check before the number meant what I thought it meant.

I trace it to a specific moment. I’d built a search engine by hand, typed in queries, and gotten back lovely, relevant-looking results. It felt finished. Then I benchmarked it properly against a test collection with real relevance judgments, and it scored about 0.01 precision. The engine that delighted me by eye was, by measurement, returning almost nothing right. The gap between “looks great to me” and “is great by measurement” was the widest I’d ever seen in my own work — and closing that gap was the entire education. The building had been the easy part. Not believing the demo was the hard part, and the important one.

Together they changed how I evaluate demos and benchmarks.

Four results that needed another check

The GPU port I refused to call a speedup. I moved a collision detector onto a GPU and wanted, badly, to report a win. But my timer resolution was milliseconds and the numbers I was comparing were a small number of milliseconds — noise. I couldn’t cleanly prove the GPU was faster, so I didn’t claim it was. Saying “I can’t measure this well enough to make the claim” is a skill, and a deeply unnatural one, because the CUDA in the title is right there doing the implying for you.

The deep-learning model that got an honest 61%. My capstone classified brain MRIs and landed only modestly above a majority-class baseline, while published work reached the 90s. The disciplined move was not to chase their number — it was to distrust it if I ever hit it. A suspiciously good result on hard, small, messy data is the first thing to audit, not the thing to celebrate. If I’d gotten 95%, my first job would have been to go find the leak.

The classifier whose headline accuracy meant nothing. I once modeled a lopsided public dataset where about 99% of cases went one way. A model reported “80% accuracy” on a held-out slice and looked like a success — until you noticed that slice still carried the real 99%-to-1% ratio, so the number was just the base rate leaking through a split I’d botched. It was an impressive figure sitting on top of a broken evaluation. The model had learned nothing and the metric applauded it anyway.

The text classifier that learned the wrong thing. Another one scored a comfortable 0.81 accuracy and a much worse 0.59 macro-F1 — and when I looked at why it was right, it had learned to detect the register of the writing, not the truth of the claims. It flagged anything that read like a hasty social-media post and trusted anything that read like a wire report. A style detector wearing a truth-detector’s label, and only a per-class metric plus an explanation exposed it. The accuracy number would have let me ship it.

The checks I kept

In each project, a second measurement changed the interpretation of the first. The benchmark exposed the search engine, macro-F1 exposed the classifier, and timer resolution limited the GPU claim.

I now use a short checklist whenever a result looks unusually good:

• Check the flattering result first. A surprising improvement may be real, but it deserves the most scrutiny.
• Pick the metric that can embarrass you. Accuracy can’t embarrass a model on imbalanced data; macro-F1 can. A benchmark can embarrass you; eyeballing never will. Choose the measure with the capacity to say you’re wrong.
• Ask not just whether it’s right, but why. A right answer for the wrong reason — style instead of truth, base rate instead of signal — will betray you the instant the distribution shifts. Correctness you can’t explain is borrowed, not owned.
• Match the claim to the measurement. If the timer cannot resolve the difference, report that uncertainty instead of a speedup.

None of these checks is exotic. Their value is that they can contradict the result I hoped to see.

How I use this now

The same suspicion is what I bring to AI now. The tasks you can safely hand a model are the ones where a deterministic check exists to embarrass it when it’s wrong; the dangerous ones are where no check exists and a plausible answer sails straight through. A demo is precisely the thing built to look right to someone who wants it to — which is why I trust it least of all.

The practical change is simple: when a result looks unusually good, I look first for the measurement, split, or representation that could have produced it by accident.

Next in “AI, and the work you can check” Three Graphics Bugs in an AI-Written WebGL App →