We've spent a lot of hours inside Unreal Engine, and we've spent the last couple of years building products with language models in them. The second one keeps reminding us of the first, usually in ways that make us uncomfortable.

Here's the thing game engines teach you within about a week: you have sixteen milliseconds. That's one frame at sixty frames per second. Everything — input, physics, animation, rendering — has to fit inside it. Go over, and the player doesn't read a nice error message. They just feel that something is wrong, and they can't tell you why.

Nobody gives AI features a latency budget

Now think about the last AI feature you used. What was its budget? Not "how fast was it" — what number was it designed against?

In most products the honest answer is that there isn't one. The feature takes as long as the model takes, a spinner covers the gap, and everyone accepts it because the output is impressive. We've collectively decided that intelligence buys you unlimited time.

It doesn't. It buys you some time, and the amount is much smaller than we assume. People will wait a long while for something they explicitly asked for and can see progress on. They will not wait at all for something that should have been instant — an autocomplete, a suggestion, a validation.

The lesson isn't that AI needs to be faster. It's that different interactions have wildly different budgets, and most products only have one.

Games solved this with prediction

Multiplayer shooters can't wait for the server either. The solution has been the same for two decades: predict locally, show the result immediately, reconcile when the truth arrives. You pull the trigger, your client shows the shot instantly, and the server confirms or corrects it a moment later.

Most of the time, prediction is right and you never notice. Occasionally it's wrong and you see a small correction. The trade is deliberate: a rare visible correction beats constant unavoidable lag.

Very few AI products do this. We could:

  • Show a fast local guess while the model thinks, then reconcile.
  • Start rendering structure before the content arrives, so the shape of the answer appears immediately.
  • Decide which interactions are allowed to be slow, and defend the rest.
  • Treat a spinner as an admission of defeat, not a design pattern.

The uncomfortable part

Game developers accept a hard constraint and design within it. In AI products we mostly do the reverse — we take whatever latency the model gives us and design an interface that apologises for it.

We're not claiming we've solved this. We're building AI tools right now that are, in places, slower than we'd like. But we've started asking the game-engine question about every interaction: what's the budget here, and what happens if we blow it?

It's a better question than "is the output good," because the output can be excellent and the feature can still feel broken.