Start your AI Factory with BugHunter

Why QA goes first

Every worker that follows needs an unfakeable check and accumulated game knowledge. QA is the only job that produces both.

The evidence answers a question about this build: did the player journey meet the expectation? The knowledge carries forward what the team has learned about the game's screens, mechanics, starting states, and accepted checks. Together, they give the next piece of work a result to aim for and context to work from.

What makes it a factory?

An AI Factory is an operating model for repeated software delivery. Work enters a queue, changes are made within defined limits, checks evaluate the result, and failures return for another attempt. People own the goals, boundaries, and release decisions.

3ALICA's AI Factory method puts a useful condition on that loop: autonomy must depend on checks that are affordable to repeat, run frequently, and cannot be satisfied by changing the evidence instead of fixing the result. Applied to games, the question becomes: what observation would convince the studio that this player journey works on this build?

Check the complete player journey

Imagine a coding agent updating a game's reward flow. The project compiles. The unit tests pass. On a device, the player completes the level, taps Claim, and receives nothing. Faster code generation has shortened one part of delivery. The studio still needs to know whether the game works.

Return to the missing reward. A function-level test might confirm that a reward calculation returns the right value. A gameplay check follows the journey: finish the level, open the reward screen, claim the reward, and inspect the resulting balance. A persistence check might then restart the game and confirm that the balance remains correct.

These checks answer different questions. The build pipeline can establish that the software compiles. Gameplay QA can establish whether a defined interaction reaches its expected outcome in the tested environment. Neither result, by itself, proves that every player journey works.

The expectation must be agreed before the run. 'The game looks fine' is too broad. 'Claiming the level reward adds the specified amount once, and that balance survives a restart' gives the team a behavior it can inspect and repeat.

Turn a failed check into the next piece of work

A QA result becomes useful to the factory when the next person or process can act on it. A message saying 'reward broken' still leaves the developer to reconstruct the build, state, and sequence of events. A useful handoff ties the observation to the tested build and shows the steps, expected result, actual result, and available evidence.

After a fix, repeat the accepted check on the new build. Keep the original failure and the retest connected. That comparison is the basis for accepting the repair; generating a patch or completing a run is an intermediate step.

A reliable workflow also preserves uncertainty. If the game never launched, the reward was not tested. If the run stopped before the assertion, the result is incomplete. Those outcomes need their own status instead of becoming a pass or being silently dropped from the report.

Game knowledge carries forward

A QA run is also an encounter with the game: where a flow begins, what the player can do, which state allows an action, and what the team expects to happen next. Accepted findings and checks turn those encounters into reusable knowledge.

For the next worker, that knowledge is a starting point. It can explain how to reach a feature, which behavior has already been accepted, and which paths need to be checked again after a change. The factory can build on what the team has learned instead of asking every worker to rediscover the same game.

That is the direction for Nodemori's workers beyond QA. BugHunter comes first because testing creates a reason to learn the game and an immediate use for that knowledge: checking the next build. Your team decides which observations become accepted knowledge and which still need investigation.

Where BugHunter fits

BugHunter is the AI QA worker your team operates. Nodemori helps connect the game and prepare the first checks. Your team selects builds, starts runs, reviews findings, and reuses approved checks across later builds. Additional hands-on support is available when the team needs it.

The work spans four tasks: Scout to understand a selected area and propose checks; Freeplay to explore a goal within a run limit; Testcase to execute approved steps against an expectation; and Regression to repeat accepted checks on a later build. Availability depends on the game and build.

For an AI Factory, repeatable testcase and regression work provide a practical starting point. Exploration can reveal a candidate issue; an accepted, repeatable check gives the team something to use on the next build. That is how individual findings can become a growing body of release evidence.

Using an AI QA worker does not automatically create an independent release gate. The studio still has to decide which results can block delivery, protect the acceptance criteria, and define how uncertain findings reach a person.

Start with one loop the team can trust

Choose a recurring journey whose expected outcome is clear: tutorial completion, a saved progression state, or a reward claim. Establish the supported test environment and a known starting state. Then operate the whole sequence before expanding coverage.

• Agree the steps and the observable result with the person who owns the feature.
• Run the check on a known working build and inspect the evidence.
• In an isolated test build, deliberately break the target behavior and confirm that the check detects it.
• Repeat the check after the repair and preserve both outcomes.
• Define who handles a failure, an incomplete run, or an ambiguous result before using the check to control delivery.

Keep creative judgment with the team

A repeatable check can establish whether the specified reward was granted. It cannot settle whether the reward feels satisfying, whether the level is worth replaying, or whether the economy serves the studio's design goals. Those questions need playtesting and product judgment.

The factory should make that judgment better informed. AI QA takes repeatable execution into the delivery loop and returns observations the team can examine. The team keeps ownership of what quality means and when the evidence is sufficient to release.