The QA agent plays your game before you do

The worst outcome in a generative game studio isn't a mediocre game. It's a build that doesn't boot, because that costs the player the ninety seconds it took to find out, plus the confidence that the next one will work. Two of those in a row and the product is dead regardless of how good the third one would have been.

So no build reaches a person before it has been played. Not by a person: by the studio's QA agent.

Four pipelines, four agents

vbgnt is a cloud game development workstation. It runs four pipelines (design, development, QA and marketing), and each one is run by its own specialist AI agent. The design agent turns your description into a plan. The development agent builds the game. The marketing agent makes the store assets when you are ready to ship.

The QA agent sits between development and you. It playtests every build before you see it: it checks the game boots, holds its frame rate, and runs without errors. When a build fails, the failure goes back to the development agent, not to you.

The cheapest quality gate there is

Automated playtesting sounds grand. The version that matters is modest: start the game, play it for a few seconds, and watch what happens. That's a shallow test by any serious QA standard, and it catches the overwhelming majority of what actually goes wrong, because generated games fail in a very particular way: not subtly, but totally.

A missing file, a visual effect that won't run on the web, a piece of startup code registered twice, an export that silently dropped a folder. These don't produce a slightly worse game. They produce a black screen.

Three checks

Does it start

The single most valuable thing the QA agent can tell you. Web games fail at load for reasons that never show up anywhere else: memory limits in the browser, a data file that didn't make it into the build, a feature the hosting setup doesn't support. A build that boots has cleared most of the cliff.

The check has to mean "the game is running", not "something appeared on screen". A blank frame exists long before a game has done anything useful, and counting it as success would pass every broken build in the class you most wanted to catch.

Does it hold its frame rate

Generated games have a characteristic performance failure: something in the scene is far more expensive than the code implies. A particle effect spawning a thousand times more sparks than it should. A light set to cast shadows in a scene with four hundred copies of it. Physics where a simple overlap check would do.

A frame rate floor, measured while the QA agent plays, catches those. It is not a performance benchmark and shouldn't pretend to be: it's a tripwire for the game that is technically correct and unplayable.

Does it run without errors

Crashes, assets that fail to load, effects that fail to compile. Individually many errors are harmless; collectively they're the best available sign that a build is not in the state its author thinks it's in. The useful discipline is treating anything that stops the game as a hard failure and everything else as a signal the development agent gets to weigh.

Failures go to the development agent, not to you

This is the design decision that matters more than the checks themselves. When a build fails its playtest, the QA agent hands the report back to the development agent: what broke, where, and how the frame rate looked. The development agent fixes it and builds again. The person who asked for a game gets a game.

The alternative, showing "build failed: SHADER_COMPILE_ERROR" to someone who asked for a kart racer, is not a status update. It's an apology with extra steps, and it moves the debugging to the one participant who has no way to act on it.

There's a limit, obviously. The back and forth needs a cap, and a genuine dead end has to reach you eventually: as plain language about what didn't work and what to try instead, not as a stack trace. But the default is that the studio cleans up after itself.

What automated playtesting does not tell you

It does not tell you whether the game is fun. It cannot, and pretending otherwise is how you end up shipping technically flawless games nobody enjoys.

Automated playtesting answers a narrower and more useful question: is this build in a state where a human's opinion would be worth collecting. That gate is worth automating precisely because it's mechanical. Fun is decided in the conversation afterwards, by you actually playing, saying "the jump is floaty", and getting a new build a few minutes later.

Keeping those two things separate is what keeps the loop honest. The QA agent owns "does it work". You own "is it good". Neither is trying to do the other's job.

What this means when you make a game

• The first thing you open works. You spend your time on how the game feels, not on reporting that it didn't load.
• Every change is checked, not just the first build. A small tweak to the jump gets the same playtest as the original game, so a fix never quietly breaks something else on its way to you.
• Phones get the same treatment. The QA agent plays the game at phone size with touch controls too, because a link you send a friend will almost always be opened on a phone.
• When something can't be fixed, you hear it plainly. No error codes: a sentence about what went wrong and what to try.

The economics of the ten-second check

Playing a build for a few seconds is close to free against the cost of generating the game in the first place. The check adds seconds to a build measured in minutes, and it removes the failure that costs the most: a person opening a black screen and concluding the whole product is broken.

Almost every quality investment in generative software has this shape. The expensive part is producing the thing; checking it is a rounding error. Teams skip the check anyway, because the model sounded confident and the code looked right. The code always looks right. That's what the models are best at.