A builder on V2EX posted something that made the rounds: a playable browser game thrown together in a single day. Grok for the morning prototype, Codex to polish the game assets in the afternoon, Gemini to rewrite the whole UI and interaction layer, and by evening there was a live URL you could actually click and play. Whether it's genuinely fun is unverified — one commenter said it played well, another said it still had a faint "AI smell" to it, and someone asked how much it cost with no answer given. But playable, on a real link, in a day. That part happened.
Here's what I want to talk about, because the generation speed is the part everyone brags about and it's also the part that ages the worst. The demo is throwaway. What you actually keep is the thin layer underneath it that makes the thing persist past a page refresh.
The honest split
Think of the project in two halves that have almost nothing to do with each other.
The first half is the game: HTML, CSS, and JavaScript, generated fast, iterated across whatever models you happen to have open. This is genuinely disposable. You can regenerate it, restyle it, throw the whole UI away and have a model rewrite it — which is exactly what happened in the original post when Gemini redid the interface. Static assets don't care how they were made. They just need somewhere to live and a URL to hand out.
The second half is state. The moment you want a high-score board that survives a reload, survives a second player, survives you closing the tab, you've left the world of static files. A leaderboard is not a UI feature. It's a tiny backend problem wearing a UI costume. And no amount of prompt-engineering the front end fixes it, because the browser has nowhere durable to write.
That split is worth internalizing before you start, because people conflate the two and then wonder why the flashy demo can't remember anything.
What the durable half actually needs
Strip it down and a leaderboard is embarrassingly small:
- A place to POST a score (name, points, maybe a timestamp).
- A place to GET the top N back for display.
- Somewhere to store rows that doesn't evaporate.
That's it. You don't need a framework du jour or a managed cluster. You need a small endpoint and a table.
On VicroCode the mapping is direct. The static game itself is the easy piece — you can run HTML online and get a hosted URL to share, same as the builder handed out theirs. The score layer is a small Python endpoint that reads and writes a SQLite table, which the platform supports natively through in-platform Python execution and API endpoint hosting. Two POST/GET routes, one table with a few columns, done.
I'd keep the schema boring on purpose: an integer id, a text name, an integer score, an ISO timestamp string. Boring schemas are the ones you can still reason about at 2am.
Why "you can inspect and hand-fix it" is the whole point
There's a separate thread in the same community that's really a warning label for anyone shipping a leaderboard. A backend developer described how they used to catch cheaters in a game: not just detection scripts, but the trail people left behind — UIDs in screenshots, then nicknames, then levels and avatars, then map data — all cross-referenced against operation logs that recorded everything.
The useful takeaway isn't the cat-and-mouse. It's that a leaderboard is an adversarial surface the instant it's public. Someone will POST a score of 999999999. Someone will submit an empty name. You will want to look at the raw rows, spot the garbage, and delete or correct it by hand.
This is why SQLite is a good fit rather than a compromise. It's a real table you can open and edit. When a junk entry lands, you don't redeploy anything — you open the SQLite editor, find the row, fix or drop it, and the live board reflects it. That inspect-and-hand-fix loop is the operational reality of running any board with strangers on it, and it's a lot less painful when the data isn't hidden behind an ORM you have to interrogate.
A few cheap guards on the write path go a long way, and none of them require sophistication: cap the maximum accepted score to something the game can plausibly produce, trim and length-limit the name, reject empties. It won't stop a determined person hitting your endpoint directly — a public score endpoint is trivially forgeable, and you should assume that — but it filters the accidental noise and the lazy tampering. Treat the numbers as untrusted input, because they are.
The security bit people skip
Worth saying plainly: an open POST endpoint that anyone can hit has no authentication by default. For a hobby arcade board that's usually a fine trade — the worst case is fake scores you clean up in the SQLite editor. But it does mean the board is not authoritative and you shouldn't wire it to anything that matters, like payouts or rankings people care about competitively, without adding real validation. Know which one you're building.
A reproducible shape, not a magic trick
If you wanted to redo the V2EX builder's move in a way that lasts, the sequence is unglamorous and that's the feature:
- Generate the game as static HTML/JS with whatever assistant you like, and host it so it has a live URL.
- Write a small Python endpoint with two routes — submit score, fetch top scores — backed by a single SQLite table.
- Point the game's "game over" screen at those two routes.
- Open the table directly whenever you need to prune fake entries.
The first step is where all the excitement is and where almost none of the durability lives. Steps two through four are boring, small, and the reason the thing is still standing next to you a week later.
There's a related grumble in the community worth honoring here — a post pushing back on the "one sentence, whole app, one person replaces a team" self-media narrative, pointing out that reliable software still needs someone to define requirements, make design calls, weigh trade-offs, and accept the result. The leaderboard is a perfect small illustration. The model generates the fun part in an afternoon. A person still has to decide what state to keep, how to store it, and how to clean it when strangers abuse it.
If you're new to wiring a front end to a small backend, the pattern is common enough that it's a good first AI coding project — small surface area, immediate feedback, and a real thing at the end that other people can touch. Just keep the two halves separate in your head. Regenerate the game as often as you want. Guard the table like it's the only part you'd be sad to lose, because it is.