Why

It started with two passions colliding. Rob plays board games often with his great friend René Hernández — sometimes in person, sometimes online — and they needed an online alternative for this one particular game. Rob's brother Alberto Fait had introduced him to Panda Royale, and it spread through the group like wildfire. The obvious move was to make it playable from anywhere: one 4-character code, everyone joins, the server deals and scores, and the math is always right.

There was a second reason, though — a demonstration. The game itself was built autonomously by Kiro Crew. It's a proof that a well-built harness around an AI agent can take a fuzzy "let's make our board game playable online" and turn it into a live, hardened, internationalized product without a human writing the code.

How — the short version

The velocity didn't come from typing fast. It came from harness engineering: building the agent's environment so that every change is self-verifying and self-shipping. The agent doesn't guess whether something works — it runs the same gates a senior engineer would, on every single change, and only moves on when they're green.

The loop for every feature, from the first commit to the last, was identical:

1. Read the relevant code first — never edit blind.
2. Change it.
3. tsc --noEmit — no type errors.
4. vitest run — the unit suite stays green (it grew from ~50 to 87 tests).
5. next build — it compiles for production.
6. axe-core — a headless accessibility scan (added mid-build) fails the loop on any WCAG 2 AA violation.
7. Commit, deploy to production, confirm the live /api/health endpoint.

Because the loop was airtight, the agent could take dozens of iterations — rule corrections, a full visual redesign, six-language localization, a security audit, an entire second game mode — without ever leaving the app broken in production.

How — the architecture that made it possible

The single most important decision was a pure, server-authoritative game engine with no I/O in it:

• lib/dice.ts — die types and the rulebook-accurate distribution (106 dice), the server RNG, the N+1 draft market, the pity-pink table.
• lib/score.ts — one scoring engine, used for both the client preview and the server's authoritative recompute.
• lib/game.ts — the state machine as a single pure function: reduce(state, action, rng) → state. Lobby → rolling → drafting → finished.

Because the rules live in a pure function with an injectable RNG, they are exhaustively unit-testable without a browser, a server, or a network. That is what let the agent verify a subtle rulebook fix — "the final round has no draft," confirmed against the actual rulebook — with a deterministic test instead of a manual playthrough. The 87-test suite runs in well under a second, so step 4 of the loop was never a bottleneck.

Around that pure core:

• Next.js (App Router) + TypeScript on Vercel.
• Upstash Redis holds the authoritative GameState, reconnect tokens, and an append-only event log, and relays changes over pub/sub.
• Server-Sent Events push state to every browser in the room — no long-lived WebSocket server needed on serverless.
• Upstash QStash runs durable server tasks like the round timeout that auto-plays for a player who steps away, so a game can never hang on someone who left.

Server-authoritative means the client can never cheat the score: the server re-scores every action. That single property removed an entire class of "is the math right?" questions the agent would otherwise have had to babysit.

What actually shipped, and why the pace held

The first session produced the playable game end to end. Everything after was a tight iteration loop that a human product owner could steer in plain language, one request at a time:

• Rulebook accuracy — correct dice distribution, red white/black numerals, rotating pity-pink dice, the clear-die "swap with a one-round lock" steal, and the round-10-has-no-draft fix (verified against the rulebook).
• A real product, not a prototype — faceted polyhedral SVG dice with a face-cycling roll animation, a bamboo-forest light/dark theme, a responsive breakpoint ladder, sound (including a synthesized drum roll on the roll), round-result announcements, share/QR + copy-invite links, play-again, and a Credits screen.
• Six-language i18n — every UI string in English, Spanish, French, Portuguese, German, and Chinese, audited so that no English silently leaks through — right down to the server's error messages.
• A full second game mode — an educational mode where kids do the arithmetic themselves on a printed-worksheet-style score sheet, with per-box hints, keyboard navigation, and every timer disabled so a child has unlimited time.
• Security hardening — token-based auth for every mutating action, security headers, CSPRNG identifiers, and a fail-closed webhook.
• Accessibility as a gate, not an afterthought — WCAG AA contrast fixes and a headless axe-core Playwright test wired into CI so every future build is scanned automatically. The reason the pace held across all of that is that nothing was ever left in a "probably works" state. The harness made "done" mean type-checked, tested, built, accessibility-scanned, and live — every time — so each new request started from a known-good, deployed baseline instead of a pile of unverified changes.

The takeaway

Speed in autonomous software isn't the model typing faster. It's the harness: a pure, testable core; a deterministic verification loop the agent runs on every change; and a one-command path to production. Get those three right and an agent can turn "we needed an online alternative for this fabulous board game" into a live, multiplayer, six-language, accessible product — without a human writing the code, and without ever shipping something broken.

Play it at app.pnd.ad.

Pandejo Real is fan-made and not affiliated with or endorsed by Last Night Games. Built autonomously by Kiro Crew. Made with ❤️ in 🇲🇽 by Rob.cr 🇨🇷. Special thanks to Manuel Quijano for reintroducing Rob to Kiro.