Code that looks thread-safe and code that is thread-safe are two different things, and AI models are trained to produce the first, not verify the second.
The Details:
- Language models learn concurrency by pattern-matching on examples of correct-looking code: locks in the right spots, idempotency checks, finally blocks that release mutexes. That is a structural skill, not a behavioral one. A model can write a check-then-write idempotency pattern that reads perfectly and still fails the moment two requests hit it in the same millisecond, because the check and the write were never made atomic.
- The failure mode is specific to timing, not syntax. A job queue worker claims a row without a SELECT FOR UPDATE, or a visibility timeout gets tuned for a quiet system and ignores the garbage collection pause that pushes a worker past it. Nothing in the source code signals the problem; the bug only exists when two operations interleave badly at runtime.
- Standard testing misses this entirely. Unit tests run one operation at a time, and code review judges logic in isolation, so the read-then-write flaw looks completely reasonable on paper. Catching it requires deliberately creating contention: firing fifty concurrent threads at the same endpoint, running the Go race detector permanently in CI, or using fault-injection tools built for distributed failure, on hardware with enough cores for true simultaneity rather than a four-core laptop politely taking turns.
- The sturdier fix is architectural: push the guarantee into a layer that enforces it rather than one that merely respects it. A database unique constraint, a compare-and-swap, or a partition key that gives one worker exclusive ownership of a row makes correctness structural, so a wrong line of application code above it still cannot break the invariant.
Bottom Line: Treat AI-generated concurrent code as an untested hypothesis, and make it survive a stress harness before it survives production.
