My AI Agent Found a 5-Sigma Result on Day One. I Deleted It.

I build with coding agents every day. The failure mode people warn you about — the agent hallucinating an API that doesn't exist — is the easy one. Your code won't run, you notice in seconds, you move on.

The failure mode that costs you weeks is the opposite: the agent produces something that looks rigorous and isn't.

Here are two of those, from my own work, and what I changed afterwards.

The first one was easy to catch
I'd built an autonomous research agent: it proposes hypotheses, tests them against historical data, scores them with pre-registered statistics, and buries the ones that fail.

On its very first run it surfaced a result about six times stronger than anything months of manual work had found. Five sigma.

My reaction wasn't excitement, it was suspicion — and the guardrails agreed. The agent had been given access to a data field it shouldn't have had at that point in the loop. It was reading the future. A lookahead bug, not a discovery. Fixed the leak, the "edge" collapsed into noise, and I deleted it the same day.

That one was easy because the result was too good. Five sigma in that domain doesn't happen. The number itself was the tell.

The second one nearly got me
Months later, a much more modest result. Small, plausible, the kind of number you'd actually believe.

I put it through everything I had:

permutation controls — shuffle the labels, confirm the result disappears. It did.
a holdout split — held-out data never touched during development. It held.
tick-level validation — replayed at the finest granularity available, rather than trusting the coarser bars. It survived that too.
Three independent checks, all passed. I was ready to act on it.

It was still an artifact. The execution loop had a bug: when an order failed to fill, the loop rewound and retried it under conditions that had already been revealed. Every fill was slightly luckier than reality allowed. Small enough per trade to look plausible, consistent enough across thousands of trades to look like an edge.

None of my three checks could catch it, because all three ran on top of the same loop. The permutation test shuffled labels and re-ran the same broken loop. The holdout split fed new data into the same broken loop. The tick validation replayed at finer resolution — through the same broken loop.

I'd built the validation with the agent, in the same session, against the same mental model. The validation inherited the blind spot. I retracted the result publicly and wrote up the mechanism.

What I actually changed
Not "trust the agent less." That's not operational advice — it doesn't tell you what to do on Monday.

1. Pre-register the pass criteria before anything runs. Write down the exact thresholds that would make the result real, and what would make you bury it, before you see a number. Once you have an exciting result, every judgement call bends toward keeping it. This is the single highest-value habit and it costs ten minutes.

2. Verify at a different layer than the one that produced the result. My three checks all sat on top of the execution loop, so none could see a bug inside it. Now, if an agent builds the pipeline, the verification has to touch reality somewhere the pipeline doesn't — different data path, different tool, different assumptions.

3. Treat a surprisingly good result as a bug report. It usually is. The prior on "I found something everyone missed" is far lower than the prior on "my measurement is broken." Spend the first hour trying to kill it, not extend it.

4. Publish the retraction. This is the one people skip. I've since published a result that weakened my own headline number — a metadata heuristic I'd been using over-predicted failures 4:1 against real verification. Publishing that made the original work more credible, not less, because it showed the number had survived someone genuinely attacking it.

The general version
Coding agents are extremely good at producing work that has the shape of rigour. Tests that pass because they assert the current behaviour. Validation that confirms what the pipeline already assumed. Benchmarks measuring the thing that's easy to measure.

None of that is the agent being dishonest. It's optimising toward the target you handed it, and a plausible-looking result is what you asked for.

So the useful question isn't "did the agent get it right?" It's:

What would this look like if it were wrong, and would my checks be able to tell?

If every check runs through the same code path, the answer is no — and you won't find out until it costs you something.

The tools and write-ups from this work are open source at github.com/junaidshahid-dev, including the retraction and the false positives I found in my own auditing tool.