My nephew is 11. He doesn't have a product requirements document. He doesn't know what a WebSocket is. What he has is the same gut-level instinct that makes UNO work. That feeling of slapping a card down and watching someone's face change.
His game idea was simple. Cards that attack. Cards that block. Cards that reverse things suddenly. No formal rules. No edge cases. Just the raw energy of a table erupting.
I don't write TypeScript. I don't configure WebSocket servers. My day job is running operations at a financial data company. But I recognised something in my nephew's idea. A structure underneath the chaos. The kind of "wait, what just happened?" moment that makes card games addictive.
Four days later, the game was live. Real URL, real multiplayer, real users, no lines of code written by me.
Here's why I think it matters.
The design was the hard part
There's a persistent myth that building software is about code. It isn't. Code is the execution layer.
The hard part is the same thing that's hard about running any operation. Defining what "done" looks like. Resolving ambiguity before it compounds. Making the smallest number of decisions that constrain the largest number of outcomes.
His first iterations were chaos. Every playtest ended with players asking the same questions. "Can I reverse this?" "Does this block that?" The game was fun if someone explained it live. That's not a product.
The breakthrough was a triangle. Attack counters Defence. Defence absorbs Attack. Reverse redirects Attack. A closed loop. Simple enough for an 11-year-old. Structured enough to build on. This one diagram anchored every decision that followed.
Specs buy leverage
Before I opened any AI coding tool, I wrote three documents. A product requirements doc with success metrics. A technical game spec with the validation rules. A rulebook that codified the game into transferable logic.
This is the same approach I use at work. Define the target. Remove ambiguity. Make the code follow the system, not the other way around.
None of this required knowing how to code. It required knowing how to think clearly about what a system needs to do, and writing it down with enough precision that someone, or something, could execute against it.
Then Claude Code took those documents and translated them into working software. It chose the architecture. It wrote the game engine. It set up WebSocket communication. It built the React frontend. I didn't tell it to use any of those technologies. I told it what the game needed to do. It figured out how.
Real users break everything
Day 3 humbled me. Real users arrived and broke everything I thought was solid.
The play button was intermittently unresponsive. State race conditions. Specs can't predict timing bugs. Two-player Reverse cards turned out to be pointless. Edge cases only surface when the game is played, not designed. The mobile layout was redesigned three times in a single day.
Simplicity won in the end. It always does.
The lesson I keep relearning: specs carry you from zero to working. They don't carry you from working to production-grade. That gap still requires real human judgment, real playtesting, and a willingness to be wrong three times in one day.
What this changes
AI tools have shifted the bottleneck from implementation to design. The person who can write a clear spec now has more leverage than the person who can write a mediocre function.
This is the biggest change in software in a decade, and most operators haven't noticed yet.
If you've run an operations function, you already have these skills. You've been writing specs. You just called them project briefs, or SOWs. You've been triaging. You just called it prioritisation. You've been debugging. You just called it root cause analysis.
The bottleneck used to be implementation. Now it's design. The people who can write clear requirements, define precise constraints, and triage effectively are suddenly the people who can ship.
It's the thesis I'm building around at Learned Context.
The full build log, including the architecture diagrams, the Day 2 deployment saga, the Day 3 playtesting reckoning, and what my nephew thought when he finally played the finished game, is at learnedcontext.com/learn/multiplayer-game-build-log.
Fair warning: the bots on Hard are better than I am.
“The person who can write a clear spec now has more leverage than the person who can write a mediocre function.
