Vibecoding: How to Rewrite
a Classic Arcade Game in 2026

The first game I tried to rewrite with AI lasted eleven seconds. A white canvas, a ball shooting upward and leaving the screen never to return. It was supposed to be Pong. In practice it was a dot fleeing the browser window. I stared at the code, stared at the empty screen, and thought: maybe I should read the canvas docs before asking Claude to write me an entire game.

That moment perfectly captures what vibecoding means in 2026. At PixelPrompt we've rewritten seven classic arcade games from scratch (Pong, Snake, Tetris, Pac-Man, Space Invaders, Arkanoid, Donkey Kong) using Claude as copilot. No emulators, no porting: fresh JavaScript code on HTML5 canvas, with the ambition of recreating the game feel of the originals. What I learned in this process is worth more than any prompt engineering course.

Vibecoding isn't what you think

The term “vibecoding” gets thrown around a lot in 2026, usually with a negative connotation: people tossing prompts at an LLM and pasting the output without understanding it. That's not vibecoding. That's copy-paste with extra steps.

Real vibecoding, the kind I do at PixelPrompt, is closer to pair programming. I know the game: I played it as a kid, I know how Mario's jump should feel, I know that Donkey Kong's barrels need that specific bounce on ladders. Claude knows the code: it can write a game loop, implement collision detection, generate a tile map. The intersection is where something interesting happens.

We have a principle at PixelPrompt: AI is the chisel, not the sculptor. I decide the design. I decide that Tetris gravity should accelerate 15% per level, not 20%. I decide that Pac-Man's pink ghost should target two tiles ahead of the player, not four. Claude writes the boilerplate, generates alternatives, saves me hours of syntax lookups. But the game design decisions are mine.

The real process, unfiltered

Every game on PixelPrompt follows the same cycle. It's not linear and it's not clean.

Phase 1: the draft that works (hours 0-2). I ask Claude for the base structure. Game loop, canvas, sprite rendering, input handler. Within two hours I have something moving on screen. It's ugly, it's imprecise, but it moves. This is where AI shines: boilerplate comes out fast and almost always correct.

Phase 2: the missing game feel (hours 2-8). This is where the real work starts. Pong's ball bounces but has no weight. Mario's jump is linear when it should have gravitational acceleration. Space Invaders sprites jitter instead of scrolling smoothly. This is where AI struggles most, because game feel can't be described in a prompt. You feel it. I spent an entire afternoon telling Claude “the jump is too floaty,” “still too floaty,” “now it's too heavy,” “go back half a point.” Pure iteration.

Phase 3: the bug that teaches you the original (hours 8-20). Every game had at least one bug that forced me to study the original ROM. In Pac-Man, ghosts phased through maze walls because collision detection checked the sprite center but not the edges. In Tetris, the SRS rotation system required a wall kick table that Claude didn't know, so I had to feed it piece by piece. In Donkey Kong, barrels on ladders: three days for a three-state state machine.

Phase 4: infinite polish (hours 20+). One frame of input lag is the difference between a game that “feels right” and one that feels like a cheap knockoff. One pixel of hitbox offset completely changes the difficulty curve. This phase never ends. But it's the one that turns a technical exercise into a game people come back to.

Where AI fails (every time)

After seven games, I have a precise list of where Claude systematically falls short.

• Magic numbers. Speed, gravity, acceleration, spawn timers. Claude produces reasonable values but almost never correct ones. Pong ball speed? Too fast. Tetris gravity? Too slow. Pac-Man ghost frame rate at level 1? Too quick. Every time I have to test, adjust, retest. Magic numbers are the last frontier of game design and AI can't nail them because it has never played the game.
• Sound effect timing. Claude generates the logic to trigger a sound, but the exact moment the sound fires (on the impact frame? one frame early? two frames late?) completely changes perception. You only find this with headphones on and your finger on the play button.
• Edge cases. What happens when two barrels overlap on the same ladder? When Tetris's I-piece rotates against the right wall at level 19? When Pac-Man changes direction on the exact frame a ghost reverses? Claude handles the base case. I find the edge cases by playing.

Where AI surprises you (when you least expect it)

It's not all debugging and frustration. There are moments when Claude does something I didn't expect.

I was working on Space Invaders and asked it to implement degradable shields. I expected a grid of rectangles that disappear on contact. Claude proposed a per-pixel system: each projectile removes exactly the pixels it passes through, creating irregular holes in the shield. Like the original. I hadn't asked for it. It recognized the pattern from its knowledge of the game and implemented the correct version without me specifying the detail.

Another moment: the input queue for Snake. I described the problem (“if the player presses two arrow keys in rapid succession within the same frame, the second overwrites the first and the snake dies”) and Claude suggested a FIFO input buffer consumed at each game loop tick. Clean solution, three lines of code, worked first try. There are moments when vibecoding truly works like pair programming with a senior colleague.

Seven games later

After seven games rewritten from scratch, here's what I've understood about coding with AI applied to game development:

• 80% of the time goes into 20% of the code. The base structure of an arcade game comes out in hours. The game feel takes days. AI covers the first part at lightspeed; the second you do by hand, pixel by pixel.
• You need to know the game better than the AI. If you've never played the original, you can't judge whether the rebuild is faithful. Muscle memory matters more than technical documentation.
• The most educational bugs are the original's. Space Invaders' progressive difficulty was born from a rendering bug: fewer aliens on screen meant fewer sprites to draw, so the frame rate went up and aliens moved faster. A bug that became a mechanic. Intentionally recreating these “mistakes” is the most fascinating part of the process.
• AI is the chisel, not the sculptor. Every single time. No exceptions.

If this piece made you curious, at PixelPrompt we rewrite a classic every week and share what we learned. Code, pixels, zero fluff. Join the crew.