Review a level-tool script through a safe fixture

A level designer can verify a tool's output without being asked to certify unfamiliar source code. An engineer can review that source without deciding whether the output matches the designer's intent. A useful cross functional AI workflow gives each reviewer a specific surface to inspect.

Here is a small example: a script should report duplicate spawn-point identifiers in a level JSON file. It must not repair the level automatically. Reporting is a good first boundary because the input can stay unchanged and the expected output can be written before implementation.

Start with a disposable project

Create a folder containing only the sample below. Do not point an early tool at the studio's level library. The synthetic fixture contains two spawn points named gate and one named well.

{"spawns":[{"id":"gate","x":1,"y":2},{"id":"well","x":4,"y":2},{"id":"gate","x":7,"y":2}]}

Save it as sample.json. A successful report should identify gate once, with a count of two. The script should return a nonzero exit code when duplicates are found so a later pipeline can distinguish an issue from a clean result.

Give the agent a bounded task

Input: one explicitly supplied JSON file in the sample folder
Output: duplicate identifiers and their counts, sorted by identifier
Exit: 0 for clean data, 1 for duplicates, 2 for malformed input
Allowed: read that file; print a report
Forbidden: rewrite levels, recurse directories, install dependencies
Cases: duplicate ID, unique IDs, missing spawns, invalid ID
Reviewer A: level designer checks the report against the fixture
Reviewer B: engineer reviews parsing, errors, and filesystem behavior
Stop: any request to change the actual level schema

The author prepares the fixture and expected report. An authorized runner executes the tool in this disposable folder with their own tools. The agent can help implement or explain the code; the runner records the exact command and observed result.

A complete reporting script

Save this as check-spawns.mjs and run node check-spawns.mjs sample.json.

import { readFileSync } from 'node:fs';
try {
  if (process.argv.length !== 3) throw new Error('Supply one JSON file');
  const level = JSON.parse(readFileSync(process.argv[2], 'utf8'));
  if (!Array.isArray(level.spawns)) throw new Error('spawns must be an array');
  const counts = new Map();
  for (const spawn of level.spawns) {
    if (!spawn || typeof spawn.id !== 'string' || !spawn.id.trim()) {
      throw new Error('Every spawn needs a nonempty string id');
    }
    counts.set(spawn.id, (counts.get(spawn.id) || 0) + 1);
  }
  const duplicates = [...counts].filter(([, n]) => n > 1)
    .sort(([a], [b]) => a < b ? -1 : a > b ? 1 : 0);
  console.log(JSON.stringify({ duplicates }, null, 2));
  process.exitCode = duplicates.length ? 1 : 0;
} catch (error) {
  console.error(error.message);
  process.exitCode = 2;
}

The expected duplicate payload is {"duplicates":[["gate",2]]}. Whitespace in the printed JSON is not significant. Identifier comparison is exact and case-sensitive: Gate and gate remain different values. If the game treats them as equivalent, that is a schema decision to settle before changing this script.

Split the review into two concrete checks

The designer checks the sample data against the report: which markers appear twice, whether a clean sample produces an empty list, and whether the output is understandable without reading a stack trace. A screenshot of the report beside the sample level can help discussion, but the fixture and command are the reproducible evidence.

The engineer checks that the program only reads the explicitly supplied file, does not execute input, distinguishes malformed data from duplicate data, and has no unexpected write path. This example is small enough to inspect directly. Extending it to arbitrary large or untrusted files needs separate limits and review; a sample-folder workflow is not a security sandbox.

The Wagglet discussion of meaningful work in human–AI pairs is relevant because the useful division of labor follows expertise, not a blanket assumption that the person running an agent can approve every result.

Deliver evidence with the revision

Return the script, fixtures, command outputs, exit codes, and an unchanged-input check. The designer's acceptance and the engineer's code review should refer to the same revision. Installing the tool into the studio pipeline is a separate release decision, with an owner for failures and rollback.

This script deliberately does not validate coordinates, enforce a complete level schema, or repair duplicates. Those are potential next tasks. Keeping them outside the first delivery gives both reviewers a result they can actually judge.