AI-Written Workers Quietly Assume Only One of Them Exists

A worker that reads a row, checks a status, and marks it done will pass every test on your laptop and still corrupt data the moment you run two of it at once.

The Details:

• Generated queue-processing code almost always assumes a single-process world because that is what dominates its training examples. The gap between reading a status and writing a new one becomes a race condition the instant a second worker touches the same row, and nothing in the code signals that this gap exists.

• The fix starts with the prompt, not the review. Asking for a worker that assumes many parallel instances forces the model to reach for real primitives, things like row locks with skip-locked semantics or a version column checked on update, and to explain what happens if a worker dies mid-job. Left unprompted, it has no reason to justify a coordination strategy it never built.

• Testing has to change shape too. A unit test that mocks the queue proves nothing about concurrency. The real test spins up two workers against the same row and checks that exactly one of them wins; teams that write this once, early, catch the bug before production does.

• The riskiest bugs live at the seams between systems, where the queue assumes the database is authoritative and the database assumes the queue never double-delivers. Naming the coordination mechanism directly in a comment next to the code keeps a future refactor from deleting a lock nobody remembers was load-bearing. Wall-clock timestamps are a particularly bad substitute for real coordination since clock drift lets an older write silently win.

Bottom Line: Distributed state without consensus is the default the moment a system has more than one process, and the job is not to remove that risk but to make it visible before it becomes a silent, three-week-old data problem.