Why this matters

In March 2018 I built a Snake game - the goal was to learn HTML5 - <canvas>, 2D, 3D - in the JavaScript world. It took about two days. Eight years later I asked Claude Code to migrate the same project onto a modern stack. Total elapsed time, including a wrong-direction first pass and the review work: about twenty minutes. The artifact is live at playsnake.online.

This article is the screenshot-by-screenshot read. I include the bad first attempt because the magic isn't free - the way the conversation went is the actual lesson.

The cost of writing the obvious code dropped near zero. The cost of knowing what to ask for did not.- the practical lesson

What 2018 actually was

The original project was not a vanilla HTML page. It was an ASP.NET Core (.NET 6) web app with the snake game embedded in Razor (.cshtml) pages. The frontend used scattered JavaScript modules - a game engine, a menu, a config layer, sounds, a level loader, primitives - bundled and minified by gulp. Bootstrap for the chrome. The build pipeline looked like this:

A screenshot of the original 2018 gulpfile.js. It defines a config object with snakeJs as an array of source paths (core, SnakeGame, UI menu, config, sounds, GameEngine modules - SnakeEngine, LevelLoader, Grid, DrawEngine - plus primitives and levels), and snakeCss and imgCss entries pointing to the css folders. The file shows the standard 2018 pattern of an asset-pipeline bundler driving the build.
The 2018 gulpfile.js · pre-Vite asset pipeline

None of this was particularly clever. It was just what shipping a small browser game looked like in 2018: a server stack you didn't really need, a bundler that was state-of-the-art at the time, and the actual game logic distributed across a dozen files because that's how you organized things back then.

The first try

My first prompt was deliberately under-specified - just to see what Claude would do:

A Claude Code chat panel showing the initial prompt: 'We are going to create site in src/Games.Snake. I need you to create index.html, folders: assets/css, assets/image, assets/js, project will be deployed to Azure via SWA. Put in README: The project was originally created on 20 March 2018. use Vite/esbuild for dev. tech stack: Html5/Css(bootstrap)/JavaScript.' A pixel-art snake-game sprite sits above the prompt.
First prompt · ~90 words · no reference to the original code

Claude built exactly what I asked for. A working snake game from scratch, in plain HTML5 + Bootstrap + JavaScript, ready to deploy to Azure SWA. Generic - one big canvas, a start button, score and best tracking, dark blue background. About six minutes.

The first Claude Code result: a simple snake game UI titled 'Snake', with the instruction 'Arrow keys / WASD to steer. Eat, grow, don't bite yourself.', a score and best display, and a centred 'Ready to play?' prompt with a green Start button. Below the canvas, a footer reads 'Built with HTML5, Bootstrap & JavaScript · since 2018.'
First-pass result · functional, generic, not what I had in 2018

It played snake, but it had nothing in common with what I had actually built in 2018. The under-specified prompt got an under-specified result. That's on me, not on the model.

The real prompt

The second prompt was a migration brief. Pointed Claude at both repos and described the stack on each side:

The migration prompt text: 'We have a project Games.Snake. Current: D:\Repos\Osovitny\Osovitny.Web\Code\src\webapps\Games.Snake. I need you to review original code and migrate to current project. Original code: D:\Repos\Osovitny\Osovitny.Games.Snake\Sources\Osovitny.Games.Snake.WebApp. Tech Stack Was: ASP.NET Core, .NET 6, pages in *.cshtml, Html, JavaScript, Css, gulp. Now: esbuild, Vite, Html5, bootstrap, TypeScript, SWA. I need you to review and do next: was: built resource: gulp, now: esbuild was: pages *.cshtml, now: must be just .html. Read gulpfile.js to know how to build.'
The real brief · was/now stack, file paths, migration constraints

Three things changed:

  • Source and target paths are explicit. Claude knows which directory holds the 2018 code and which holds the new one. The work is migration, not creation.
  • "Was / Now" tech stack laid out as a table. ASP.NET Core → just HTML. gulp → esbuild. .cshtml → .html. TypeScript replaces JavaScript. Each row tells Claude exactly what to swap.
  • "Read gulpfile.js to know how to build." The single most important line. It's telling Claude to understand the existing build before rewriting it. Migrations break when the rewriter doesn't read the original.

Claude's plan

Claude read both repos, read the gulpfile, then proposed a plan:

A Claude Code 'Update Todos' panel listing seven steps: copy binary assets (sprites, sounds, css images) into public/assets - marked done; write core/leaf TS modules (consts, utils, userAgent, dom, types, audiofx, engine consts, menu consts) - in progress; write game singleton (game.ts) + config + sounds + menu; write engine modules (snakeEngine, grid, drawEngine, levelLoader, primitives, levels); write entry snake.ts, index.html (inline cshtml partials), style.css; update README, remove stale placeholder bits; typecheck + build with Vite to verify migration.
Claude's seven-step migration plan · executed top to bottom

The plan reads like one a senior dev would write: assets first (the easy stuff), then leaf modules (low dependencies), then the engine (where the logic lives), then the entry point (which depends on everything), then docs and verification. Each item became a TypeScript file in the new project.

What's worth noting: Claude inferred this ordering from the gulpfile and the source layout. I did not specify it.

The result

About fourteen more minutes later, the migrated project was building cleanly, type-checking, and deployable to Azure SWA. The visual identity from 2018 - the logo, the dark green jungle background, the menu structure - all came across because Claude had the original assets and could read what the .cshtml pages were doing visually.

The migrated playsnake.online start screen: the white snake-head logo glowing green on a dark scaled background, framed by jungle leaves, with PLAY, HIGH SCORES, and HELP menu options below.
playsnake.online · start screen · the 2018 identity intact
The migrated game in mid-play at playsnake.online: a top-down view of a brown sand arena framed by green bamboo edges and jungle leaves on either side. The yellow snake is moving up the centre. A soccer ball and a basketball sit as food items, a pineapple in the top-left corner, and small green grass clusters as obstacles. A bottom HUD reads SCORE: 0, FOOD LEFT: 10, LIVES LEFT: 5, LEVEL: 1.
playsnake.online · the migrated 2026 build · in play

Click playsnake.online if you want to see it. The game itself - the snake, the levels, the audio - is the 2018 logic, ported to TypeScript and bundled by Vite instead of gulp. The migration preserved the artifact, replaced the pipeline.

The 144x math

2018 by hand · 2026 by Claude Code
~ 144x speedup
2 days × 24 h × 60 min = 2880 min
2880 min ÷ 20 min ≈ 144

The headline number is real, with the obvious caveat: I did not work 24 hours straight in 2018. The "two days" was wall-clock - thinking, eating, sleeping, breaks - while the "twenty minutes" was focused work with no breaks. If you compare productive hours to productive hours, the speedup is closer to 30-40x. Still real. Still the right order of magnitude for the lesson.

The honest cost

The 20 minutes flatters the AI a little. Three caveats worth naming:

  • The first prompt was wrong, and I wrote it. Six of the twenty minutes went to a result I had to throw away. Knowing how to write the migration brief - paths, was/now, "read the gulpfile" - is what saved the rest. That's craft, and it didn't come for free.
  • 20 minutes of Claude, 10 minutes of review, then live. Claude did the work in about twenty minutes. I spent ten more reading the diffs and catching the things I didn't like before they landed. Then deploy - and it was live. Skip the review and that thirty minutes becomes an hour of debugging things that almost-worked.
  • Migration is the friendly case. Claude had both repos to read - the original code is the spec. If I'd been writing this from scratch with no reference, the prompt-writing alone would have taken longer than the build.

The fair summary: obvious code got faster by 50-100x; judgement work got faster by 2-3x. The product is the migration of an 8-year-old project in 20 minutes, which would have been unthinkable in 2018 - and that part is real.

The takeaway

  • AI compresses the obvious code. Scaffolding, build configs, the boring 80% of a port - written in minutes.
  • It does not compress the thinking. The under-specified first prompt cost me time. The migration brief saved it. The skill that pays now is writing the brief, not writing the code.
  • The review pass is the new craft. "Can you write the game loop?" became "Can you tell when the game loop is built wrong?" in the space of one career. Get good at that.

Two days to twenty minutes is what changes. The shape of being a developer - knowing what you want, knowing when it's wrong, knowing what to ship - does not.

For more on the tool itself, read What is Claude Code? For where it fits next to Copilot, read Copilot vs Claude Code: engineer vs artist.

References