If you spend enough time online, you will eventually encounter two very different stories about artificial intelligence.

  • AI is about to transform everything.
  • AI is dangerous, unreliable, overhyped, and moving too fast.

Both stories contain some truth. Neither fully explains what is happening.

Over the past few years, I’ve become convinced that much of the confusion comes from a simple idea borrowed from computer science: the race condition.

In software, a race condition is not only about different speeds. Several parts of a system act at once, or interleaved. The outcome can depend on timing — who finishes or updates first — and on dependencies — who is waiting on whose unfinished work, and who is writing into the same shared decision, record, or rule. Same starting setup, different order, different result.

The term sounds technical, but most of us have experienced something similar.

Imagine a rumor spreading through a high school. Students hear it in minutes. Teachers hear it later. Parents hear about it that evening. The principal learns enough to investigate. The school board discusses it at the next meeting. There might not be anyone to blame. Different groups simply operate at different speeds.

That metaphor is a good on-ramp. It is not the whole idea. Speed lag alone is not a full race condition. In software — and in organizations — two actors may both write into the same policy, customer record, homework rule, or a chain of AI instructions. Whose update sticks matters. Adoption can finish before governance because today’s work depends on the tool while the policy depends on a review that is not done yet. Naming the race helps you pick a dependency to own, not a villain to punish.

Now imagine the rumor is only partially true, or completely false, or changing as it spreads. Things get messy. That is what the current AI era feels like to me.

One person tries a chatbot at home and gets a useful answer in seconds. Another person asks a slightly different question and gets something confident but wrong. A student uses AI for homework before the school has a policy. An employee uses it before the company knows what data is safe to paste. A manager hears that everyone should be using AI, while the legal team is still figuring out what that means.

That is not one problem. It is several systems moving at different speeds — and depending on one another.

We are watching multiple races at once

Many discussions about AI assume there is a single race: technology advances, then society responds. However, reality is more complicated. Several races are happening at once. Each has a different job in the mess.

Race #1: Capability vs understanding (mental-model lag)

AI tools can change quickly. At the same time, researchers and ordinary users are still learning what a given tool can and cannot do. New behaviors are often noticed after people start using the tool, not only before.

That is why a tool can feel amazing on Monday, confusing on Tuesday, and different again after the next update. The capability is changing faster than people can build a stable mental model of it.

In earlier software for many teams, putting the tool in people’s hands often felt close to the finish line: build, test, launch, move on. Today, for many GenAI tools, putting the tool in people’s hands increasingly feels like the beginning of the experiment. The tool changes. Users adapt. Data changes. Expectations change.

Race #2: Adoption vs governance (rules and authorization lag)

People can adopt a new AI tool in an afternoon. Organizations often need longer to write policies about its use. Governments often move more slowly still. This creates a gap.

Employees are already using the technology. Managers are trying to understand it. Compliance teams are drafting guidance. Regulators are debating rules. Everyone is trying to catch up with something that keeps changing.

For example, a worker may paste a customer email into an AI tool because it helps draft a response. The worker is trying to be helpful. The manager may not know it happened. The privacy policy may not mention it yet. The risk may be real even though nobody intended to create one.

This does not necessarily mean failure. It is evidence that rules and permissions lag behind use.

Race #3: Hype vs reality (discourse and evidence lag)

Every major technological shift attracts bold predictions. Some will prove useful. Some will prove too optimistic. Some will underestimate what is coming.

The challenge is that predictions often travel faster than evidence. A headline can say AI will eliminate a whole category of work before anyone has measured what happens in a messy real workplace. Eventually reality catches up.

The encouraging part is that we are beginning to see more public testing, measurement, and evaluation. Claims are being challenged. Assumptions are being tested. That is a sign that learning is occurring.

Race #4: Innovation vs resilience (failure-readiness lag)

Organizations understandably focus on new capabilities. The demo gets attention. The recovery procedure rarely does.

A demo might show an AI tool answering policy questions perfectly. Months later, the hard question is not whether the demo worked. It is whether anyone knows what to do when the tool gives a plausible answer from an outdated policy, cites the wrong source, or fails during a busy week.

Innovation remains important. Resilience becomes equally important. The question is no longer only “What can this technology do?” It is also “What happens when it fails?”

Race #5: Automation vs human adaptation (skill, culture, and practice lag)

Technology can change in months. Human systems often need longer. Schools, businesses, and families need conversation, practice, and trust. Those do not arrive automatically when the software updates.

A school may need to rethink homework. A business may need to rethink training. A family may need to decide when a child can use a chatbot and how to check the answer.

This is related to Race #2, but it is not the same race. Governance is about rules and authorization. Adaptation is about practiced judgment — how people actually learn to use the tool without pretending the transition is easy.

We have navigated hard transitions before — factories, cars, the internet, smartphones. We rarely did it by pretending the transition was simple.

Race #6: Scale vs blast radius (containment lag)

Good and bad ideas can spread widely before we fully understand them. The issue is not whether a technology is good or bad. The issue is that scale often arrives before certainty.

Blast radius, here, means how far a polished mistake can travel before someone catches it. A weak prompt, a bad policy summary, or a copied mistake can move through a whole organization because the output looks polished enough to trust. The better the system is at producing fluent answers, the easier it can be for an error to travel farther before someone notices.

This is related to Race #4, but it is not the same race. Resilience asks whether you prepared recovery. Blast radius asks how far a polished error travels before someone catches it. The larger that radius, the more monitoring, testing, and learning matter.

Six different mismatches, each with a different job to address. Timing and dependencies shape the outcome. Original diagram created with Codex for Renaissance Solutions.

Why this feels different

One reason the AI era feels unusually chaotic is that we have a front-row seat to the learning process, often without much explanation of what we are watching.

Rocket testing is a limited comparison, not a perfect one. When a rocket fails in a test, many people do not conclude that physics has failed. They understand that engineers are learning. That understanding took time to build for aviation and other technologies too.

AI is partly similar and partly not. The learning is more public, more continuous, and more woven into ordinary work. Everyday email, homework, and customer answers are partly the test surface. Fluent mistakes can travel farther than a visible explosion. Still, the useful lesson holds: when we see troubleshooting in public, that can mean learning is happening — not that the whole project has failed.

Researchers publish findings. Companies revise approaches. Users discover limits. Policies evolve. Everyone watches. The process can look messy because we are seeing the troubleshooting, not only the final result.

The goal is not perfection

Complex systems will never be perfect. There will always be issues to address as things change and we learn. The goal is to identify problems before the mismatch gets expensive, reduce how far a polished mistake can travel, and learn faster than the risks grow.

That mindset may be more useful than either unrestrained optimism or endless pessimism.

The question is not whether AI will create race conditions in this metaphorical sense. It already has — not as a claim that every AI product is full of software timing bugs, but as a way to describe org and society timing-and-dependency mess.

The question is whether we can identify them, understand them, and respond before the cost piles up.

One concrete organizational response

Naming these races helps us see the challenge. A response needs a dependency, an owner, and a feedback or recovery step.

Suppose employees begin relying on an AI assistant to answer questions about internal policies. The dependency is not the chatbot itself; it is the work decisions people now make from its answers. Someone needs to own the source material and the rule for keeping it current. Then the organization needs a feedback path: when an answer looks wrong or uncertain, employees know how to flag it, check the original policy, and correct the source or guidance before the same mistake travels farther.

Own the source, check uncertain answers, and feed corrections back before the same mistake spreads. Original diagram created with Codex for Renaissance Solutions.

The good news

The good news is that many people are already doing that work. Researchers are testing claims. Organizations are revising policies. Educators are adapting. Governments are debating. Users are sharing experiences. The troubleshooting has begun.

From the outside, that process looks messy. From an engineering perspective, it looks familiar.

The logs are finally coming in. Now we can start figuring out what is actually happening.