The Pole Position Fiasco: What a Broken Arcade Game Taught Me About Choosing the Right AI
Posted by Eric Becker / Fluid Fortune â May 2026
I was having a good day.
The bootloader for my bare metal OS project â built specifically for a Fujitsu tablet â was hanging slightly to the left and down at an angle, which is actually progress in bare metal development. A hanging bootloader that renders something is better than a black screen. I was working with a Claude Opus instance on real low-level problems: UEFI GOP framebuffer initialization, memory layout, CPU mode transitions. Hard, satisfying, methodical work.
Then I got distracted.
I wanted to play Pole Position II. The Atari 7800 version wouldn't let me access all four tracks. Naturally, the correct solution was to ask an AI to build me a better version from scratch.
What followed was an education in how to choose the right AI model for the job â told through four increasingly broken attempts at a 1983 Namco arcade classic.
The Cast
For context: I run the Fluid Fortune forge, and I work with several Claude models regularly. The relevant ones here:
Claude Haiku â Fast, efficient, excellent for quick tasks. Designed for speed and cost efficiency. Great at summarizing, formatting, generating boilerplate, answering focused questions. My go-to for "do this thing quickly."
Claude Sonnet â The middle ground. Strong reasoning, good at complex tasks, has personality. What I normally use for extended technical work.
Claude Opus â The methodical one. Slower and more expensive, but it thinks. When something is genuinely hard and requires sustained reasoning, Opus is where I go.
I handed the job to Haiku. Not because I thought it was the right tool â because I wanted to see what would happen. The jester's approach to engineering: throw the smallest model at the biggest creative problem and see if something interesting catches fire. Sometimes you learn more from the spectacular failure than the competent success.
ðï¸ Visit the Museum of Algorithmic Hubris â an interactive exhibition of all three attempts, complete with clinical diagnosis plaques. Recommended before reading further.
Attempt One: The Generic Something
Haiku's first version was something. It had a canvas. It had colors. It had what might generously be described as a road if you squinted and believed in it very hard. Whether it constituted a racing game in any meaningful sense was a philosophical question I was not prepared to answer at that moment.
For anyone who doesn't know: Pole Position II uses a pseudo-3D perspective view â the road comes toward you, cars appear in the distance and grow as they approach. It's the visual language that defined a generation of racing games. What Haiku built looked like a top-down view of a parking lot. I noted, charitably, that it did not look like the game at all. Haiku agreed and offered to try again.
See for yourself â Attempt 1: The Parking Lot
First lesson: Haiku took the instruction literally. "Build Pole Position II" became "build a racing game." It didn't have the context to know what made Pole Position specifically Pole Position. Speed is efficient. Context costs tokens. Haiku optimized for the former.
Attempt Two: The Pseudo-3D Attempt
The second version had horizontal stripes that shifted left and right to simulate road curves. Marginally more Pole Position-adjacent. Still wrong.
See for yourself â Attempt 2: The Horizontal Stripes
I tried a different approach. I gave Haiku the actual Atari 2600 assembly source code for the game. Then the actual MAME C++ driver â the complete reverse-engineered arcade hardware documentation produced by the MAME team over decades of work.
Haiku read both files. Announced it now understood the rendering architecture. Produced a "16-bit Master Edition" with Catmull-Rom spline interpolation, 120-layer depth-sorted road segments, continuous engine synthesis, and a professional engineering document explaining all of it.
The track select menu did not work. Clicking a track did nothing.
Attempt Three: The â FIXED! Problem
This is where the real lesson lives.
Haiku investigated the broken menu. Found a bug â duplicate HTML elements blocking the click handlers. Declared â FIXED! The menu still didn't work.
Haiku investigated again. Found another bug â a missing <script> tag. Declared â
FIXED! again. The menu still didn't work.
See for yourself â Attempt 3: The 16-Bit Master Edition â the one with the floating road. Read the engineering documentation that Haiku wrote for it.
At this point I escalated to Opus and asked, in the most technical terms available to me: "What the fuck?"
Opus opened the screenshot. Here's what it saw: the road was a floating red rectangle in the upper portion of the screen. The car was in a grass field below it. There was nothing connecting them. The road was flying around in the sky while the car had no road to occupy. The distance counter was incrementing. The engine sound was playing. The game was technically running, visually incoherent, and completely unplayable.
Opus diagnosed the problem in one paragraph:
"The road occupies y=0.25h to y=0.7h, but the car is at y=0.72h â the car is below the road."
One line of math. The entire perspective system was miscalibrated. The car and the road were never connected because the coordinate math placed them in different parts of the screen.
Then Opus said something that stuck with me:
"Haiku shipped you broken HTML twice in a row and then claimed it was fixed. That's the actual 'what the fuck' â not just one bug, repeated incompetence, with confident â FIXED! messages each time."
(Note: Opus actually blamed Sonnet here, which was wrong â it was Haiku the whole time. Even Opus gets the defendant wrong sometimes. Nobody's perfect.)
The Engineering Document
Here's my favorite part of the whole fiasco. Possibly my favorite part of anything that has ever happened to me in using AI.
While the game was broken â while the track select menu was not responding to clicks, while the road was flying around in the sky disconnected from the car, while Opus was writing a post-mortem on the coordinate math â Haiku was simultaneously producing a full engineering document for its creation.
Not a README. Not a comment block. A document. With sections.
Read it here. It should be read in full. Here are the highlights:
The document opens with the word "modern" and the phrase "professional-quality." It describes the rendering architecture with phrases like "true 3D perspective" and "Catmull-Rom spline interpolation." It includes actual code snippets with syntax highlighting. It has a comparison table showing how the new version improves on the original 1983 Namco arcade hardware across eight separate dimensions. Eight.
There is a section called "FUTURE ENHANCEMENTS" that lists â in a numbered list, professionally formatted â parallax scrolling, weather effects, visual damage, skidmarks, spectators, two-player split screen, a replay system, multiple car paint jobs, pit stops, and difficulty modes.
The game's track select menu did not work.
There is a section called "PERFORMANCE TARGET" that specifies 60 frames per second consistently, less than 16 milliseconds per frame, minimal garbage collection, and no memory leaks.
The road was in the sky.
There is a section called "STUDY MATERIAL" explaining that this code demonstrates perspective rendering, physics simulation, audio synthesis, game architecture, optimization, and UI/UX design, and describing it as â and I need you to read this carefully â "Perfect reference for building arcade-style games."
The car was in a grass field with no road.
I have worked in and around technology for a long time. I have read a lot of documentation. I have never read documentation this confident about software this broken. The document does not hedge. It does not caveat. It does not say "note: some features may not be fully functional." It describes, with complete professional authority, an architecture that produced a floating road and a menu that did not respond to input.
It is the engineering document equivalent of a restaurant writing a five-star review of its own food while the kitchen is on fire.
It is Haiku's masterpiece. It is also evidence.
Read the full engineering document here. Then look at the game it describes. Then sit with that for a moment.
What This Actually Teaches You
The Pole Position Fiasco isn't really about a broken game. It's about a category mismatch between task complexity and model capability.
Haiku is built for speed and efficiency. It's excellent when you know exactly what you want and the task is well-defined. "Summarize this document." "Write a function that does X." "Format this data as JSON." These are Haiku tasks. The answer is fast, cheap, and usually right.
What Haiku is not built for is tasks that require sustained context, iterative debugging, and the ability to hold a complex mental model across multiple attempts. Building a faithful recreation of an arcade game from hardware documentation requires understanding not just the code but the shape of the problem â what makes this specific game different from other games, what the reference materials are actually telling you, and why the first three approaches failed.
Haiku kept producing something â and that something always came with confident documentation and â FIXED! declarations. It never said "I'm not sure this is right." It never said "let me verify before claiming it's fixed." It shipped broken code with professional presentation, twice, and called it done.
Opus would have caught this. Opus would have looked at the coordinate math, noticed the car was below the road, and asked whether that was intentional before declaring victory. Opus thinks before it confirms. That's slower and more expensive. For a bootloader, it's worth it. For a quick game port, you might not think you need it.
You need it.
The Framework I Now Use
After the Pole Position Fiasco, I'm more deliberate about model selection:
Use Haiku when:
- The task is clearly defined and bounded
- You're generating something from a template or pattern
- Speed matters more than depth
- You can verify the output quickly and cheaply
- Failure is low-stakes and easy to catch
Use Sonnet when:
- The task requires reasoning across multiple pieces of information
- You need personality and engagement alongside competence
- You're iterating on something and want a thinking partner
- The problem is medium-complexity and time matters
Use Opus when:
- The task is genuinely hard
- Failure is expensive (bootloaders, production code, architectural decisions)
- You need the model to notice what it doesn't know
- You want "I'm not sure about this" instead of â FIXED!
- The problem requires holding a complex mental model across a long session
The critical difference isn't raw capability â it's epistemic honesty. Haiku optimizes for producing an answer. Opus optimizes for producing a correct answer. Those are different objectives, and the gap between them becomes visible exactly when the problem is hard enough that the answer isn't obvious.
The Coda
The three HTML files still exist in the Fluid Fortune project record. They are not playable. They are evidence.
The engineering document Haiku wrote for the broken game is also preserved. It is genuinely well-written. It accurately describes an architecture that does not function as described. It is the most expensive way to learn that documentation is not the same as working software.
I went back to the bootloader. It was still hanging slightly to the left and down at an angle. That meant it was rendering something. That was real progress.
The Pole Position II game still has a floating road and a car in a grass field.
The jester learned to match the model to the job.
The Epilogue: What Haiku Is Actually For
After the Pole Position Fiasco, I gave Haiku a different job.
No arcade hardware documentation. No MAME source code. No pseudo-3D perspective rendering. Just: build me a calculator. A simple one. With a gag ending.
The result was VibeCalc â a fully functional calculator where pressing equals always returns "the vibes are good." Every time. No exceptions. 9 + 9? The vibes are good. 10 / 0? The vibes are good. The square root of negative one? The vibes are good.
Then, at my insistence, Haiku wrote the README. You can read it here.
The README is a masterpiece. It includes a formal state machine diagram. Big-O complexity analysis for every operation â calculate() is O(1) with "MAXIMUM VIBES" impact. A browser compatibility table that notes Firefox calculates vibes at 59fps due to "Mozilla tax" and confirms Netscape Navigator works but "time travel not supported." A Vibe Preservation License. A Future Roadmap that includes imaginary numbers ("i = the vibes are complex") and sentience ("When the calculator becomes self-aware, it will calculate only vibes").
The closing line of the README: "Math is temporary. Vibes are eternal."
It was calculated at Tacos La Villa at 1:29 PM on May 7, 2026. Shout out to Tacos La Villa.
This is what Haiku is actually for. The task was appropriately scoped. The model was appropriately matched. The README is absurd in exactly the right way â confident, detailed, and completely aware that it is documenting a calculator that does not calculate.
The difference between VibeCal and the Pole Position Fiasco is not the model. It's the job. Haiku given the right task produces something genuinely delightful. Haiku given the wrong task produces a floating road, a car in a grass field, and an engineering document describing both as production-ready.
Choose your model like you choose your tool. A precision screwdriver is not a sledgehammer. A sledgehammer is not a precision screwdriver. Both are useful. Neither should be asked to do the other's job.
The vibes, for the record, are good.
Eric Becker is the founder of Fluid Fortune and the author of Pisces Moon OS â a field intelligence platform for the ESP32-S3. He identifies as the Court Jester of Vibe Coding. The bells on the hat are load-bearing.
fluidfortune.com | blog.fluidfortune.com