01Problem
A higher-or-lower game lives or dies on its catalog. It needs thousands of recognizable movies with accurate ratings, working posters, and real taglines. It also needs to cost nothing to run and be discoverable by search engines, even though the game itself is a JavaScript single-page app.
I also wanted to find out how far an autonomous coding agent could carry a real product. That meant answering two questions: how do you give it work it can finish, and how do you stop it from doing damage at catalog scale?
02Build
The agent loop
The agent runs unattended on one of my own machines. Work reaches it as a written brief, and it hands work back as a written report. 26 of these briefs and reports live in the repo's planning/ folder.
- 01
Task brief
Goal, scope, constraints, deliverables, verification expectations
- 02
Agent run
Implements in the repo and runs the tests
- 03
Report
What changed, files touched, what was verified, follow-ups
- 04
Follow-up
The report's recommendations seed the next brief
The product
03Challenges
An agent pass broke the catalog
A subagent asked to add 500 movies rewrote the catalog file and didn't finish. Its own report said so: the expansion "did not fully land" and needed "immediate remediation before merge/use."
Treat it as a process bug, not a one-off. Catalog writes now go only through scripts that take a timestamped backup first, append rather than rewrite, dedupe by normalized title, year, and IMDb ID, and emit a report. The rebuild then went in seven small verified batches instead of one big rewrite.
Keeping future agents consistent
Every new session starts cold. Without a standard, each agent invents its own way to add movies, and quality drifts.
CATALOG_PIPELINE.md exists "so future agents follow the same ingestion/verification standard instead of doing ad hoc catalog edits." It spells out the required row shape, identity resolution, and dedupe rules. A poster counts as ready only after a HEAD (or ranged GET) returns an image/* response, and taglines must be real, never invented.
Search traffic for a JavaScript game
A single-page game gives crawlers almost nothing to index.
Put every critical signal in static HTML, and generate a real page for each movie and genre from the catalog. Tracking parameters are stripped at runtime with history.replaceState, so canonicals stay clean. Asset URLs are cache-busted with the catalog version.
Static hosting, external images
No server to fall back on, and poster hosts can fail at any time.
The catalog is bundled, so gameplay is deterministic. Designed fallback cards cover any image that fails to load, and broken-URL remediation scripts re-validate posters in bulk.
04Impact
- 2,000movies in the catalog, all with a validated poster URL
- 2,000+statically generated movie and genre pages, plus a sitemap
- 130Vitest tests passing across game logic, catalog integrity, page generation, and SEO
- 18 / 19commits authored by the autonomous agent, driven by 26 briefs and reports
- $0backend. Deployable to any static host or CDN.
Sources: the movie-hilo repository (catalog metadata, planning folder, git history). Test count is from a local run in October 2026. Traffic and engagement numbers are omitted.
05Stack
- Game
- vanilla JavaScriptHTMLCSSlocalStorage
- Data pipeline
- Node.js scriptsIMDb public datasetsstreamed TSV parsing
- SEO
- static page generatorJSON-LDOpen Graphsitemap.xml
- Testing
- Vitestjsdom
- Agent workflow
- autonomous coding agenttask briefsrun reportspipeline spec
- Mobile
- Flutter