When most of the hands-on work is done by AI agents, the question that matters is not “can the agent write the code” — it usually can — but “what stops a confident, plausible-looking mistake from reaching a player?” Our answer is a QA gate: a fixed set of automated checks that a change must pass before it is allowed to ship. This is the honest account of that gate. It is not a silver bullet, it does not decide whether a game is any good, and it fails in specific, predictable ways. But it catches a surprising amount, and knowing exactly where its blind spots are is the whole point of writing this down.
The premise: a gate that must pass before anything ships
The gate is a hard precondition, not a suggestion. A change — a new mechanic, a balance tweak, a one-line fix — does not move from “an agent finished” to “this is going out” until it clears every check in the gate. The checks run the same way every time, in the same order, whether it is the first change of the day or the fortieth. That is the single most important property: consistency. A tired human reviewer lets something slide at the end of a long week; the gate does not get tired and does not make exceptions “just this once”.
The gate is deliberately made of several independent checks rather than one big one, because each catches a different class of problem and they fail loudly for different reasons. In broad strokes the lanes are: static analysis (the analyzer and linter, run clean with no suppressed warnings); unit and widget tests (the change is exercised, not just present); build verification (the app actually compiles and packages for the platforms it targets, not just on someone's machine); a content and claims check (any number, statistic, store string, or factual claim in the change is traceable to something real); accessibility basics (labels, contrast, focus order, reduced-motion behaviour); and a runtime smoke pass (the build boots, the first interactions work, nothing crashes on launch). A change that trips any lane goes back to be fixed; only a clean pass across all of them earns a ship.
What the gate catches well
The gate earns its keep on the whole category of mistakes that are objective, mechanical, and cheap for a machine to check exhaustively — exactly the mistakes a human is worst at catching reliably because they are boring.
Regressions and broken builds. The clearest win. If a change breaks compilation, breaks a test that encoded a behaviour we care about, or reintroduces a bug a previous test was written to guard, the gate stops it before it travels any further. “It builds on my machine” is not a category the gate accepts; build verification runs against the platforms we actually ship to, so a change that quietly depends on a local quirk is caught rather than discovered by a player on launch day.
Analyzer errors and dead-obvious defects. Static analysis is unglamorous and enormously effective. Unused variables, unreachable code, null-safety violations, type mismatches, the accidental leftover of a debugging experiment — the analyzer sees all of it instantly and does not get bored on the thousandth file. An agent that “helpfully” left a stray change riding along with the intended one is frequently caught right here, because the stray change trips a warning the intended one did not.
Broken links and missing assets. The kind of rot that accumulates invisibly. A link that points at a page that no longer exists, an image reference to a file that was renamed, an asset that was declared in a manifest but never actually added — these produce no crash and no error a casual playthrough would surface, but they are trivial to check mechanically and embarrassing to ship. The gate treats them as failures, not warnings.
Unverified claims and numbers. This is the check that matters most for a studio that writes as much as it builds. Any empirical claim, statistic, store-listing string, or comparison that appears in a change has to be traceable to a real source; a number that cannot be backed up is a gate failure, not a stylistic note. It is the same discipline this very blog runs on — we do not publish metrics we cannot stand behind, and the gate is where that rule is actually enforced rather than merely intended.
Accessibility basics. The floor, not the ceiling — but a floor that is easy to fall through by accident. Missing semantic labels on interactive controls, contrast that drops below the threshold, a focus order that jumps around, motion that ignores a reduced-motion preference: these are checkable, and the gate checks them. It will not tell you whether an interface is pleasant to use, but it will stop the most common ways an interface becomes unusable for someone relying on assistive technology.
The through-line is that the gate is excellent at questions with a definite right answer. Does it compile? Does the test pass? Does the link resolve? Is the number sourced? Is the contrast ratio above the line? These are binary, and a machine answers them faster and more consistently than any person can. That is real quality, and it is the majority of quality problems by volume.
What the gate misses — honestly
Now the part that keeps us honest. The gate is blind to an entire dimension of quality, and it is precisely the dimension that decides whether a game is worth playing. No amount of green checks touches any of the following, and pretending otherwise would be the dishonest move.
Is it fun? The gate has no opinion. A mechanic can compile, pass every test, build cleanly, and be joyless. Fun is not a property you can assert in a unit test; it emerges from the interaction between a player and a system over time, and the only instrument that measures it is a human actually playing. Every check in the gate can be green while the answer to the only question that matters is “no”.
Game feel. The difference between a mechanic that feels alive and one that feels dead lives in timing, easing, feedback, sound, and screenshake — the details we wrote about in the anatomy of game juice. A jump that lands a few frames late, an impact with no weight behind it, a transition that is technically correct but subtly wrong — the gate sees a passing build. The player sees a game that feels cheap. Feel is authored and felt, not asserted.
Balance. Whether a difficulty curve is fair, whether an economy is exploitable, whether one strategy quietly dominates all others — these are emergent properties of a system played by real people, often only visible after many sessions. A test can confirm that a number is what we set it to; it cannot tell us the number is wrong. Balance is discovered by playing, and increasingly by watching other people play in ways we did not anticipate.
Subtle visual and audio glitches. A texture that flickers only at a particular camera angle, a sound that cuts out under a specific overlap, a one-pixel seam on one aspect ratio, a particle effect that looks wrong only in dark mode. The runtime smoke pass confirms the app boots and the first interactions work; it does not have eyes and ears attuned to “that looks slightly off”. These are caught by a human noticing, not by a check passing.
Emergent bugs. The defects that only appear from the combination of features nobody tested together, the state you can only reach by doing three unusual things in sequence, the race that shows up on a slow device under memory pressure. Green tests are necessary and nowhere near sufficient here: for anything involving timing, real devices, concurrency, or resources, the honest question is whether the test could even reproduce the failure mode — and often it cannot. A deterministic test is a checkpoint, not a conclusion.
“Technically passes but bad UX”. The most insidious category, because it looks like success. A flow can be fully accessible by the letter of every checkable rule and still be confusing, tedious, or quietly hostile. A form that validates correctly but punishes a mistake harshly; a menu that is reachable but buried; copy that is accurate but cold. The gate confirms the boxes are ticked. It cannot tell you the experience is bad.
Raising the floor, not the ceiling
The cleanest way we have found to describe the gate is that it raises the floor without touching the ceiling. It reliably prevents a whole class of things from going wrong — the broken, the regressed, the unsourced, the inaccessible — which is genuinely valuable and frees human attention for the work that actually needs it. But it cannot make a game good. The distance between “does not crash and passes every check” and “is worth someone's time” is the entire craft, and it lives above the ceiling the gate can reach.
So a human still signs off, and this is not a transitional inconvenience we expect to automate away. It is the design. The gate is the backstop that catches the mechanical mistakes an agent can make confidently and at speed; the human is the judgment that decides whether the thing is any good and takes responsibility for shipping it. A green gate is permission to ask the interesting question, not an answer to it. If you want the fuller picture of how the crew and its review gates fit together, that is the subject of how we build games with an AI agent crew; this post is the close-up on the one gate that stands between “finished” and “shipped”.
The mistake we work hardest to avoid is the one the gate makes tempting: mistaking a full row of green for a verdict on quality. The checks are real and they matter, but they answer “is this broken?” and never “is this good?” Keeping those two questions separate — and refusing to let the first quietly stand in for the second — is what keeps the gate an asset instead of a comfortable illusion.
Notes
This is a first-hand account of our own QA gate, not a general survey of software testing. It deliberately contains no performance metrics, catch-rates, or “the gate caught X% of bugs” claims — we do not have numbers of that kind we would stand behind publicly, and inventing them would undercut the point of the piece. The check lanes (static analysis, unit and widget tests, build verification, content and claims, accessibility, runtime smoke) are described in generic terms; the value here is the honest boundary between what an automated gate can and cannot decide, not any claim about a specific internal tool. Where we describe a blind spot, it is one we have actually shipped into and learned to keep a human in front of.
Sources
The accessibility floor the gate checks against is the public standard, not an internal invention: W3C — Web Content Accessibility Guidelines (WCAG) 2.2, 2023.
Keep reading: all posts on the WizusLabs Engineering blog.