Reality-adjacent thoughts on software, games, and whatever I’m building.
Part 3: the agent that beat a random player every game loses every game to a few hundred lines of hand-written priorities. Stranger: a near-perfect imitation of those priorities still loses four games in five. The cause is not the learning, the data, or the network. It is how the network was allowed to answer.
Part 2: before a machine can learn a game, something has to run the game. Building the engine that plays anything, meeting Jaipur (the two-player trading duel that carries this series), and bolting an off-the-shelf learner onto it to watch random flailing become recognizable play. Plus the first war stories: an agent that found the one legal way to do nothing forever.
Opening a series about a question that won't leave me alone: if you handed a machine a board game's instruction manual and the contents of its box, could it teach itself to play well? Any game, with no game-specific code. Seventy-five years of game-playing AI says the pieces finally exist. The catch is how you tell the machine the rules.
Coding agents can’t see motion: they write an animation, watch the tests pass, and never notice it looks broken. Here’s a trick that gives an agent motion perception: capture the animation as a timed burst, tile it into one labeled contact sheet, and hand it back as a single image.
I built an interactive tool to trace Ontario’s $244B budget as deep as the public data allows, tagging every number as verified, a government black box, missing from public data, or classified. Here’s what I found, and why AI changes what civic analysis can do.
A RuboCop cop I proposed, Metrics/SingleLineComplexity, that applies the ABC metric per line to measure "complexity density" and flag the individual lines packing in too much logic.