AI-written async code can pass every test and still collapse under real traffic, because the failure mode is silence, not a crash.
The Details:
Generated code mirrors its training data, which is dominated by light-load, happy-path examples. It rarely captures what happens when fifty coroutines fight over one connection pool, so the resulting function type-checks and passes tests while the actual bug lives in the timing between operations, not in any single line.
The most common trap is holding a lock across an await. In a quick test, that awaited network call returns in milliseconds and nothing looks wrong. Under production contention, the same await can stretch for seconds while the lock stays held, so every other task queues behind one slow request. CPU stays low, dashboards stay green, and throughput quietly falls off a cliff.
Catching this requires a different review lens: ask how long each locked section could take in the worst case, name every piece of shared state and who touches it, check for blocking calls hiding inside async wrappers, and confirm what happens when a downstream dependency slows down. Bundling concurrent changes into small, isolated pull requests forces reviewers to actually look at these questions instead of skimming past them inside a bigger diff.
Standard load tests miss this entirely because they test volume, not shape. A steady stream of requests lets a connection pool settle into equilibrium; a sudden burst of two hundred requests against a pool of fifty exposes the lock-across-await problem in seconds. A small chaos harness that spawns concurrent workers with injected latency, run fifty or a hundred times in CI, catches these probabilistic races that a single test run would miss.
Bottom Line: Treat AI-generated concurrent code as a first draft of the happy path and let humans own the contention thinking, because that is the part no model can feel from inside a conversation.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
