A single developer, one worker, and a local network create a tidy illusion of correctness. Operations run in the one order the code silently assumes, and that order is luck, not proof. Luck holds until the code ships to production and meets concurrent traffic.
The Details:
Tests verify outputs, not the hidden timing assumptions beneath them. A test confirms that a function returns the right value once, not that step A always finishes before step B starts under load. CI runs one thing at a time in a clean environment, so the gap where bugs live never opens.
AI assistants write from the prompt they are given, not from the concurrency reality you failed to mention. Ask for a webhook handler and you get a clean check-then-act pattern: look up a record, act if it is missing, write the result. That pattern is fine until a retry fires a second worker against the same message while the first is still running, and both read "not done" before either writes "done."
Better prompting only moves the problem instead of solving it. Telling the assistant that retries happen produces idempotency keys and conditional updates, but only developers who already know retries exist think to say so. The people who need the warning most are the ones least likely to type it.
The durable fix is naming the assumption in the code itself, not in a prompt or a design doc. A comment stating that a handler must be idempotent because the provider retries on failure travels with the function forever. It shapes what any future assistant generates and what any reviewer checks, turning a silent premise into a visible contract.
Bottom Line: Passing tests only prove the code survived the one timing pattern you happened to test; write down the ordering assumption before the code quietly picks one for you.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
