Two kinds of “fixed”
A symptom fix makes the visible failure go away. A root-cause fix removes the condition that produced it. Both can look identical in a five-minute playtest. They diverge the next time the player takes a slightly different path, reloads a save, or opens a menu the patch never considered.
AI-native production makes the cheap fix cheaper. A model will often propose the smallest text change that satisfies the prompt: clamp a number, skip a branch, disable an input, catch an exception and continue. Those can be legitimate last-resort guards. They are not a diagnosis.
The cost shows up later: a dialogue that cannot be clicked because look-input is still captured, a GPU context that comes back empty, a survival number that is written from two owners, a Steam page that does not match the build. Those are categories of real CONTRABAND incidents. This essay will not retell them. It will insist you use the same questions on the next failure, including failures the model is eager to “just patch.”
A method that can be evidenced
Martinez AI Studios Academy only publishes a CONTRABAND case when the incident can answer a fixed set of questions: what the player saw, why it mattered in play, how to reproduce it, which system owned the behavior, which assumption was wrong, what the root cause was, what the smallest honest fix was, which regression would catch it again, and what a release check should remember.
That template is the teaching. It is slower than “ask the model to fix it.” It is also how you keep a commercial game from accumulating invisible writers. This page does not copy those incident bodies. The verified write-ups live on the case-study hub. Use them as worked examples of the method, not as a second copy of this essay.
If a topic cannot yet answer every section, it stays unpublished. That is why the public set is five incidents, not a hundred. Quality is the point. A thin page that only repeats the word “root cause” for ranking would violate the same discipline the cases are trying to teach.
Where the method shows up
The public set is small on purpose: state and arrival distance, pointer-lock versus dialogue, WebGL context lifetime, survival progression, and Steam release gates. Each is a different surface. The shared lesson is not “here is a clever snippet.” It is “do not stop at the first red pixel.”
If you are tempted to write a general WebGL tutorial by paraphrasing the context-lifecycle case, don’t. The case is the authority for that incident. If you are tempted to treat Steam publishing as a vibe instead of a gate list, read the release-gates case and then return to the flagship production map — which is still a map, not a finished lecture series.
Using AI without laundering the diagnosis
It is legitimate to ask a model for hypotheses, search terms, or a first patch. It is not legitimate to skip reproduction, ownership, and player impact because the patch compiled. The person directing the work still has to say whether the failure was data, control flow, lifecycle, or a mistaken rule.
Regression tests protect a known class of mistake. They do not prove the game is fun. Play remains required. The Academy will not pretend that a green suite is a shipped product, and it will not invent QA headcount or coverage percentages that this project has not published.
What to read next
If you need the philosophy underneath this method, start with what AI-native development is — and is not. If you need the architectural question that makes root cause possible, read who designs the system. Then open the CONTRABAND hub and pick one incident. Read it as a practitioner, not as a tourist collecting keywords.
The 170 flagship lessons are free to read. You can optionally support the Academy on Stripe. None of the case studies are a paid gate. They exist so the Academy can teach from a real process without turning postmortems into advertisements.