From idea to final product in a day (Opus 5.5)

looked like.
* Everything lived in three files: server, HTML, CSS. Make it work first, structure it later.
* One experiment I liked: I asked Claude to pick one feature to add with no guidance. It chose a dash with knockback. It stayed in the game and became one of the core mechanics.

**Phase 2**

This is where most of the real work was, and where I changed how I used Claude.

1. **Split the code early.** Once a file passes about 2,000 lines, Claude spends a lot of context just reading it. Splitting into small modules (game loop, physics, matchmaking, rendering) made each session faster and more focused.
2. **Keep a** [**CLAUDE.md**](http://CLAUDE.md) **that describes the architecture.** Commands, folder layout, how the netcode works, the game rules, the UI colours and fonts. New sessions start with the right mental model instead of rediscovering it every time.
3. **Share one simulation between client and server.** The game logic lives in a single shared file that both sides run. The server is the authority, and the client runs the same code to predict your own movement, so the game feels instant even with lag. Having one source of truth also made it much easier for Claude to change game rules without the two sides drifting apart.
4. **All in one conversation.** I like to run single conversation as orchestratos and have it spin subagents per features. It works quit well 
5. **Tests on the server logic.** Matchmaking, match events and the game rules have Bun tests.

**Things I learned the hard way**

* Netcode is where AI help needs the most supervision. Client prediction and reconciliation are easy to get almost right. I had to actually learn how they work to judge whether Claude's changes were correct.
* Be specific about feel.