Retro Computing as an Honest AI Coding Test

An agent will write you a React form with login, validation, and a tasteful loading spinner before you've finished describing it. It has read a million of them. The training data for that task is so deep that the model is less writing the code than recalling the shape of it. The result is usually fine, because the millionth CRUD screen really is a lot like the previous nine hundred thousand.

The interesting question is what happens when the deep training data isn't there. So I went looking for places where it isn't.

Where the path runs out

Retro targets turn out to be an unusually clean probe. Obscure hardware, constraints nobody designs around anymore, old languages and file formats, and problems that have exactly one correct answer with no Stack Overflow thread to crib it from. There's no scaffolding to lean on and no well-worn pattern to recall. The agent either understands what it's doing or it improvises something plausible. On a retro target the difference shows up immediately, because the machine doesn't grade on a curve.

That last part is what makes it honest. On a modern web stack, a confidently wrong answer can pass review, sit in production, and fail quietly months later. On a 1986 machine the wrong answer doesn't render. You don't get to be vague, and neither does the agent.

The Juggler

The concrete case is Eric Graham's Juggler. In the autumn of 1986 he raytraced a chrome figure juggling three mirrored balls above a checkerboard floor and ran the frames on a stock Amiga 1000, a 512K machine running at about 7 MHz that spent roughly an hour on each image ^{[R3] [R4]}. Commodore's people reportedly assumed it was a hoax rendered on a mainframe ^[R4]. The renderer grew into the commercial raytracer Sculpt 3D the next year, and the animation circulated on user-group disks long after ^[R3]. When AlphaPixel recovered and released the original C source, scene files, and media in 2026 ^{[R1] [R2]}, I spent a weekend pointing agentic tooling at it to see whether a current model could take that Amiga C and produce something that runs in a browser. What they released is a leaner raytracer than the one behind the finished animation, but the scene files and the core of the approach are there ^[R1].

It can. The reconstruction is a single index.html that parses the original .dat scene descriptions directly and runs with no build step, with a Classic Source profile that preserves the original HAM output and its quirks alongside modern profiles that layer on soft shadows, ambient occlusion, depth of field, and anti-aliasing. Raytracing runs on the CPU with a BVH to make it tractable and web workers so the page stays alive while it renders. The original rendering behaviour survives the translation closely enough to put the two side by side and compare them.

That's the part it got right, and it's genuinely impressive. The part it got wrong is more instructive. The agent was confident about Amiga capabilities the Amiga did not have. It reached for colour behaviour that assumed a modern framebuffer, where every pixel simply names its own colour, because a modern framebuffer is what almost all of its training data describes. It had to be walked back to what HAM actually does: instead of naming a colour, most pixels modify just one of the red, green, or blue channels of the pixel before them and hold the other two, which is how the Amiga put all 4096 of its colours on screen at once and why a sharp colour edge smears into the mode's tell-tale fringing ^[R5]. You cannot reason about that correctly by analogy to anything current. The model knew the words. It did not know the machine.

GlyphBlaster, where almost-right is just wrong

The second probe was lower-level and less forgiving. GlyphBlaster rebuilds images out of text glyphs, not as a cheap ASCII filter but as a rendering process: characters become marks, strokes, and texture, placed by image sampling and staged refinement. There's a fast scanline mode and a slower painterly one that builds from broad forms down to fine detail.

Pixel-level rendering is a domain where being almost right is identical to being wrong. A sampling step that's off by half a cell, an error-diffusion term with the sign flipped, a refinement loop that stops one pass too early: each produces output that looks like it's working and isn't. The agent's confidence stayed serenely high through all of it. It wrote the off-by-half version with exactly the same fluency it later wrote the correct one. Nothing in the tone of the code told me which was which. The screen told me, because the marks landed in the wrong places, and I could see it.

This is the plausibility problem again, the one I keep coming back to, except that rendering makes it impossible to miss. On a data pipeline a plausible-but-wrong transformation can hide behind a number that looks reasonable. On a canvas it's just visibly broken, and visibly broken is a gift. You learn faster from a failure you can see than from one you have to go looking for.

The fun is the point, not the excuse

I want to give this its own space without apologising for it. Building a raytracer for a 1986 machine with a 2026 agent is the most fun I've had in months, and the fun is not incidental to the exercise. A machine with 512K of memory will not let you paper over a sloppy approach, so it forces both you and the agent to be specific about what you're actually doing. There's a craft pleasure in that, the same pleasure as making an old format and a new browser agree, and it's hard to explain to anyone who hasn't sat up too late getting a checkerboard floor to reflect correctly.

The constraints are clarifying in a way that a generous modern environment never is.

It also happens to be the best calibration exercise I know. After the Juggler and GlyphBlaster I have a much sharper sense of where this agent is recalling and where it's reasoning, and that sense transfers directly to the work that pays, where the failures are subtler and the stakes are higher.

What it actually teaches

The lesson isn't "agents are bad at old computers." They're often remarkably good, and the reconstruction works. The lesson is about the shape of the competence. On the well-documented path the agent is recalling a pattern, and recall is fast, fluent, and usually correct. Off that path it's reasoning from incomplete knowledge and filling the gaps with the most statistically likely nearby thing, which on unfamiliar hardware is frequently a capability that doesn't exist. Both modes read identically in the output. The only way to tell them apart is to work somewhere the wrong answer can't hide.

So if you want to know what your agent genuinely understands rather than what it can fluently reproduce, take it somewhere with thin training data and an unforgiving test. Retro computing is that somewhere. You'll map the edges of the model's real knowledge, you'll get better at directing it on the work that matters, and you'll enjoy yourself more than the exercise has any right to allow.

_{Retro Computing as an Honest AI Coding Test · July 2026 · A field note. The Juggler reconstruction and GlyphBlaster are my own projects; the original Juggler and its mid-1980s history are Eric Graham's, with source recovered and published by AlphaPixel.}