When I'm running eight game development sprints in a week, I don't have time to open every sprite and look at it. But I also can't ship broken art.
The usual solution is to slow down. I tried a different one: make the AI agent that generates sprites also verify them — without my eyes in the loop.
This is N=1. It worked for six assets last week. I don't know yet if it scales to sixty.
The Problem
My art pipeline works like this: I queue art requests, an agent (Iris) generates pixel sprites, and the results land in the project. The agent runs on its own schedule. I review at the end.
The review step was becoming the bottleneck. Not because it's hard to look at a sprite — it's not — but because "look at this and tell me if it's right" is a task that only I can do. At eight sprints a week, that's a lot of small interruptions that couldn't be batched or delegated.
What I wanted was a gate that could ask the important questions automatically:
- Does this sprite use only the palette I defined?
- Is it the right size?
- Does it look substantially different from the previous version? (Regression check)
The Implementation
The core tool is verify_sprite.py. It runs outside the game engine — pure Python, no Unity dependency — which means the agent can call it in any environment.
Four checks, in order:
Palette compliance
The game has a defined palette in GamePalette.hex. Any pixel that falls outside it counts against a threshold. The threshold is asset-type-dependent — a background sprite gets more tolerance than an icon, because backgrounds often blend colors at edges.
python verify_sprite.py --sprite hit_effect.png \
--palette GamePalette.hex \
--type sprite \
--threshold 0.05Pixel size and aspect ratio
Simple but catches a class of bugs I used to only find in Unity. If the expected size is 16x16 and you get 32x32, something upstream went wrong.
SSIM regression
For assets that have previous versions, ssim_regression.py computes structural similarity against the registered baseline. Too similar to the baseline means the update had no effect. Too different means something unexpected changed.
The tricky part here: you need two thresholds, not one. A hit effect that's "40% different" is fine — that might be intentional. A terrain tile that's "40% different" from its baseline is a problem.
Results From Last Week
Six assets went through the pipeline: a hit effect sprite, three NPC reward icons, a combo finisher particle, and a leaf particle.
6 out of 6 passed. I still opened each one after the fact, and the pipeline agreed with my eye on all of them.
That's the good news. The honest caveat: this is a single week of data, six assets, generated by the same agent with consistent prompts. The false-negative rate (pipeline passes, human rejects) is 0% — but I don't have enough data to know if that holds.
What I Haven't Solved
The harder problem is creative judgment. The pipeline can tell me "this sprite uses 4.8% off-palette pixels." It can't tell me "this hit effect doesn't feel satisfying." That's still a human judgment, and I'm not sure it can be automated the same way.
My current hypothesis: the automated gate handles the objective failures (palette, size, regression), and I reserve my review time for the subjective ones (does it feel right). In practice this means my review time drops from "look at everything" to "look at things that passed the gate but still need a feel check."
I also haven't tested what happens when the agent starts generating more creative variations — assets that are intentionally very different from the baseline. The SSIM thresholds will need calibration as the art style evolves.
The Bigger Pattern
What I'm actually building here is a principle, not just a tool: the agent that creates a thing should also be responsible for verifying it, within the limits of what can be verified objectively.
This matters because verification is where quality problems are caught — and if verification always requires a human, you've created a permanent bottleneck that scales with the rate of output, not the rate of human attention.
Pixel art is a tractable starting point because the quality criteria are reasonably well-defined. I'm curious whether the same approach generalizes to other outputs — written descriptions, level layouts, audio cues — where the quality criteria are fuzzier.
Evolution Log
- 2026-04-07 — Initial observation. Six assets verified, 6/6 PASS. Palette compliance + pixel size + SSIM regression pipeline complete.