A few days ago I had a silly idea: what if my homepage had a hidden arcade game? Click a button, and the page turns into Space Invaders - where the actual text on the page becomes the enemies you shoot.
I built it with Claude Code in about 30 minutes across three iterations. I used Opus as the model with effort set to high and Plan mode enabled for each iteration. The result is a fully playable game: chiptune music, CRT scanlines, neon glow effects, explosions - the whole 80s arcade aesthetic, in ~560 lines of vanilla JavaScript with zero external dependencies.
Here’s how it went.
Iteration 1: The initial prompt
My prompt was intentionally loose:
On the main landing page I’d like to have a button on the bottom that reads ‘play’. If clicked the page turns into a game with a small spaceship on the bottom that can shoot. If a shot hits a character that character is removed and an explosion happens. Only JS, no external dependencies. Simple and small as possible. 80s arcade look. Very simple 80s arcade style music is fine.
With Plan mode enabled, Claude Code didn’t jump straight into writing code. It first explored my Hugo site structure - understood the theme, templates, asset pipeline, and how the homepage renders. It then wrote a detailed implementation plan covering file placement, game architecture, audio design, and visual effects. Only after I reviewed and approved the plan did it start coding, producing two files:
layouts/index.html- a Hugo template override that loads the game script via the existingfooter_jsblock. Clean integration, no changes to any existing file.assets/js/space-invaders.js- the entire game in a single self-contained IIFE.
The clever part was how it extracted the “invaders”: on game start, it walks the DOM tree, isolates every visible character using the Range API, captures each character’s exact screen position via getBoundingClientRect(), then draws them on a full-screen canvas overlay. Your homepage text literally becomes the enemy formation.
The game had everything from the first version:
- Ship movement (arrow keys + touch)
- Bullets with a shoot cooldown
- Collision detection between bullets and the per-character bounding boxes
- Particle explosions on hit
- Win and lose conditions, with restart on Enter
- A live score display
- Procedural music and sound effects via the Web Audio API
- CRT scanline overlay and a vignette gradient
It worked on the first run. The text on my homepage really did become space invaders, and I really could shoot them apart. I sat at my desk laughing for about ten minutes.
But it wasn’t quite shippable yet.
Iteration 2: Audio that didn’t make me want to mute the tab
The first version had music, but it was bad in a very specific way. The notes had no proper gain envelopes, voices stepped on each other, the loop seam was audible every few seconds, and the explosion sound was a thin sine-wave blip rather than the satisfying crunch you want when you delete a letter from existence.
This is the part where AI assistance starts looking less like magic and more like pair programming. “It sounds bad” is not actionable feedback. I had to be specific: I wanted a square-wave bass voice and a triangle-wave lead, both routed through a single master gain so nothing clipped. I wanted explosions to be short white-noise bursts, not oscillator pings. I wanted the loop scheduler to queue several bars ahead so you never heard a gap.
Plan mode helped again. Claude wrote out the audio graph - oscillators feeding their own gain envelopes, summed into a master gain, into destination - plus the look-ahead scheduler, before changing any code. I approved. It ran. The homepage suddenly sounded like a quarter-eating arcade cabinet from 1983, and I had a master gain of 0.15 because I am also a thoughtful person who doesn’t want to ambush visitors with full-volume chiptune.
Iteration 3: Mobile, polish, and the easter egg you’re reading
Two things still bothered me. First, the entry point felt wrong. A button that says “play” is fine but it doesn’t feel like an arcade machine. Second, on my phone the whole thing was barely playable: the ship couldn’t dodge anywhere useful, the text invaders were squashed against the left edge, and there were no real touch controls.
The third iteration prompt was a list:
- Replace the “play” button with a pulsing magenta INSERT COIN button, slotted into the footer next to the legal links. CSS keyframes, neon glow, the works.
- Real touch controls: a finger anywhere on the screen should move the ship; the upper portion of the screen should also fire.
- Recompute invader positions against the canvas dimensions instead of the raw DOM coordinates, so the layout adapts to phone widths.
- Pressing
?during the game should open a blog post about how the game was built.
Plan mode again. Claude listed every change before touching code: the keyframe animation, the touch handler that splits move from shoot by Y-position, a layout pass that rescales character positions with a 60px margin, and a window.open to a specific blog post slug on ?.
That last bullet is why this post exists.
What this told me
A few things, in roughly increasing order of importance.
Simple stacks compound the AI gain
The “10x developer with AI” debate usually gets framed around enterprise codebases with 200 microservices and a CI pipeline that takes 40 minutes to run. That is a hard environment for any AI tool. The gains are real but capped.
My homepage is the opposite: Hugo, Markdown, plain JS, plain SCSS. Almost no friction between “idea” and “deployed”. The multiplier in that environment is not 10x. It is closer to 1000x, in the sense that what I just shipped in 30 minutes is something I would have spent a week of evenings on before, or - more honestly - never built at all.
The lesson is not “AI is magic”. The lesson is that simple stacks compound the AI gain. If you are paying real engineering money to maintain accidental complexity, you are also paying it in lost AI leverage. Every layer of build tooling, framework abstraction, and unnecessary infra is a layer Claude has to negotiate with before it can help you.
Good ideas are now the bottleneck
Claude did not wake up one morning and decide my homepage should be Space Invaders. I had to want that. The ratio of “ideas worth building” to “engineering hours” used to be a serious constraint - and that constraint quietly killed a lot of small playful projects before they ever got prototyped.
Now the engineering hours collapse and the ideas become the bottleneck. Product thinking - what should exist, why anyone would care, what the joke is - is suddenly the rare resource again. That is excellent news for anyone who has been quietly carrying ideas around for years waiting for time to build them.
You still have to be the senior engineer
The first version of the music was unlistenable. The first version on mobile was unplayable. Both took a specific, technically informed nudge to fix. “It sounds bad” got me nowhere. Telling Claude that the gain envelopes were clipping and that the scheduler needed look-ahead got me a working soundtrack in one shot.
The pattern I keep noticing across every project I do this way: Claude produces an obvious 80%-correct solution very quickly, and then you spend a few minutes being the engineer who notices the missing 20%. It is far more effective to be that engineer working with Claude than to be that engineer working alone. The leverage is real, but the floor on what you can ship is still set by what you understand.
Try it
Scroll to the bottom of the homepage. There is a pulsing magenta INSERT COIN button next to Privacy Policy. Press it.
Arrow keys to move. Space to shoot. The text that makes up my homepage becomes the invaders. When the last character is gone, you win. If they reach your ship, you lose. Press ? to come back here.
Now go insert a coin.
