"Unbeatable" is a testable claim, not a marketing word. Before that word goes anywhere near the tic-tac-toe page, the shipped AI has to survive a headless self-play harness — the same functions the browser runs, played thousands of times with no human at the keyboard. Here is what that harness measured, including the part that didn't look good at first.

The counterintuitive result

A tic-tac-toe AI with an 87% win rate still lost games that the full-depth engine never would. "It's minimax, so it's unbeatable" is true at exactly one depth setting — and the only way to find which is to run every depth and count the losses.

The numbers

Against 1,000 games of a random-move opponent, the AI went 825 wins, 175 draws, 0 losses. Against 200 games of the AI playing a perfect copy of itself, every game ended in a draw — the correct result for perfect tic-tac-toe play, and the harder claim to satisfy. Across both runs, 1,200 games total, the loss count is 0. That is the number the word "unbeatable" is actually standing on.

The harness

The benchmark is headless self-play: the exact move-selection functions from the shipped page, imported into a script with no DOM and no human, playing thousands of games back to back. A benchmark written against a re-implementation of the algorithm proves the algorithm is sound in theory; it says nothing about the code a browser actually executes. Pulling the real functions out of the production page means the numbers describe the shipped build, not a clean-room stand-in that happens to share a name with it.

It also has to be re-runnable. A number from one afternoon of manual play-testing is an anecdote; a script that plays 1,000 games and produces the same counts every time is a measurement. Mean move time came out at about 0.3 ms across 500 sampled positions.

Depth is the proof

The shipped engine searches to depth 9 — the full game tree for a 3×3 board — which is what guarantees the zero-loss result. To find out whether that depth is necessary, the harness re-ran the same 200-game vs-random test with the search capped at each depth from 1 to 9:

The honest finding is in the depth-2 row: at a search depth of 2, the AI lost 2 of 200 games. An 87% win rate looks fine on its own, until you notice the two losses hiding next to it. Depth 9 is the only depth with a 0-loss guarantee behind it; every shallower depth is a different, weaker program that happens to share the same UI.

That is the entire argument for benchmarking instead of reasoning from the algorithm's name. "It's minimax, so it's unbeatable" is true only at one specific depth setting, and the only way to know which is to run all of them and look for the losses.

The 2048 case

Tic-tac-toe has a small enough state space that "unbeatable" is checkable in an absolute sense. Most games don't — 2048 has no realistic path to "solved," so the only honest claim is a measured reach-rate: 250 headless self-play games with the shipped expectimax-plus-corner-snake solver.

A strength profile, not a single number — and one that would be indistinguishable from a coin flip if I'd run it 10 times instead of 250.

Reproduce it yourself

The harness is public and seeded, so runs are deterministic. Each file copies the shipped game code verbatim and drives it headlessly:

The benchmark harness (public gist)

node tictactoe-benchmark.mjs   # 549,945 -> 36,528 nodes, 0 losses, depth-2 loses 2
node 2048-benchmark.mjs        # reach-rate profile

The deterministic numbers (node counts, 0 losses at full depth, "only depth 2 loses") reproduce to the exact digit. The stochastic ones (win/draw split, 2048 reach %) reproduce as the same profile with seed-dependent variance. I also included the one number that didn't cleanly reproduce — a Color Lines pathfinding stat that turned out to be board-sampling-dependent — and documented why, rather than curve-fitting to hit it.

The rule this enforces

Benchmark before you publish a number. Any performance or strength claim has to come from a measurement that can be re-run, not a description of what the algorithm should do in theory. The depth-2 result is exactly the kind of thing that rule is for — a plausible-sounding claim ("it's minimax, it can't lose") that turns out to be depth-dependent, and would have shipped wrong without a script that actually played the games.

This was originally published on the LK Forge blog, where the commit chart is interactive and you can play the AI games it talks about.

Between June 5 and July 3, 2026, I took an empty domain to 26 repositories, 1,549 commits, and 335 live pages — one developer, working with Claude Code. The interesting part isn't the volume. It's which failure modes showed up, because none of them were the ones the AI-coding debate argues about.

The numbers

Commit cadence: ~53/day average, peak 122 on June 20, exactly one zero-commit day in the sprint. The two heaviest days at the tail (114 each) were a site-wide URL-structure migration — which is itself one of the failure stories below.

The setup

Deliberately boring: one developer, Claude Code in the terminal, git for everything, static-first architecture. Games and tools are self-contained repos of vanilla HTML/CSS/JS; the hub site is Astro. Everything deploys to Cloudflare Workers with static assets at the edge — no backend, no database, nothing to babysit at 3am.

Every session ran the same loop: describe the goal, let the model plan and build, review the diff, make it verify its own work against the live site, commit. That verification step is what earns its keep — every failure below was caught by a check, not by luck.

What the pipeline was genuinely good at

Working classical-AI engines, first try or close. The 2048 solver is real expectimax search with a corner-snake heuristic and adaptive depth. Before publishing any performance number, I ran the exact production code through 250 headless self-play games: it reaches the 2048 tile in 69.6% of games at ~0.5ms per move. The tic-tac-toe opponent is minimax with alpha-beta; the pathfinding in Color Lines is BFS. Textbook algorithms, correctly implemented, shipped in days. That part of the hype is real.

Volume with consistency. 335 pages sharing one brand system, one URL convention, one schema pattern. Once a convention was written into a project memory file, the model applied it across dozens of pages without drift. Those memory files turned out to be the highest-leverage artifact in the whole pipeline.

Audits at a depth a human won't sustain. Full link-graph crawls, redirect-chain verification across hundreds of URLs, per-page canonical checks against live HTTP. The model does the 400-URL tedium without getting bored — which matters, because tedium is where site-wide bugs hide.

What actually broke

Not one failure was a syntax error, a broken build, or code that didn't run. Every real problem was structural — invisible in any single diff, only visible when you look at the whole system.

1. The pipeline competed with itself

Asked for a word-tools hub, the pipeline built one — at /word-tools/, while the existing tools lived under /tools/. Two pages on the same domain targeting the same queries: textbook SEO cannibalization, self-inflicted. Search Console showed both URLs impressing for the same terms before I consolidated with a 301. Each page was locally correct; nobody was watching the query-level picture.

Lesson: the model optimizes the page you asked for, not the site you already have.

2. Twenty-six repos, two URL conventions, weeks of cleanup

Some tools were built as flat files (page.html), others as directories (page/index.html). On Cloudflare's asset serving those get opposite trailing-slash behavior — so the site accumulated canonical mismatches, two-hop redirect chains, and Search Console redirect errors. The fix consumed the two biggest commit days of the sprint and produced a written URL convention plus a pre-deploy crawl checker that now gates every release.

Lesson: conventions the model must follow have to be written before repo #2, not after repo #20.

3. Source and production drifted apart silently

Game repos are mirrored into the hub site for deployment. Over weeks, SEO improvements were applied to the production mirror and never back-ported to source. The trap armed itself: the obvious "sync" — copy source over mirror — would have silently destroyed live metadata. It was caught only because a diff-before-copy check is now mandatory.

Lesson: any two copies of the same file will diverge, and the AI won't notice unless a check forces the comparison.

4. The verification tools lied too

The first link-graph audit reported a wave of orphaned pages. False alarm: it compared absolute URLs against unresolved relative hrefs. A later canonical audit reported 123 mismatches — also false, because the checker assumed file paths equal serving paths, and the CDN serves clean URLs. In both cases the audit tooling — also AI-written — had the bug, and acting on its output would have "fixed" a healthy site into a broken one. Both caught the same way: probe the live site before believing static analysis.

Lesson: verify the verifier. An AI-written check inherits every blind spot of the AI that wrote it.

The economics: 93% of the cost was re-reading, not writing

The sprint produced 44 working sessions and 826MB of transcripts. When I audited the token bill, the headline wasn't generation cost: roughly 93% of token consumption was cached context being re-read, turn after turn, inside marathon sessions that should have been split up.

The mechanics are mundane. A long session accumulates giant context; every subsequent turn re-reads it; a session that drifts across three unrelated tasks pays the full history of tasks one and two as a tax on task three. The model never complains, so nothing forces you to notice.

The fix cost nothing: clear context between tasks, keep durable knowledge in small memory files, treat "one session = one task" as the default. If you run an AI coding workflow and have never audited where the tokens actually go, that single check is probably worth more than any prompt engineering.

What it earned (honest version)

Over the last 28 days the site drew 207 clicks from 7,320 impressions across 257 pages with search data. For a domain about five weeks old, that's a normal, healthy trajectory — and nobody's growth-hack screenshot.

The detail worth reporting: the single biggest click-earner after the homepage is the 2048 game with the visible AI solver — the page where the most genuine engineering lives. Search demand followed the depth, not the page count. 300 thin pages didn't beat one page with something real on it.

The rules that survived

Every one exists because its absence caused a real incident above. That's the only rule-making process that works.

1. Benchmark before you publish a number. If it isn't measured, it doesn't ship.

2. Diff before you copy. No exceptions for "they should be identical."

3. Probe live before believing static analysis. An audit result is a hypothesis until production confirms it over HTTP.

4. Write conventions down before scaling them — in a memory file the model loads every session, not in your head.

5. One session, one task. Context is the real cost center.

6. Check the whole site, not the diff. Cannibalization, drift, and convention splits are invisible at diff level.

The live version, the interactive commit chart, and the AI games are at lkforge.com. The 2048 solver writeup with the full benchmark is here.