About Vibe Arcade — How These Games Get Made

What This Is

Vibe Arcade is a one-person experiment, started in early 2026, to find out how far current AI models can be taken on long-running, real-world software work — and, just as importantly, where the rough edges are and where a person still has to stay in the loop. The games are the proof: if the process does not produce something genuinely worth playing, the experiment has failed.

The setup: an overnight pipeline plans a new HTML5 game from a written spec, builds it, runs lint, security and a playability rubric, and commits only if every gate passes. If anything fails, I triage it in the morning. Over 100 playable games have come out of this so far. Every one of them is free in the browser — no signup, no install, no email capture.

The second output is a set of running notes — what the AI surprised me with, where it failed quietly, what got better between model versions, and which tasks I now trust it with versus the ones I keep tight human review on. I write these up as how-we-built posts on the blog. Each one is a data point, and each one names the things that went wrong as well as the things that worked.

Benchmarks are easy to game; a hundred games that strangers actually play is a harder test, and a more honest one.

What a Person Checks Before Anything Ships

AI writes the code here — all of it. Not a single line of what runs on this site was typed by a human, and that is the point of the project rather than something to bury. What a person does is decide: what gets built, what the bar is, whether a build clears it, and what to do about it when it does not. When something is broken I diagnose it and tell the AI what to change; I do not go in and patch it myself, because a fix I made by hand would be me quietly failing the experiment. "Built with AI" is not a quality standard, so here is the one this site actually runs on.

Nothing is built without a written spec. Genre, controls, scoring formula, win and lose conditions and a trademark check are settled in writing before any code is generated. Concepts come from me or from the top-voted entries on the player idea board.
Every build is scored against a 60-point playability rubric covering playability, visuals, whether it is actually fun, integration, mobile and code quality. The target to ship is 58 of 60, and a build that has not reached it keeps iterating. The only exception is the end of a build night: rather than lose the work, a game may ship at a 53 floor and get finished by the weekly improvement pass. Some builds never clear the bar and are dropped.
Automated gates run before a person looks at it — a structural lint, a two-tier security scan, a JavaScript syntax parse, and a real headless-browser test that loads the game and fails the build on any uncaught error or a Start control that throws.
A person reviews every failure by hand the next morning. Anything touching shared architecture, anything content-sensitive, and anything that could fail silently in production is held for manual review regardless of score. Review means reading the failure, working out what actually went wrong, and writing the instruction that fixes it — the AI makes the change, and it gets re-run through every gate afterwards.
Games get played, and pulled when they do not hold up. Human playtesting is the only thing that catches "technically working but not fun". Several games have been rebuilt or removed after that pass, and a separate improvement pass runs weekly on games already live.
When something does go wrong, it gets written up by name. One crossword build reached QA with fill that was not real English — it validated as data and the lint passed, and the only thing that caught it was the QA step that actually solves the puzzle. It was fixed before release, and the whole episode is on the blog, because the failures are the useful part.

The site is run by one person, J. If you find something broken, wrong or unfair, please tell me — I read everything that comes through, and I would rather hear it from you than not.

What I'm Trying to Figure Out

Three open questions drive the experiment:

1. How much of a non-trivial software project can the AI handle autonomously?

Game by game, what fraction of the work clears every gate without human intervention? Many months and 100+ games in, more nights ship cleanly than don't — but the failure modes are still informative when they happen.

2. Where do the rough edges show up — and how do they shift as models improve?

Some categories of failure recur (content quality that passes structural lint, novel mechanics that need many human QA passes, cross-environment iframe issues). Tracking them over model versions tells me what's actually getting better in practice, not on benchmarks.

3. Where does a human still have to stay in the loop?

Auto-merge clears security, lint, and the playability rubric. I keep manual review on for anything that touches core architecture, anything content-quality-sensitive, and anything that could fail silently in production. The line between those buckets keeps moving as the rubric and lint gates get better.

How the Pipeline Works

The pipeline is the experimental apparatus. Each game runs through the same gate sequence; results compound across runs because every game is built against the same shared infrastructure (CSS, leaderboard widget, integration lint).

1. Spec

A planning model writes a detailed spec from the concept — genre, theme, scoring formula, integration checklist, naming, trademark notes. Either I author the concept or pull a top-voted submission from the idea board.

2. Scaffold + iterate

Implementation models build the game in iterations. Each iteration runs a 60-point QA rubric (playability, visuals, fun, integration, mobile, code) and writes feedback for the next pass. Most games clear the 58-point ship target within 3–4 iterations.

3. Lint gate (grep-based)

Structural rules: leaderboard wiring, canvas sizing, schema tags, no banned imports, etc. Grep is roughly 10× cheaper than a model pass and catches a surprising amount — so the pipeline runs lint first and only spends model tokens on the things grep can't check.

4. Security gate (two-tier)

Universal categories first (the OWASP-style classes), then a project-specific tier that targets the exact infrastructure this site uses. The project-specific tier catches more real issues than the universal one — generic models can miss framework-specific patterns.

5. Playability rubric + ship decision

Final scoring pass. If the score clears the threshold and every gate is green, the build auto-merges. If anything fails, the run goes into manual review in the morning.

A separate improvement pipeline runs a couple of times a week to deepen existing games — that's how games grow past their initial overnight build.

What I've Found So Far

Concrete observations from the run so far, rather than abstractions:

The AI picks structural architecture without being asked, and often picks well. Path Runner shipped with a segmented procedural track model I never specified — segments spawn ahead of the player and despawn behind. It turns out that's exactly the right answer for an endless runner because it sidesteps browser memory limits. Mini Cross shipped iter-4 with a six-tier streak celebration ladder I never asked for. Deadlock proposed Castle-Doombad-style narrow-room layouts in a single commit when the spec said almost nothing about geometry.
Content-quality bugs slip past structural lint. Mini Cross iter-1 shipped crossword answers that weren't real English words — they validated as data, the lint passed, but a human (or the QA gate's solve-the-puzzle pass) was the only thing that could catch it. Lint and security can verify shape; they can't verify meaning.
Fix-once-globally pays compound interest. A single CSS rule in main.css fixed tablet tap responsiveness across all 20+ games in one commit instead of 20 per-game edits. Moving from a chat interface (where each game was built independently) to a unified pipeline is what made shared CSS, a universal leaderboard widget, and structural conventions consistent across every new build.
Genuinely novel mechanics still need a lot of human QA. When I'm specific about what a game should look like and how its rules work, the loop usually lands in 3–4 iterations. Anything where the rules need to be invented takes many more passes — and human playtesting is the only thing that catches the "this is technically working but it isn't fun" failure mode.
"Vibe coding" oversells the prompts and undersells the rules. The pipeline is roughly 90% scaffolding and guardrails. The AI is fast hands; the rules I wrote (the rubric, the lint, the structural conventions) are what keep it from shipping junk. Vibe coding implies vibes-first; this is rules-first, AI-executes-fast.

If you're interested in the longer write-ups, many of the games have a how-we-built post on the blog with what surprised me, what broke, and what changed across iterations.

Free, Solo, Closed-Source

A few honest disclosures since the framing of "experiment" can be ambiguous:

Free for players. No signup, no account, no email capture, no in-app purchases, no paywall. Leaderboards work with a chosen display name on a per-game basis.
Supported by advertising. The site runs display advertising to cover hosting and keep the games free. Ads never sit inside the game area and nothing is gated behind watching one. What advertising cookies do, and how to opt out, is set out in the privacy policy.
One person — J. No team, no studio, no investors. The "we" in earlier versions of this page was aspirational; corrected.
Pipeline is closed-source. The pipeline is the experimental apparatus, and sharing it would replace independent reproductions with one shared codebase — collapsing the comparison signal the experiment depends on. Architecture is described above and on the blog; the implementation is private.
What I'll do with what I learn. Inform where I lean on AI in my day-to-day work — for tasks it's actually good at, and to be careful about handing it work where the stakes are higher and the failure mode is harder to detect.