When AI Writes Timeouts, It Forgets the World Can Say No

Ask a model for a function that calls an external service and it writes the version where the service always answers, and answers fast. That is not a bug, it is a gap: the prompt described success, so the code only knows success.

The Details:

• A one-line prompt like "call the pricing API" never mentions failure, so failure never enters the output. The model cannot answer questions a single function has no visibility into: is this call inside a three-second user request or a thirty-second background job, and is the downstream service safe to retry at all.

• Mismatched timeouts compound instead of canceling out. A ten-second user request can sit above a thirty-second inner call wrapped in three retries, so the caller gives up at second ten while the inner call keeps running for up to ninety seconds beneath a request nobody is waiting for anymore.

• Retries turn a slow dependency into a flooded one. If the service is slow because it is overloaded, three retry attempts triple the load on it exactly when it can least absorb more, converting a resilience feature into the mechanism that causes the outage.

• Generated tests inherit the same blind spot as the code. They verify the happy path in detail and never simulate a hung or timed-out dependency, because nothing in the original prompt raised that case. A green test suite ends up certifying a failure path that was never written, let alone executed.

The fix is to decide the failure policy before any code exists: the end-to-end time budget, what happens when it is blown, and whether retrying is safe. Feeding that policy into the prompt, or baking it into a shared HTTP client wrapper, makes the safe behavior the default instead of something a developer has to remember to add later.

Bottom Line: Clean, passing code only proves the model handled the case it was told about. Nobody decided the failure policy, so the happy path decided it by default, and that default is silence until the outage.