Seeing the Race Before the Crash

AI systems are starting to share the workflows humans use. That creates risk, but it also makes the risks easier to see.

AI systems are beginning to participate in the same places where people coordinate work: repositories, issue trackers, ticketing systems, email, public comment portals, and customer-service queues. In these ordinary systems, overlapping actions, unclear authority, and decisions that no single actor fully owns can create trouble long before anyone sees a dramatic failure.

In software, a race condition occurs when multiple actors interact with the same shared system or state and the outcome depends on timing. A race condition is not always dramatic. It may first appear as an odd result, a duplicated action, a missing update, or a decision nobody can reconstruct. Once people can see the pattern, they can measure it and build controls around it.

I recently ran into a broader version of that problem while testing an AI assistant against twenty years of production data-mart transformation code. The assistant found an Assignment table and followed the concept of assignment through the codebase. That was a logical path, but it was shorter than the system’s actual execution path. Stepping through the pipeline took the work through a different, longer route before it reached the same idea.

The assistant had found something meaningful out of order and treated the first useful answer as the whole answer. If another developer had accepted that analysis and opened a ticket or prepared a change from it, the work could have been internally consistent and still wrong. In this kind of large codebase, manifests and a pipeline view give the model the map it needs to see where a concept sits in the real flow of work. A human review caught the mismatch before the AI’s answer became the next person’s assumed source of truth.

We built most collaboration systems for human participants. Now an agent can draft documentation in the same repository where another tool is looking for bugs, while maintainers decide what needs review. Recent reporting on projects such as Godot, empirical work on agentic coding pull requests, and the Linux kernel’s move toward explicit AI-assistance disclosure and human accountability show that this is already a practical maintenance question.

AI can participate usefully in shared workflows when the organization is clear about who has authority, which actions require approval, and whether it can explain what happened afterward.

A small-municipality test

Consider a small municipality with limited staff and budget. AI could help process citizen requests, identify duplicate issues, summarize public comments, draft first-pass responses, and route work to the right department. For residents, that could mean fewer lost requests and faster service.

The municipality still needs to decide where the tool can act and where a person remains accountable. A system might prepare a draft response, but a staff member approves a high-impact action. It might identify duplicate requests, but someone can correct the grouping. It might route work, but the decision record shows what information it used and who made the final call.

Practical guardrails are ordinary engineering: scoped permissions, human approval for high-impact actions, audit logs, rate limits, and post-action review. They turn a vague concern about AI into questions a public office can answer: Who owns the decision? Can a resident appeal it? What information did the system use? Can we reconstruct the action later?

My father learned the same lesson about safeguards more than once. Like many people, he sometimes treated a power-tool guard as something that slowed down the work. The guard was annoying until it became the reason someone kept all ten fingers. (My father and two brothers are missing parts of at least one finger.)

The mature form of a powerful tool includes the safety practices around it. For AI, that work is already taking shape in the NIST AI Risk Management Framework, its Generative AI Profile, the EU AI Act’s requirements for risk management, record-keeping, and human oversight, and standards such as ISO/IEC 42001 for responsible AI management systems.

Make the interactions visible

The encouraging part is that these risks are becoming easier to name. A team can inspect where an agent can act, which data it can use, and what requires human review. A city can decide which recommendations remain recommendations. A maintainer can require accountability for a contribution before it becomes part of a shared codebase.

That work does not make AI risk-free. It makes the operating boundaries visible enough to govern. The future will be shaped by the people who build those boundaries while the new tools are entering everyday work, rather than after an opaque failure has taught the lesson for them.