GAMESLASHIridium Reach: lessons from 15 rounds of AI visual reviews
By GameSlash
A creator's case study of building a browser space shooter with Claude Code, testing it through 15 visual-review rounds, and finding problems through human playtesting.
Jason Croucher built Iridium Reach with Claude Code agents and had other agents review the game's screenshots across 15 rounds. His account shows how repeated visual critiques helped refine a browser space-shooter demo, while human playtesting still found problems the critics missed.
What was actually built?
Iridium Reach is a browser-playable first-person space shooter built with three.js. The author describes procedurally generated planets and visual effects, pirate ship battles, shields, a heat-limited cannon, and warp travel. The project was directed and playtested by Jason Croucher, while Claude Code agents produced most of the code. See the repository and the developer's own account.
How did the AI reviewing loop work?
In the documented 'gauntlet' workflow, several AI workers built different subsystems. A separate critic compared screenshots against an intentionally very high visual target, wrote defect reports, and fed those findings into the next round. The developer records fifteen rounds across four runs; the target was not fully reached. That is a process claim from the creator, not an independent test.
For someone vibe coding a game, the useful pattern is simple: define what good looks like, ask AI to capture the current game, compare the two, change one thing, and test again. Visual judging cannot confirm that controls are responsive or combat is fun.
What still went wrong?
The README openly notes that asteroids only appear in the first star system and that the ship's computer speaks during much of combat. It also says the human tester found issues the fleet of AI critics missed. A performance target of 60fps at 1080p is reported on an Apple M4, but is not a promise for other machines.
A practical checklist for your next AI-made game
Ask your agent to take screenshots of the menu, combat and a later level; compare them for consistency; then personally play from start to finish and write down the failures. Always test the second area, because errors may hide beyond the opening scene. The project links to a browser demo. These lessons come from the creator's development report; the screenshots are the creator's own examples.
The code is MIT licensed, while the voice clips are distributed under separate ElevenLabs terms. Do not assume that licensing the source code grants the same permissions for every sound. The practical lesson is not that AI replaces QA; it is that repeated visual reviews and real human play sessions catch different kinds of problems.