In 1992, a Norwegian teenager named Lone Starr wrote a program that ran on a Commodore Amiga 500.
7.16 MHz processor. Half a megabyte of RAM. A single 880KB floppy disk.
What came out the other side was a full MTV-quality music video — vector-animated dancing silhouettes, synchronized to music, rendered in real time. The audience at the demoparty dropped their jaws to the floor. He was 16 years old.
I was one of those people passing that floppy around Mexico City. I also had an Amiga 500. I showed it to everyone I knew. It was called “State of the Art” by Spaceballs, and it was the most impossible thing I had ever seen a computer do.
But the story starts earlier. Before the Amiga, I had an Atari VCS.
The VCS was designed by a chip architect named Jay Miner. To make games on that machine, programmers had to race the electron gun of the CRT with their code — timing every single instruction to the exact moment the beam was resetting between scan lines. Miss that window and black bars appeared on screen. Visible. Immediate. No hiding it. The hardware didn’t send you an alert. It just showed everyone in the room that you hadn’t done the work.
That constraint produced some of the most ingenious programming ever written. There’s even a book published by MIT press about it: “Racing the Beam“
Then Jay Miner left Atari — because they wouldn’t let him build what he knew was possible — and he designed the Amiga. A machine whose custom silicon did what VCS programmers had to do manually. He had internalized the constraint so completely that his solution was a new kind of hardware. Same mind. Same philosophy. Different expression.
I watched both. I played both. And somewhere between racing the electron gun on the VCS and watching State of the Art run on the same class of machine that produced it, I absorbed something I’ve never been able to let go of:
Understand the constraint so deeply that it becomes the design.
For 30 years I forced every team I led to develop and test on the smallest viable hardware. Not as punishment. As a diagnostic. Impressive hardware masks lazy coding and bloat — the powerful machine absorbs it silently and keeps going. Small hardware has nowhere to hide it. You feel it immediately. Like a driver who knows a car is struggling to pass a truck before the speedometer says anything. Real performance is felt, not measured. No monitoring dashboard tells you what your hands and eyes already know.
AI-generated code is bloated. Terribly, consistently, obviously bloated — if you know how to feel it. And most people don’t, because they’re running it on hardware that masks the problem.
I run my production systems on a 1 vCPU, 8GB RAM server. The LLM I use for complex queries runs locally on that machine. When the code the agent produces is lazy, I feel it. And then I make the agent fix it — because I can point to exactly where the weight is, and exactly what it costs.
“AI code is bloated” is a true statement. It’s also a solvable problem — if you’re developing on hardware that won’t let you lie to yourself about it.
Jay Miner taught me that. He just didn’t know he was teaching a kid in Mexico City.
The demoscene called this the Constraint Aesthetic. I just call it the only way to build.
References
Montfort, Nick, and Ian Bogost. Racing the Beam: The Atari Video Computer System. MIT Press, 2009.
Spaceballs. State of the Art. Real-time computer graphics demo, Commodore Amiga 500. The Party 1992, Herning, Denmark.
