I Typed Two Words and Got a Working Chess Game
Chess looks like a beginner project until you try to write the rules. I gave an AI builder two words and walked away. What came back — and where “easy” quietly ends.
I typed “chess game” into the prompt box. Two words. No spec, no piece list, no mention of rules. Then I hit send and went to make coffee.
By the time I came back there was a board. Not a placeholder board — a real one, with pieces in their starting ranks, a turn indicator, a move counter, a captured-pieces tray, a material-advantage readout, an undo button, and a “flip board” toggle. It was playable. And it had an opponent.
That last part is the one that made me sit up.
Chess is a trap for “simple” projects
Everyone files chess under beginner tutorial. It isn’t. A chessboard is easy. The rules of chess are a small monster, and they’re the kind of monster that looks tame right up until it eats your weekend.
Here’s the short list of things any honest chess implementation has to get right:
- Legal move generation per piece — a knight’s L, a bishop’s diagonals stopping at the first blocker, a pawn that captures differently than it moves.
- Check — you can’t make a move that leaves your own king attacked, which means every candidate move has to be simulated and then validated.
- Checkmate vs. stalemate — no legal moves and in check is a loss; no legal moves and not in check is a draw. Confusing the two is a classic bug.
- Castling — two pieces moving at once, gated by four separate preconditions (neither piece has moved, nothing between them, king not in check, king doesn’t pass through an attacked square).
- En passant — a capture that’s only legal for exactly one move after a specific pawn push, then gone forever.
- Promotion — a pawn reaching the back rank becomes another piece, and the UI has to ask which.
This is why chess shows up in senior engineering interviews. It’s a compact test of whether you can hold a system of interacting rules in your head without dropping one. Most people who “know how to build chess” quietly forget en passant.
The builder didn’t. It produced roughly 1,300 lines across six files — a dedicated move-rules module, a board component, and, unprompted, a separate engine for the AI opponent. Nobody asked for an opponent. It decided a chess game without one wasn’t really a chess game.
Asked for a game. Got a full one — AI opponent and all.
What the builder actually did
Under the hood it wasn’t pasting a template. The trace reads like someone working a problem in order:
- Scaffold a fresh frontend project.
- Write the rules engine first — moves, check detection, special cases — as its own module.
- Wire up an engine-style AI so one side can play itself.
- Build the interface on top: board, side panel, history, the controls a player expects.
- Start the dev server, hit its own URL, confirm a real
200before calling it done.
That last step matters more than it sounds. The difference between “the code looks right” and “the server actually answered” is the difference between a demo and a thing you can click. The build isn’t finished until something on the other end says it’s alive.
And it doesn’t stop there
What I got is a complete, playable game: two players on one screen, plus the AI. If you want the next thing — two different people, on two different devices, playing over a shared link in real time — that’s a backend: game rooms, a join-by-URL match, a socket pushing each move to the other player, state that survives a refresh.
Here’s the good part: that’s the next prompt, not the next month. You keep talking to the same builder — “make it online, two players join by link” — and it adds the layer. Two words got you a real game. One more sentence takes it online.
Why this matters past chess
If a builder can hold the full rule system of chess together — the special cases, the self-check validation, the “don’t move into check” constraint that touches every other rule — then the app you actually need is almost certainly easier than the toy I made for fun.
Most real software is not chess. A CRM is forms and a list. A booking tool is a calendar and a confirmation email. A dashboard is a query and some charts. These have fewer interacting rules than en passant alone. Chess is the stress test; your internal tool is the easy case that’s been waiting behind “I’ll learn to code someday.”
You don’t need someday. You need two words and a willingness to keep talking.
Build your version in the next ten minutes
Describe it in plain language. Get a live, playable app back. Then iterate by chatting — add a backend, a login, a domain.
Try Bnome