How Magnus Carlsen's App Taught AI to Explain

There's a telling moment in Kaggle's LLM Chess Tournament—the one Magnus Carlsen apparently watched from his Oslo office while providing commentary—where Grok stumbles into the Poison Pawn variation and then promptly falls apart. It's funny in the way a lot of AI demos are funny: impressive surface, crumbling foundation. The model knows what the Poison Pawn variation is. It just can't actually play chess.

This is the problem that Anant Dole and Asbjørn Steinskog, engineers at Play Magnus, set out to solve. Not "can we make an LLM play chess better" but something more interesting: "can we make an LLM explain chess well, given that it can't actually play?" Their answer, presented at the AI Engineer conference, is a lesson in what the AI industry still largely refuses to absorb—that knowing a model's failure mode is the beginning of good design, not an obstacle to it.

The Division of Labor

The architecture they landed on is almost aggressively sensible. Stockfish—the open-source chess engine that has been the gold standard for computer chess for years—handles position evaluation. It tells you what the best move is. A separate layer of custom detectors analyzes the position for tactical and positional themes: knight forks, pins, skewers, doubled pawns, structural weaknesses. A third component, Maya (from a University of Toronto research project), adds a human-probability layer—predicting what moves players at different rating levels are likely to find, so the system can flag moves that are both objectively brilliant and statistically rare for your skill tier.

The LLM enters only at the end. Its job, as Steinskog put it, is "only to translate this information into English, because we really don't want it to try to figure out too much on its own, because it quickly leads to hallucination. It still does, but we want everything to be grounded in the information that we give it."

That framing—the LLM as translator, not reasoner—is worth sitting with. It's a direct repudiation of the instinct to point a language model at a problem and trust it to figure things out. The Play Magnus team essentially pre-solved the chess cognition problem with purpose-built tools, then handed the output to the LLM as a structured brief. The model's job is closer to a copy editor than a grandmaster.

The result is commentary that can tell you not just that a move was bad, but why: your opponent played F5 threatening to trap your queen, but you can escape by capturing the central pawn because it defends the key square. That's the difference between a stockfish eval bar (useful to nobody learning chess) and an actual explanation.

Why LLMs Can't Just... Play Chess

There's a historical footnote here worth preserving. Claude Shannon—the information theorist, not the Anthropic model, though Steinskog acknowledged the coincidence with evident pleasure—wrote his foundational paper on computer chess in 1949. He proposed two types of engines: brute-force exhaustive search (Type A) and selective, intuition-like search (Type B). He assumed Type B would win, because computers weren't powerful enough for brute force. Then computers got fast, Type A scaled, and Deep Blue beat Kasparov in 1997 without any intuition whatsoever.

The neural network revival came later, via AlphaGo and AlphaZero, because Go's branching factor is too enormous even for modern hardware—you need something like selective attention. DeepMind eventually trained a transformer on millions of Stockfish evaluations and got grandmaster-level chess play. But here's the thing: that transformer was trained to predict board evaluations, not language. It can play chess; it cannot explain chess. The gap between doing and explaining isn't trivially closed by pointing a language model at the board.

LLMs trained on text have absorbed chess notation, chess concepts, chess history. They can produce text that looks like chess commentary. But they hallucinate moves that are illegal, miss obvious threats, and lose games that any 1200-rated human would win. The architecture of transformers isn't the issue—it's what they were trained to predict. Language models predict tokens. Chess requires calculating consequences.

The Feedback Loop That Runs Itself (Mostly)

The more novel part of what Dole and Steinskog built is the improvement pipeline—which is where things get genuinely interesting from an infrastructure standpoint.

When a user flags a piece of commentary as bad, the event doesn't just go into a database for a human to review next Tuesday. It posts to Slack and gets injected into a running Claude Code session via Channels, a new MCP (Model Context Protocol) feature in research preview. Claude receives the position, the generated commentary, and a "triage skill" that outlines the investigative process it should follow. It can modify prompts, adjust or create new detectors, regenerate the commentary, verify its own work—and then ask questions back through Slack.

During the live demo, Dole flagged a piece of commentary from his phone as bad. Claude started investigating. While the audience was watching another slide, Claude had already posted in Slack: "Looking into this now. Quick question: what specifically feels wrong about the commentary?" Dole's response was essentially that nothing was wrong—he'd just been testing. "You're absolutely right," he told the audience. "Nothing wrong."

Which is either a successful demo or a mildly awkward one, depending on your perspective. The system worked correctly—it investigated, found no issue, and asked a clarifying question instead of immediately making changes. That's actually the right behavior for a human-in-the-loop agent. The joke writes itself, but the engineering point is valid.

This kind of feedback architecture—user complaint → automated investigation → human sign-off on proposed fix → PR merge—is becoming a recognizable pattern in production AI systems. The human doesn't disappear from the loop; they just move from doing all the work to reviewing and approving it. Whether that's an improvement depends on how much you trust the agent's investigative judgment.

The Latency Math

For a consumer app, all of this has to be fast. Chess players aren't waiting for a loading spinner after each move. The team is targeting sub-three-second end-to-end latency, which they're hitting with Gemini Flash—time to first token around one second, full response averaging three seconds. They've tested Claude (with extended thinking) and GPT-4o mini; neither hits the same combination of speed and accuracy.

The eval numbers are instructive: Gemini Flash passes about 75% of their 16 test scenarios, which cover tactical patterns, blunder identification, and hallucination resistance. Claude with more thinking budget gets to just under 60%—but with unpredictable latency. GPT-4o mini is faster but less accurate. "The analysis is not incorrect," Dole noted about the reasoning models, "but the challenge is it's unpredictable as to how long it's going to take to finish."

For a move-by-move review feature, unpredictability is a dealbreaker. They're keeping reasoning models in reserve for a future "chat with your coach" feature where users are already in a patient, conversational mindset. That's a reasonable product distinction—different interaction modes warrant different latency tolerances—but it also surfaces a real tension in deploying frontier models in consumer contexts. The most capable models are frequently the ones you can't ship.

The Harder Question

There's something the Play Magnus architecture handles well that most AI deployments don't: it has a principled answer to "what should the model not do." The LLM should not reason about chess positions. It should not invent threats that weren't identified by the detectors. It should not second-guess Stockfish. It is a translation layer, full stop.

Most AI product teams don't draw that line this explicitly, which is part of why so many AI-generated outputs feel simultaneously impressive and untrustworthy. The Play Magnus approach essentially inverts the common pattern—instead of asking the LLM to do everything and hoping it doesn't hallucinate, they've done the hard analytical work upstream and handed the model a constrained task.

As Dole put it in closing: "It's really important to separate the data pipeline from the language generation."

That principle is simple enough to fit on a slide. Executing it requires knowing your domain well enough to build the upstream machinery—the detectors, the engines, the eval suite—before you write a single prompt. It's slow and unglamorous work. Which is probably why it's not more common.

Marcus Chen-Ramirez is a senior technology correspondent at Buzzrag. He was formerly a software engineer for eight years before switching to journalism.