Claude Code Built a Game Its Creator Cannot Beat

There is a moment near the end of Lydia Hallie's demo — posted to the Google Cloud Tech channel — where she finishes building a multi-level game with AI assistance, runs it, and then quietly admits she isn't sure she can clear any of the levels it built. The AI finished the job. The human is still catching up.

That detail is small, but it points at something worth sitting with. We've spent years asking whether AI can write code. Hallie's demo shifts the question: what happens when AI doesn't just write code, but organizes, delegates, and manages the whole construction process itself?

The Plan Before the Code

The demo opens with a design problem, not a coding problem. Hallie, a developer relations engineer at Anthropic, pulled an existing slingshot game from a colleague's GitHub repository and wanted to turn it into something more complete — multiple levels, a main menu, health bars, haptic feedback on mobile, audio, scoring. The standard approach would be to sit down with an AI coding assistant and describe those changes one by one.

She didn't do that.

Instead, she used Claude Design — described in the demo as a research preview that generates presentations, wireframes, and websites from text prompts — to build a visual blueprint of the whole game first. The result was a set of HTML screens mapping out game flow, interface elements, level designs, and system specs. Not a prototype. A plan rendered as something you can look at, edit, and hand to the next stage of the process.

"I really like having this visual approach for a plan," Hallie explains in the demo. "This is just HTML at this point. I could have also exported it to Figma or Canva or anything else. But this allows me to really think about the plan and the changes I want to make."

The distinction matters. Prompting AI with a list of desired changes and handing AI a visual spec it can read, interpret, and act on are different operations. The first is you directing a tool. The second is closer to briefing a team.

How the AI Divided the Work

Here is the part that should interest anyone who has wondered what "AI agent" actually means in practice. Hallie fed the HTML design file to Claude Code running on the Gemini Agent Platform with a deliberately minimal instruction: read this design file and use a dynamic workflow to rebuild the game and match it.

She was testing whether Claude could figure out the rest.

What happened next is the demo's real subject. Rather than working through the task sequentially — write the game engine, then the UI, then the audio — Claude generated a JavaScript file that described its own work plan. That file organized the job into phases and assigned different pieces to parallel workers running simultaneously. The build phase ran four workers at once, each focused on a distinct piece of the system: one on the game engine, one on the interface, one on audio, and one on level design and haptics. After those finished, separate phases handled integration, review, and verification, running one after another.

None of that file was written by Hallie. Claude wrote it.

The practical effect: work that would have proceeded in a single line — one thing after another — instead spread out across simultaneous tracks. The demo's four parallel workers don't wait for each other. Audio development doesn't wait for the game engine to finish. Level design doesn't wait for the UI.

This is the plain-English version of what "dynamic workflows" actually means: the AI figures out which parts of a job can happen at the same time and runs them that way, then stitches the results together. It is less like a single very capable assistant and more like a coordinator who knows how to staff a project.

The Repeatability Question

One thing Hallie emphasizes that tends to get lost in the excitement about what AI can generate: because the workflow exists as a plain JavaScript file, it can be saved, inspected, edited, and rerun exactly. Every time you invoke it, the same workers run in the same order with the same instructions.

That matters for anyone who has bumped into AI's tendency toward inconsistency. Ask an AI to help you with a task once and you might get a great result. Ask it again tomorrow and the approach might be completely different. Saving a workflow that worked is a way of locking in a process, not just a result.

It also opens a more interesting possibility: engineers can look at the file Claude generated, decide that some of the workers don't need the most capable model available, swap in a lighter option for those steps, and save money and time without sacrificing quality where it counts. The workflow becomes editable infrastructure, not a black box.

"I didn't type this," Hallie says, reviewing the JavaScript file Claude produced. "This is all Claude."

What the Game Actually Did

After the workflow completed, Hallie ran the game. It matched the design spec closely — the visual style, the multiple levels, the structured flow from menu to gameplay. It included audio. It included haptic feedback. It was, by any reasonable measure, a functional multi-level game built from an HTML wireframe and a one-sentence prompt.

Then she tried to play it and ran into the same wall she'd mentioned at the start: the game is hard. She hadn't been able to clear the original single-level version her colleague built. The multi-level version she'd just assembled with AI help was, if anything, more demanding.

"I'm not sure if I can like clear all these levels," she says at the end, with the particular tone of someone who has just been mildly humbled by software they helped make.

There's no clean moral to extract from that moment. The game being difficult isn't a failure — it's probably a feature. But the image sticks: a developer who understands the system thoroughly, who designed the plan and wrote the prompt and oversaw the process, now sitting across from the output and finding it a legitimate challenge. The AI didn't just execute instructions. It produced something with its own character.

What This Changes — and What It Doesn't

The demo makes a credible case that AI-assisted development is moving past the stage where the main use is autocomplete. Managing a structured workflow, delegating to parallel workers, generating its own work plan from a visual spec — these are coordination tasks, not just code generation tasks.

But a few things are worth holding onto. This is a demo, built and presented by someone deeply familiar with the tools, in conditions designed to show them working. The interesting question isn't whether the workflow ran cleanly in a prepared environment. It's how well these tools handle the messy, underspecified, halfway-finished projects that constitute most real software work.

The visual planning step Hallie uses — translating intentions into a readable design spec before touching code — also shouldn't be overlooked. The AI's ability to interpret and act on the HTML wireframe depends on that wireframe being well-constructed in the first place. The quality of what Claude Design produced as a plan directly shaped what Claude Code produced as a game. Good inputs, better outputs. That relationship doesn't change just because the tools are more capable.

What does seem genuinely different is the level at which a single person can now manage a complex, multi-part build. Hallie ran this as a demonstration, but the underlying setup — one person, a design sketch, a short prompt, a structured result — describes a meaningful compression of what used to require more hands and more time.

The harder question, the one the demo doesn't address, is what that compression eventually does to the people who used to fill those roles. The AI built the game. The human can't beat it. At some point, someone will need to ask which of those facts is the more consequential one.

---

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG