# A 111-Move Chess Match Taught Us Why Coding Agents Need Ground Truth > Source: > Published: 2026-08-16 00:00:00+00:00 Most AI-agent demos look impressive for the first few turns. Ask a model to write a component, summarize a codebase, or propose a refactor, and it can sound remarkably competent. But the harder question is what happens after fifty turns, after the user changes a requirement, after a test fails, after an earlier assumption turns out to be wrong, or after the agent needs to reason about a state it can no longer safely hold in its context window. This week, we accidentally found a compact answer through a 111-move chess game. Rope Notes was playing against Gemini through a conversation. What began as a casual test turned into a long tactical game: captures, queen trades, endgame conversion, repetition risks, stalemate traps, promotion, and eventually a forced mate. Rope Notes won. But the interesting part was not the result. The interesting part was that, at several points in the game, Gemini described a board state or tactical continuation that did not match the actual position. Rope Notes caught those errors because it was not relying only on its own running narrative of the game. It had tools. A language model can maintain a surprising amount of context. It can recall moves, explain tactical ideas, and produce plausible analysis for a long time. But plausible is not the same as correct. Chess is unforgiving about this distinction. A single missing pawn, an overlooked defender, or a piece remembered on the wrong square can make an entire paragraph of analysis meaningless. A move that sounds forcing may be illegal. A "hanging" rook may be protected. A claimed checkmate may leave one legal escape square. During the match, Rope Notes repeatedly treated the conversation as a hypothesis rather than ground truth. Before committing to a move, it could: That is a much more reliable loop than "the model thinks it remembers where the pieces are." By the end of the game, Black had promoted and reached a queen-and-rook versus bare-king position. Gemini proposed candidate finishing moves, including lines that looked natural in prose but did not produce the cleanest forced result. Rope Notes checked the actual position. The engine found the mating sequence: ``` 109... Rd2 110. Ke4 Kf6 111. Kf4 Rd4# ``` And then, crucially, it did not simply announce that the game was over because the engine evaluation said "mate." It applied the final move and checked the resulting state: ``` checkmate: true legalmovecount: 0 ``` That is the distinction we care about. The agent did not merely say the position was checkmate. It asked a deterministic system whether White had any legal move left. The answer was no. We are not building Rope Notes to play chess. We are building it because software engineering has the same state problem, only messier. A coding agent does not work on a clean, static prompt. It works inside a moving system: A browser chatbot can describe what the code should be doing. But an engineering agent needs to know what the codebase is doing right now. That requires ground truth. | In chess | In a real project | |---|---| | Board state | Workspace and file state | | Legal moves | Allowed edits and valid tool actions | | Engine evaluation | Compiler, analyzer, linter, and test output | | Checkmate verification | Verified build, test, or task-completion condition | | Repetition/stalemate checks | Git conflicts, loops, no-op edits, and unsafe terminal states | The model supplies reasoning. The tools supply reality. This is the design principle behind Rope Notes. An agent should not be trusted because it sounds certain. It should be useful because it can interrogate the real workspace: The agent proposes. The environment verifies. The developer stays in control. That is also why Rope Notes is local-first. Your project tree, editor buffers, diagnostics, permissions, and review workflow are not incidental details around a chatbox. They are the state an engineering agent must respect. The industry often treats agentic behavior as a measure of how long a model can operate without a human touching it. We think that is the wrong metric. The useful question is not: It is: In the chess match, Rope Notes occasionally had to correct its own earlier analysis too. That is not a weakness. It is precisely why deterministic tool calls matter. A grounded agent should be willing to say: the board says otherwise. For coding, the equivalent is even more valuable: That is how an AI assistant becomes an engineering tool rather than a confident narrator. The 111-move match was a fun experiment. It was also a small, concrete demonstration of a larger idea. Long-horizon work is not solved by asking a model to remember more. It is solved by giving the model a structured workspace, deterministic tools, explicit boundaries, and a way to verify every important claim against the current state. In chess, that means legal moves and a canonical board. In software, that means your actual project. Rope Notes is built for that second problem.