Legibility Used to Be Free

An Altair 8800 in the browser, and what it says about machines that hide everything.

Illustration for Legibility Used to Be Free
legibility-used-to-be-free The Altair 8800 could not hide its own state; it leaked into a nearby radio. A browser front panel, 51 years on, beside a model that hides everything. altair 8800, front panel, legibility, interpretability, tiny basic, intel 8080, retro computing, llm opacity

In 1975 a man in California set a transistor radio next to his new computer, hit run, and heard it. The Altair 8800 leaked so much of itself into the air that the radio became, in his words, his first peripheral device.

TL;DR

Run the legibility audit on anything you ship that claims to explain a system. Score each row zero to two; below 4 of 10, label it illustrative or build the real one.

The New MachineI Built a Browser LLM Lab. The Hard Part Was Refusing to Fake It.

Steve Dompier had just finished assembling his kit. He wrote up what happened next for the People's Computer Company newsletter, and the account still reads like someone who cannot believe his luck: "I hit the 'run' switch on the computer and it took off sorting the same list of numbers over and over again. At the same time my radio also took off!!" The unshielded case was radiating the switching of the address bus. Different memory addresses made different tones. Within eight hours he had the machine playing music.

That is not a party trick. That is a machine so incapable of concealing its own internal state that the state escaped into a nearby radio by accident.

The story has been sitting in my head for a year. I spent much of that year on a browser page that tries to make a language model explain itself, and the contrast kept getting louder. I have spent most of a decade building speech systems whose behavior I could only ever infer from their output. I did not notice what that cost me until I put the two machines side by side.

The Machine That Could Not Hide Anything

The Altair shipped with almost nothing. The January 1975 Popular Electronics article priced the complete kit at $397 and the assembled machine at $498, and sold it on the line "the most powerful minicomputer project ever presented can be built for under $400." The Smithsonian, which has one, describes what that bought more plainly: "the minimum configuration of circuits that one could legitimately call a computer." No printer. No keyboard. No screen. 256 bytes of memory.

What it had instead was a front panel: rows of toggle switches and rows of lamps. You entered a program by flipping bits, one byte at a time, and you read the result off the lights. That is how I wrote my first program.

The switches did not glide. Each took a deliberate push and gave back a click you felt in the knuckle, eight times per byte, then deposit, then again. Dompier's line about "getting a good set of caluses on my ten input devices" stops being a joke somewhere around the hundredth flip. Your hands hurt, the case was warm, the radio beside it hissed, and the machine told you what it was doing the whole time. None of that was a metaphor. The state of the computer was a physical fact on a board in front of you, and you could put a finger on any bit of it.

Twenty-four bytes is the real size of Kill the Bit, Dean McDaniel's front-panel game from May 15, 1975. A light runs around the row and you flip the switch under it to kill it. Miss, and you get another light to deal with. The entire game is short enough to toggle in by hand, and it needs no terminal at all, because on this machine the lamps are not an accessory. They are the whole output device.

What the Lamps Actually Do

Here is the part that most browser Altairs get wrong, and the part that made me want to build one.

On real hardware the address and data lamps are wired directly to the CPU's address and data buses. They are not a display of the machine's state. They are the state, with a bulb attached. Which means that while a program runs, the lamps do not show you a tidy readout of some final value. They show you a blur, because the bus is changing millions of times a second and the lamp is just following it.

Simulating that honestly means you cannot render the lamps from a variable. You have to sample the bus every machine cycle and light each lamp by its duty cycle:

// Every bus cycle, fold this address into the running per-lamp totals.
// The lamp's brightness is the fraction of cycles in which its bit was high.
for (let i = 0; i < ADDRESS_BITS; i++) {
  this.addressDuty[i] += (address >> i) & 1;
}

Do that and a running program looks like the 1975 photographs instead of like a debugger. This is why the shortcut is so tempting: read the lamps off a variable once per frame and you get something easier to build and easier to read. You also get a lie about what the machine is doing.

The rest of the build followed the same rule. The BASIC is Li-Chen Wang's Palo Alto Tiny BASIC, assembled from source by an 8080 assembler in the same repository rather than pasted in as a prebuilt blob. A test asserts it comes out as the same 1,920 bytes every time. The CPU runs the standard 8080 diagnostics, including the strict one that checksums every flag of every instruction group. It is at frontpanel.dev, it is free, and it works on a phone.

Fifty-One Years Later, the Lamps Are Gone

The lamps did not vanish all at once, and the years in between are not a straight decline. They are a series of rebuilds. The panel went away and we wrote printf. Programs outgrew printf and we built debuggers. The interesting behavior moved into the kernel and we got strace, then eBPF; it moved across machines and we got distributed tracing. Every one of those is the same move. Something stopped showing its work, so somebody built an instrument to make it show its work again. Every layer we added bought speed and charged us visibility, and every generation has paid the difference back by hand.

Now put that machine next to the one everybody is actually using.

Dario Amodei runs a company whose entire commercial interest lies in you trusting these systems. In April 2025 he wrote that "people outside the field are often surprised and alarmed to learn that we do not understand how our own AI creations work." His framing: these systems "are grown more than they are built," their internal mechanisms "emergent rather than directly designed." Their operations, he says, "are not optimized in the slightest to be legible to humans."

Legible. That is the word, and it is the whole distance between the two machines. The Altair's interface was its internal state, so thoroughly that it broadcast that state to a radio nobody had connected to it. A language model has no equivalent surface. You get tokens. The tokens are the output of the process, not a window onto it, which is exactly why a confident wrong answer looks identical to a confident right one.

Building the Legibility Back In

Which is what the other project turned out to be. LLM Lab trains a real character-level model in your browser tab. Every honesty decision in it was an attempt to manufacture by hand what the Altair gave away for free: a machine whose insides you can watch while it works.

None of it came free. Real gradient descent in a tab produces real garbage until you add the machinery real pipelines use. The validation curve had to be allowed to climb in public while the training curve fell, because that embarrassment is the actual lesson. The attention heatmap shipped as a hand-set illustration until I reread my own design bar and went and trained a genuine 65,184-parameter transformer so the diagram would show measured weights instead of my assumptions.

The fix is the same shape as the lamps. Do not draw the picture. Sample the mechanism, in this case the actual scaled dot-product the forward pass computes, and draw whatever comes back:

// The attention the heatmap draws is the attention the model used.
for (let s = 0; s <= t; s++) {
  let dot = 0;
  for (let i = 0; i < HD; i++) dot += q[t][off + i] * k[s][off + i];
  scores[s] = dot / Math.sqrt(HD);
}
const soft = ttSoftmax(scores);   // these exact weights go to the screen

A dot product sampled off a forward pass, sixteen lamps sampled off a bus. Same discipline, fifty-one years apart. The staged diagram could only ever show me what I already believed about attention. This one is allowed to contradict me.

Every one of those was work. On the Altair it was not work. It was wiring. The machine could not help it.

The Legibility Audit

Score anything you ship that claims to show people how something works. Zero to two per row.

Question012
Where do the numbers on screen come from?Staged or hand-setComputed once, replayedComputed live, every time
Can the thing fail in front of the user?Failure is smoothed awayReachable but unexplainedReachable and explained
How far is the display from the mechanism?A separate re-implementationAn approximation of itSampled from the real thing
What can the user inspect?Final output onlySome intermediate valuesEvery layer, on demand
What does a wrong answer teach?NothingThat it was wrongWhy it was wrong

Scoring: 8 to 10, the thing is a teaching instrument. 4 to 7, it is a demo with good intentions. Below 4, it is an animation, and you should either label it illustrative or go build the real one.

What to Fix First

A low score is not a mandate to rebuild the display layer, and teams that treat it that way never start. Take the single worst row and do three things to it.

  1. Find the proxy. There is an exact line where the display stopped reading from the mechanism and started reading from something more convenient: a cached value, a summary object, a variable somebody set by hand at four in the afternoon. Until you can point at that line, you are guessing.
  2. Point it back at the mechanism. Sample the real computation and render whatever comes back, including the parts that look bad. This is usually smaller than it sounds. The lamps needed one accumulator per bit; the attention heatmap needed the softmax the model was already computing.
  3. If you cannot, say so on the surface itself. Sometimes the raw state genuinely cannot be shown, because it carries somebody else's data or the shape of your defenses. That is a legitimate answer. It is not a licence to keep the realistic-looking panel. Label it illustrative where the user can read it, or take it out.

Inherited legibility never needed a label, because it was incapable of misrepresenting anything. Manufactured legibility is fully capable of it, which is why the label is not a courtesy. It is the difference between an instrument and a decoration.

What It Costs to Fake Nothing

The bill for that standard arrives as verification, and it arrives late.

The front panel's own test suite was green while the machine was, for several people, invisible: the chassis sat below the fold on an ordinary laptop, and a cache-first service worker was handing returning visitors the previous deploy. The tests asserted the switches existed. They did exist, several hundred pixels down the page.

Worse were the assertions that could not fail. The strict 8080 diagnostic was checked by looking for the string "Tests complete", a line the diagnostic prints whether its checksums matched or not. So a run with failing instruction groups read as a pass. Another test matched any of three words the program could print, which is every possible output. Tightening that one immediately surfaced a real bug in the BASIC's output formatting. None of this is exotic; it is the ordinary way a suite rots into a number that measures its own existence.

I learned this the hard way on both projects, a year apart, in almost the same shape. A test that cannot fail and a lamp rendered from a variable are the same category of mistake. Both replace the thing with a picture of the thing. Both stay invisible until somebody who trusted the picture gets hurt by the gap.

Where the Analogy Breaks

I am not arguing that we should have kept the front panel, and the comparison has real limits worth naming.

  • The Altair's legibility was bought with uselessness. You could understand the whole machine because the whole machine did almost nothing: 256 bytes, no keyboard, and a price that only looked cheap until you priced a configuration that could do work. Legibility was not a design triumph. It was what was left over when there was no room for anything else.
  • Scale genuinely forecloses this. Nobody is toggling a frontier model in by hand, and no panel of lamps meaningfully renders billions of weights. The Altair's kind of transparency does not survive the jump in size, and pretending otherwise is nostalgia rather than argument.
  • Opaque is not permanently opaque. Interpretability is a live research field making real progress, and the same essay that admits we do not understand these systems is an argument that we could. Treating the situation as hopeless is its own kind of laziness.
  • Total legibility is itself a hazard. This is the one that took me longest to accept. The Altair could safely show you everything because everything was 256 bytes of your own program. A production system's internal state is not innocent: it holds other people's data, the prompts and weights somebody paid for, and a map of exactly where the guardrails sit. Expose all of it and you have not built a teaching instrument, you have built reconnaissance for whoever wants to attack it.

So the goal is not maximum exposure. It is deciding, deliberately, who gets to see which layer. Operators and auditors need the mechanism. Users need enough to calibrate their trust and nothing that identifies anyone else. The public needs the shape of the thing, not its keys. The Altair never had to make that call, and every honest system built since has to make it on purpose, per surface, and write the answer down.

The claim is narrower and, I think, harder to dodge. There are two kinds of legibility and we keep confusing them. The Altair had the inherited kind, which costs nothing because the machine is physically incapable of concealment. Everything since has the manufactured kind, which is a feature with an owner, a cost, and a review cycle, and which does not exist unless somebody funds it. Confusing the two is how a team ends up believing its dashboard is evidence.

The Bottom Line

Legibility used to be a side effect of a machine that could not hide anything. Now it is a feature somebody has to sit down and build. That is the whole difference between the two projects. The front panel came together over a weekend. The model page took a year of arguing with myself about staged pixels.

Inherited legibility is gone and it is not coming back. Manufactured legibility is what is left, and it only exists if someone funds it, scopes it, and defends it from the pressure to make the demo look calm. So run the legibility audit on the thing you are about to ship. Find the row where you scored a zero. Fix it, or label it illustrative. There is no third option that is honest.

And go flip the switches. frontpanel.dev works on the phone you are holding. Toggle in Kill the Bit by hand, all twenty-four bytes of it, and watch the lamps blur while it runs. Fifteen minutes with a machine that cannot lie to you will recalibrate what you accept from the ones that can.

"Legibility used to be a side effect of a machine that could not hide anything. Now it is a feature somebody has to sit down and build."

Can You See What Your System Is Doing?

I review AI and data products for the gap between what the interface shows and what the machine is actually doing.

Book a Legibility Review

Disagree? Have a War Story?

I read every reply. If you've seen this pattern play out differently, or have a counter-example that breaks my argument, I want to hear it.

Send a Reply →