When Jev Plays the Game, Who Captures the Bug?

An agent that plays the game for us seems like it should remove a large part of repetitive testing. But when the human player disappears, another role disappears with them: the person watching the screen who can say, "Something odd just happened."

TypeSafe AI released Jev in early access on September 15, 2026, alongside a Doom gameplay demo. A fast model keeping a game moving is interesting. For a QA engineer, the more important question comes one step later: when automated play reaches a broken state, what happened immediately before it?

What Jev actually did

Jev is closer to a decision function inside code than a chatbot that generates free-form text. Give it structured state and a predefined set of actions, and a typed primitive such as Choice returns a selection, probabilities, and confidence. The game then executes an action from the set it already allows.

The official explanation includes an important caveat. The Doom demo used structured state containing text, not screen images, and TypeSafe notes that a non-AI bot could play better. This is not a universal bot that can be dropped into any game. The project still has to decide which state to expose, which actions are legal, and how Unity executes a selected action.

The new evidence gap in automated play

When a person is playing, they notice a character getting stuck in a wall or repeating the same move. They save a video, write down what they remember doing, and attach logs. Automated play may explore more paths overnight, but if the only artifact in the morning is position invalid, a developer still has to walk the path again.

Failure evidence has to scale with test execution. The final state alone is not enough. We need the sequence: which state went to Jev, which action it selected, how confident it was, and what Unity actually produced. This goes beyond a single game-state snapshot. It is about preserving the interval before the failure.

Let the game judge the anomaly and Rekon keep the evidence

The integration becomes clearer when each layer has one job. Jev chooses a high-level action. Unity validates that the action is legal in the current state and executes it. Game-specific test code decides whether an invariant has failed. That failure point triggers Rekon capture.

using RekonOps.Rekon;

Debug.Log($"[Jev] step={step} action={actionName} confidence={confidence:F2}");
RekonContext.Add("jev.step", step.ToString());
RekonContext.Add("jev.action", actionName);
RekonContext.Add("jev.confidence", confidence.ToString("F2"));

if (anomalyDetected && !captureRequested)
{
    captureRequested = true; // Reset to false when the next autoplay run starts
    RekonContext.Add("anomaly.reason", reason);
    Rekon.Capture($"Jev autoplay anomaly: {reason}");
}

Log every action so the step sequence remains in the log stream, and attach the current step, action, and confidence as context. The captureRequested latch prevents the same anomaly from creating a report on every frame and is reset when the next run begins. When the condition first becomes true, Rekon.Capture() follows the same path as the capture hotkey. With FFmpeg available in a PC/Mac/Linux Play Mode or Standalone environment, it can preserve roughly the preceding 60 seconds of video alongside logs and baseline game state. The mechanism that keeps the past available is covered in the rolling-buffer approach.

What counts as an anomaly?

Neither Jev nor Rekon can decide this for the project. The game has to define the edge of a valid state.

• Position has not changed for a fixed time after a movement action
• The same action repeats N times without progress
• Health is zero while the entity remains in an Alive state
• A scene transition or combat encounter exceeds its timeout
• Jev repeatedly falls below a confidence threshold and the runner enters SafeStop

The last case is not automatically a game bug. The state may be missing information, or the action set may be poorly designed. Low confidence is better treated as a signal to preserve a reviewable interval than as a failure verdict on its own. Capturing every low-confidence decision would only create report noise, so combine it with game signals such as repetition or stalled progress.

Automation is not ownership of quality

There is no native Jev-to-Rekon integration that makes this automatic today. Each game still needs a state/action adapter and its own anomaly conditions. Rekon video capture currently assumes desktop plus FFmpeg; mobile runs need a logs-and-state-first approach. Hiding those boundaries can produce an impressive demo, but not repeatable QA infrastructure.

Automated play is valuable because it can walk more paths than a person has time to cover. Quality engineering begins when the failed paths remain explainable afterward. With Jev choosing actions, project code judging anomalies, and Rekon preserving the preceding context, an autoplay demo starts to look more like a test runner a team can actually investigate.