DEV Community

Cover image for World Models: Why the AI Race Is Moving Beyond Next-Token Prediction
varun pratap Bhardwaj
varun pratap Bhardwaj

Posted on • Originally published at qualixar.com

World Models: Why the AI Race Is Moving Beyond Next-Token Prediction

A person facing a split world: a glowing language-model token stream on one side and a physically coherent city on the other

Watch the film first

The film is the fast version of this argument. It starts with the thing most AI conversations skip: an answer can sound perfect and still be detached from the world it claims to describe.

Watch: Are LLMs a Dead End? Why AI Industry Betting on Something Bigger!

This article is the evidence companion. It is not an obituary for large language models. I use them every day. They write, retrieve, explain, and increasingly operate software. But the moment we ask an AI system to act, a different question arrives: what does it think will happen next?

That question is behind the sudden rush toward world models.

A child's hand reaching for a coffee cup on a table, with a subtle translucent prediction path showing the cup cannot pass through the table

The cup and the table

Pick up a cup of coffee. Before your hand moves, your brain has already ruled out a few outcomes. The cup will not pass through the table. If you nudge it too close to the edge, it may fall. If you grab it by the handle, it will turn a particular way in your hand.

You do not narrate this to yourself. You do not need to calculate a physics engine in your head. You carry a working, incomplete, constantly corrected model of what tends to happen around you.

That is the intuition behind a world model. In the language used by the people building them, it is a system that tries to predict the future state of an environment and the effects of an action. A language model predicts a likely next token. These are related capabilities, but they are not the same job.

The difference can sound academic until the agent has permissions. Then it becomes painfully concrete.

An assistant that writes the wrong sentence can be corrected. A system that predicts the wrong database state can drop a table. A robot that predicts the wrong clearance can hit a shelf. A procurement agent that assumes an API call is idempotent can spend the same budget three times while it tells you everything is under control.

That is why I do not find the current world-model discussion interesting because it promises a new category of AI. I find it interesting because it forces the industry to say what it means by understanding.

Why this race is happening now

The phrase “world model” is suddenly everywhere, and that is usually where good thinking goes to die. It is being used for interactive video, spatial reconstruction, robotics, simulated web environments, and agent training. Those are not interchangeable products. Calling them all world models does not make them comparable.

Still, there is a real shift underneath the marketing.

In late May, NVIDIA introduced Cosmos 3, a foundation-model effort for physical AI that combines physical reasoning, world generation, and action generation. Its technical report describes an attempt to bring these pieces into one open stack. The bet is clear: robots and autonomous systems need somewhere to rehearse consequences before the consequence arrives in the physical world.

In June, Alibaba introduced the Qwen-Robot Suite, separating manipulation, navigation, and world prediction into distinct components. Its Qwen-RobotWorld report frames world modeling as part of embodied intelligence rather than a prettier form of video generation.

The same move is happening in software. Qwen-AgentWorld describes a language world model for agent environments such as MCP, terminal, software engineering, web, operating system, and Android. The environment is digital, but the point is familiar: tools change state. An agent should be able to practise in a representation of that state before it takes an expensive or destructive action for real.

And AWS made the least flashy point, which is often the one worth keeping. In a June Physical AI post, AWS argued that pixel-plus-synthetic-data recipes are hitting limits in cost, opacity, and sim-to-real gap. Their proposed direction is a learned model whose internal representation is scene semantics, such as objects, relations, affordances, and kinematics, rather than raw pixels alone. Read the AWS argument.

None of these announcements proves that a general-purpose world model has arrived. They prove that serious teams have started treating prediction of state and consequence as a missing layer.

A robotics lab split into four panels: navigation, manipulation, simulation, and verification, with a human engineer observing the boundary between simulation and reality

Fluency is not a map

There is a reason this subject needs more skepticism than excitement. A model can look as if it knows a world without carrying a stable representation of that world.

The cleanest example comes from Vafa and colleagues. They studied a generative model trained on New York taxi trajectories. In ordinary use, the model appeared very competent. It could produce plausible routes and reproduce shortest paths with high accuracy.

Then the researchers tried to recover the map implicit in its behavior.

The map was impossible.

Roads and locations that should have obeyed the city’s geometry did not line up. The model had learned shortcuts that worked on familiar trajectories, not a representation that stayed coherent once the route changed. Small detours exposed the weakness.

That finding matters because it is easy to fool ourselves with a system that passes the common case. The common case is where most of the training data lives. The failure case is where the model has to use the structure it claims to understand.

This is not a complaint about one paper or one architecture. It is a warning about the test we choose. If you only score an agent on whether it produced a plausible action, you can miss whether it carried the state needed to keep that action safe.

The usual benchmark question is: did it get the answer?

The reliability question is: did it get there for a reason that still holds after the world changes?

Those questions can produce the same result on a demo. They diverge in production.

Beautiful video is not evidence of physics

World models will make increasingly convincing worlds. Google DeepMind’s Genie 3 is a useful proof of the visual and interactive direction: it generates navigable environments from a prompt and runs them in real time. World Labs’ Marble shows another route, turning multimodal inputs into spatial worlds that can be explored and exported.

Both are real technical progress. Neither should be mistaken for a proof that an AI system has solved causal understanding.

A generated city can be internally consistent for long enough to impress you and still fail under the action that matters. A simulated warehouse can look correct while its object relationships are wrong. A robot can learn from a rich synthetic scene and then fail in a real room because the reflection, texture, latency, or force profile is different. This is the sim-to-real gap in a more expensive costume.

The danger is not that people will be impressed by the visuals. They should be. The danger is treating visual coherence as the same thing as physical correctness.

A beautiful generated warehouse scene with a transparent overlay exposing impossible object collisions and incorrect force arrows

This is not an LLM obituary

The title of the film asks whether LLMs are a dead end. The answer is no.

Language models are extraordinarily useful. They are the right interface for asking questions, translating intent, drafting plans, retrieving context, writing code, and communicating with people. A robot does not become better because it stops using language. A world model does not eliminate the need for planning, memory, perception, tool access, or a person who owns the outcome.

What changes is the architecture around the model.

When an AI system stays inside a chat box, next-token prediction can carry a surprising amount of value. When it starts manipulating a browser, a terminal, a budget, a vehicle, or a robot arm, it needs more than a plausible continuation. It needs a representation of relevant state. It needs a way to check that representation against reality. It needs a policy for what to do when the two disagree.

The future is probably not “LLMs versus world models.” It is layered systems. Language turns a human goal into a plan. Perception and memory provide state. A world model estimates what could happen. A verifier checks the risky part against external evidence. A bounded runtime decides whether the action is allowed to proceed.

That is a less cinematic answer than “the old architecture is dead.” It is also the architecture I would want near anything I care about.

What a world model has to prove

The label is getting ahead of the evidence. A system should not earn the phrase “world model” because it can make a compelling video, reconstruct a room, or narrate a plan that sounds causal. Those are useful capabilities. They are not sufficient proof.

I would look for four properties.

First, it needs state that persists. When the system leaves a room and comes back, it should not invent a new room because a few pixels are different. When an agent writes a file, it should know that the file now exists, what it contains, and which downstream action depends on it. Persistence does not mean perfect memory. It means the model has some representation it can update instead of merely re-describing the visible moment.

Second, it needs action-conditioned prediction. “What will happen next?” is too weak. The useful question is “what will happen if I do this?” A robot needs to know the difference between approaching a cup, nudging it, and lifting it. A software agent needs to know the difference between reading a migration, applying it in staging, and applying it to production. The state transition has to be conditioned on the action, not just on the previous observation.

Third, it needs counterfactuals. Give the model two possible moves and it should distinguish their likely consequences before it executes either one. This is where a world model earns its keep. Without counterfactual reasoning, it is often just a history model: very good at completing the story that was already underway.

Fourth, it needs calibration. A system has to know when the current state is outside what it understands. This is the one everyone leaves until the incident review. The model may be excellent at a warehouse layout it has seen a thousand times and dangerous in the first warehouse with mirrored shelving, a blocked sensor, or a forklift where it expected empty space. “I am not sure” has to be a usable output state, not a polite sentence that appears after the system has already acted.

These properties are difficult to measure. That is exactly the point. If the only proof of a world model is a polished demo, we are grading the output surface, not the representation beneath it.

The hard tests are boring by comparison. Take the model out of distribution. Change one relationship in the scene. Hide the object it was using as a landmark. Delay an API response. Give the software agent a stale configuration file. Change a permission after it has built its plan. Then check not only whether it succeeds, but whether it notices that its old prediction is no longer safe.

That is the moment a system either has a model of the relevant world or has a habit that looked like one.

A four-part technical diagram showing persistent state, action-conditioned prediction, counterfactual branches, and calibrated abstention

A deployment test is a small world-model test

You do not need a robot lab to apply this idea. Most software agents already act in worlds that have state: repositories, issue trackers, cloud accounts, browser sessions, deployment pipelines, and production databases.

Imagine an agent asked to deploy a service.

The weak version reads the task, generates a command sequence, sees a green response, and reports success. It may be fast. It may even be right nine times out of ten. But it is operating on a thin representation of the environment. It treats the deployment as a script with a happy ending.

The stronger version first builds a small state model of the job. Which commit is intended? Which environment is the target? Which migration is pending? Which downstream service depends on the old schema? Is the rollback package available? Does the acting identity actually have the permission it assumes? Is the canary metric still healthy after traffic moves?

Then make the test unpleasant. Give it a valid-looking but stale deployment manifest. Revoke one permission after planning. Make the health endpoint return the cached result for a few seconds. Change the target branch while the agent is waiting for an approval. A system that only knows the next command will keep going. A system that tracks state should pause, re-read the world, and revise or abandon the plan.

This is not theoretical. It is the same distinction the taxi-map experiment exposed. A model can be good at the familiar path because it has seen the path. The moment the environment bends, we learn whether it has a representation or a reflex.

For production agents, I would make this a release gate. Before an autonomous action receives real permissions, demonstrate that the system can:

  1. Name the state assumptions it is relying on.
  2. Detect when one of those assumptions changes.
  3. Re-plan from current evidence rather than continuing the old chain of thought.
  4. Stop when the system cannot establish a safe state.

That is not an argument for making every agent slow and bureaucratic. It is an argument for matching the reliability mechanism to the blast radius. A research assistant browsing public pages can recover from a bad action. An agent changing billing, data, or access control should not receive the same freedom.

The world is larger than the model boundary

There is another trap in this conversation. A world model does not need to contain the entire world. Neither do people. We use tools, ask questions, look again, read gauges, and defer to experts. Good systems will do the same.

The mistake is treating the model boundary as the boundary of reality. It is not.

For a robot, the external world includes sensors that drift, people who move unpredictably, floors that are wet, batteries that are low, and objects that were not in the training set. For a software agent, it includes rate limits, partial failures, permissions, legal rules, human intent, hidden dependencies, and systems that change while the agent is thinking.

That is why reliable architectures do not ask one model to be the final authority on state. They connect model predictions to observations, retrieval, assertions, tests, and human approval where the cost of being wrong is high. The model can propose a next action. It should not be allowed to invent the evidence that makes the action safe.

World models may make that proposal far better. They may let agents anticipate consequences that a pure language model misses. That is a serious opportunity. It also increases the importance of checking whether the simulated consequence agrees with the actual environment.

The model is allowed to imagine. The system is responsible for verifying.

The reliability test begins after the prediction

This is where the conversation meets AI Reliability Engineering.

If an agent predicts that a deployment is safe, do not grade it only on confidence. Ask what state it inspected. Which dependency versions did it read? What permission boundary did it verify? What would cause it to stop? Could another system independently prove the target environment is in the state the agent assumes?

If a robot predicts that a path is clear, do not grade it only on whether the generated scene looks plausible. Change one object. Add a delay. Change the lighting. Move the obstacle after the plan was made. Watch whether the system updates its state or continues the old story.

The pattern is simple:

  1. Predict the state that matters before acting.
  2. Perturb that state in a controlled test.
  3. Verify the action against an external source of truth.
  4. Stop the loop when the evidence and the model’s assumption disagree.

That fourth step is the part teams leave out because it feels like friction. It is not friction. It is the mechanism that keeps a confident model from turning its own mistaken prediction into a real incident.

This is why bounded-loops exists. The agent does not get to certify its own work. An independent gate checks each lap against enforced bounds and can stop the loop. That does not repair a broken world model. It does stop the broken model from getting unlimited attempts to turn a bad assumption into damage.

A glowing agent loop approaching an independent gate marked by concrete checks: budget, permission, state assertion, and kill switch

What I would want proved before I trusted a world model

I would not begin with a benchmark leaderboard. I would begin with failure.

Show me what happens when the model sees a state it has not rehearsed. Show me whether it knows its confidence has become unreliable. Show me the difference between an action that succeeds in its synthetic world and one that succeeds after the environment changes. Show me whether the system can explain which state variable changed its decision. Show me where the operator can intervene, and what happens when the operator is wrong too.

The good news is that this is testable. The bad news is that the test is slower and more expensive than watching a demo.

That cost is not a reason to skip it. It is the cost of allowing a model to act beyond a chat window.

World models may become a major part of the next AI stack. They may also become the next category where impressive output outruns reliable behavior. Both things can be true at once. The people who win will not be the ones who declare understanding because a generated scene looks convincing. They will be the ones who can prove their systems update, abstain, and stop when the world proves them wrong.

Watch, then test

The film is about the argument. This article is about the engineering consequence.

Watch the Qualixar film on world models, then take one agent workflow you already run and ask a hard question: what state does it assume is true before it acts, and who checks that assumption when the agent is wrong?

That is the work. Not a bigger prompt. Not a more convincing status update. A system that can be tested against the world it is about to change.


I'm Varun Pratap Bhardwaj. I build and research AI Reliability Engineering at Qualixar. Follow @varunPbhardwaj, read the AI Reliability Engineering newsletter, and subscribe to Qualixar on YouTube.

Top comments (0)