The authoritative server problem
The straightforward way to build a multiplayer action game is to make the server the sole authority. The client sends input — "forward is held" — the server simulates the world, and sends back the result: here is where you are now. This is correct, it is cheat-resistant, and over a local network it is invisible.
Over a 28.8k modem it is unusable. The original Quake (1996) shipped with this architecture and, on a dial-up connection, put roughly 100 to 200 milliseconds between the player pressing a key and the player's view responding. The game was not dropping frames or running slowly. It was waiting, correctly and by design, for permission to move. Quake was playable on a LAN and miserable on the internet, which in 1996 was where the players increasingly were.
Letting the client guess
QuakeWorld, released later in 1996, was John Carmack's response. He scrapped the netcode entirely and rewrote it for internet play rather than adapting the LAN design. The central change was client-side prediction: the client stops waiting. It runs the same movement simulation the server runs, applies the player's input immediately, and shows the result — then reconciles when the server's authoritative answer arrives.
Carmack described the change in his .plan file at the time: "I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change." It was. The server remained authoritative — the client's guess could be overruled, and when the guess was wrong the player got snapped to the correct position. But most of the time the guess was right, because the client was running the same physics code with the same inputs. The perceived lag on player movement went to approximately zero without giving up server authority.
Who got there first
QuakeWorld is the implementation that mattered — it was the one that spread, because id's engines were licensed and dissected across the industry, and because Carmack documented what he had done. But it was not the first. Duke Nukem 3D, whose shareware episode released on 29 January 1996, is the earliest known first-person shooter to ship client-side prediction, several months ahead of QuakeWorld.
The reason the technique is associated with QuakeWorld rather than Duke Nukem 3D is that QuakeWorld's version was explained. Carmack's .plan updates, and the later engine source releases, turned client-side prediction from a trick one studio happened to use into a documented architecture every studio could implement. The prediction-and-reconciliation model in a modern shooter's netcode is recognisably the QuakeWorld design — the client guesses, the server rules, and the disagreements are resolved quietly enough that the player never notices they were part of a negotiation.