AI coding assistants write code as if only one process will ever run it, and that single assumption is why production incidents surface at 3 a.m. with no stack trace and no reproducible steps.
The Details:
When you ask an assistant to update a record or run a scheduled job, it writes a clean single-actor story: read the value, decide, write it back. Nothing in that prompt asks what happens if a second instance is two milliseconds behind, reaching for the same file or row. This mirrors how most tutorials and documentation teach coding in the first place: stripped to one process, one thread.
Unit tests and code reviews answer the wrong question. A test checks whether a function behaves correctly; a review checks whether code looks right. Neither asks whether that correctness survives a second copy running concurrently, because the danger lives in the gap between a read and a write, not inside either operation.
The bug hides behind bad odds. A fifty-millisecond race window in a job that runs every fifteen minutes will never trigger in staging with one instance active. Run it ten thousand times across scaled workers or overlapping cron schedules, and it will fire eventually, then erase its own evidence before anyone looks.
The fix is naming the concurrency model before any code gets written: single instance behind a lock file, multiple workers coordinated with SELECT FOR UPDATE, or atomic rename for shared config writes. That one sentence changes what gets written, what reviewers check, and what tests get added. Teams should also keep an explicit list of every piece of shared state and how access to it is coordinated, since the gaps in that list are exactly where failures will appear.
Bottom Line: Code that looks correct in isolation can still be globally fragile. Say the concurrency model out loud before writing a line of code, not after the data has already corrupted.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
