4 min read

Using a Netcode Pattern to Contain AI Systems


The first time I built the pattern I now use to think about AI, it had nothing to do with AI. It was multiplayer netcode, in grad school, a decade ago, and the enemy was latency.

The problem a networked game hands you is a contradiction. The network is slow and unreliable, but the player has to feel instant response, and every player has to agree on one shared world. Fast, and consistent, over a medium that is neither. The solution I ended up with had three moves, and I have been rebuilding those same three moves ever since, in domains that look nothing like a game.

The original netcode design

Optimism at the edge. If you wait for the server to confirm every action, the game feels like wading through syrup. So the client predicts: it shows the result of your input immediately and assumes the server will agree. The edge is fast because it’s optimistic — it acts before it’s allowed to.

Authority at the core. All that optimism would fracture into a different game on every screen if nothing were in charge. So one place — the server — owns the truth. Real state changes happen there, in one atomic location, and everyone else is downstream of it. The core is slow, singular, and authoritative.

Reconciliation between them. The optimistic edge and the authoritative core will disagree — the client guessed, the server knows. When they do, you don’t snap the client violently to the truth; you converge it, easing from the guess toward the authority over a few frames so the correction doesn’t jar. And underneath it all runs an ordered log of events, so the truth is not just current but replayable.

That combination kept the game responsive without allowing each client to invent its own state.

An optimistic edge proposes to an authoritative core; the core corrects the edge back; an ordered event log runs underneath both. The edge is a game client or an AI model; the core is a game server or deterministic code.

The same separation is useful when an AI component proposes work that the surrounding system must validate and record.

Mapping the pattern to AI

Years later I started building systems with AI in them, and I kept reaching for a structure that felt oddly familiar. It took me embarrassingly long to notice it was the netcode loop.

The way I think AI should sit inside a serious system uses a similar division of responsibility:

  • AI is the optimistic edge. Let it draft, suggest, predict, autocomplete, propose. Let it be fast and feel instant. That’s what it’s good at, and — like client prediction — it’s allowed to act before it’s confirmed, precisely because it’s not the thing that commits.
  • Deterministic code is the authoritative core. Validation, execution, the actual write, the money, the irreversible action — those live in one checkable place that owns the truth. The model doesn’t get to be authoritative any more than a game client does.
  • Reconciliation is where they meet. When the optimistic AI output and the deterministic check disagree, the check wins — but gracefully. Reject with a reason, ask for a confirmation, fall back to a safe default. Converge, don’t crash.
  • And the event log is the audit trail — what the AI actually did and why, replayable after the fact, the same ordered history that let me record and replay a game.

I did not derive this from first principles about language models. I imported it, whole, from a game where the network would humiliate me the instant I trusted the wrong layer.

Why the analogy is useful

The analogy is useful because games make disagreement visible immediately.

In netcode the network is a merciless tutor. Latency and loss are present in every single frame; there is no happy path where they go away. So you cannot get away with letting the optimistic edge be authoritative — the moment you do, two players’ worlds diverge and the bug is on screen, immediately, every time. The environment forces the discipline on you.

Model failures are intermittent, so an AI prototype can appear reliable even when generated output flows directly into an action. The disagreement may not surface until production sees a case the demos missed. That delayed feedback makes it easier to omit validation, authority, and reconciliation than it ever was in a networked game.

AI prototypes can hide the same disagreement for much longer, especially when plausible output passes as valid state.

Where the analogy stops

I keep finding this loop everywhere now, and I no longer think that’s a coincidence. Optimistic UI over an authoritative API. A single writer for the truth in a data system, with everything else reading. Caches reconciled against a source of record. It’s the general answer to a question that comes up in almost every system worth building: how do you feel fast while staying correct?

The answer, every time, has the same skeleton — an optimistic edge for speed, an authoritative core for truth, a reconciliation loop for the disagreement, and a log so the truth can be replayed. I didn’t learn to distrust the fast layer from AI. I learned it from a game where the network would prove me wrong within a frame if I trusted it. The domain changed. The loop didn’t.

More on Distributed Systems What Multiplayer Netcode Taught Me About Distributed Systems →