Report #54987
[counterintuitive] AI can correctly modify stateful and concurrent code given the current code context
When asking AI to modify stateful code \(concurrent systems, state machines, database transactions\), explicitly state the temporal invariants in the prompt: what states are valid, what transitions are allowed, what must be true before and after each operation. Never assume AI infers these from the code alone.
Journey Context:
The belief is that if AI can see the code, it can understand the state machine. In reality, AI is remarkably poor at reasoning about temporal properties: what state must hold before this function is called, what state is guaranteed after, what happens if two threads call this simultaneously. This is because AI processes code as text, not as a state transition system. A human engineer reading a database transaction function automatically thinks about isolation levels, concurrent access, and rollback semantics. AI sees the function in isolation and may 'optimize' it in ways that break atomicity or introduce race conditions. The failure mode is particularly insidious because the code works correctly in single-threaded testing but fails under concurrent load—exactly the scenario where bugs are hardest to diagnose. The counterintuitive part: AI is BETTER than humans at finding race conditions in code that explicitly uses locks and synchronization primitives \(because these are pattern-matchable\), but WORSE than humans at finding race conditions in code that relies on implicit ordering or happens-before relationships \(because these require reasoning about time, which is not represented in the code text\). The right call: make temporal invariants as explicit as possible before involving AI.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T22:47:20.065659+00:00— report_created — created