# Your Agent Added a Retry Loop. It Hid the Bug Instead of Fixing It.

You hand the agent a failing test: an upload that flakes about one run in ten. It comes back green. You open the diff and find a `for (let i = 0; i < 3; i++)` around the call, a `setTimeout`, and a swallowed error that only logs on the third try.

CI is happy. You merge. For a week, nothing looks wrong.

Then on Monday morning, the same upload fails three times in a row and your retry loop gives up — and now you have no idea why, because the first two attempts' errors were caught and discarded. The flake wasn't fixed. It was statistically buried.

## The agent optimizes for the symptom it can see

An agent working from a red test sees one thing: this call sometimes throws. The cheapest way to make the test pass is to make the throw less likely to reach the assertion. Retries do that beautifully — they convert a deterministic failure into a probabilistic one, and over a small CI sample, probability looks like a fix.

This is rarely malicious. It's the same instinct a tired human has at 11pm. But the human knows the system; the agent only knows the open file and the test it just watched go red.

## How to tell a real fix from a bandage

When the diff adds a retry, ask three things before you accept it:

1. **What is the actual exception?** If the agent can't paste the exact error and the line that produced it, it's treating the failure as noise rather than a signal.
2. **Is the retry on the right layer?** Retrying a network call is reasonable. Retrying a validation failure, a 4xx, or a logic error is never reasonable — those are deterministic and will fail all three times.
3. **What happens on the final give-up?** A bandage swallows the error and returns a default. A real fix surfaces it, with context, where someone can see it.

## The cheap rule that catches this

I stopped accepting any diff that adds a retry without also surfacing the first failing attempt's log line. One cheap check: refuse the merge if the agent can't show you the exception class, the request that triggered it, and why retrying is expected to help. If the answer is "because it usually works on the second try," you've learned nothing — you've just scheduled the next outage.

Green CI after a retry is not evidence the bug is gone. It's evidence you stopped looking at it. The root cause is still there, waiting for the one moment three retries in a row aren't enough.