A software engineer posted a video of a cozy village-builder prototype on August 16-17, 2026, and the demo itself is not the interesting part. Cozy village-builder games with AI-generated assets are becoming a familiar shape of viral post — explainx.ai has already covered Opus 5's Homeworld-style space RTS, a procedural desert you can walk into, and a 3D Pokémon remake, among ten public game-building prompts that circulated the same month. What's actually worth extracting from this one is the workflow: a specific, repeatable technique for keeping creative control while an agent does the building.
Dilum Sanjaya (@DilumSanjaya), a software engineer known for showcasing AI applications in science and engineering — his earlier viral 3D cell explorer used a similar model-stack approach — asked Claude Opus 5 to build a game where the player manages a cluster of villages inside a forest, assigning tasks to villagers, with a UI matching the game's cozy aesthetic. After about 5 hours of work he had a prototype with a working in-game economy, assignable villager tasks, and "plenty of things to build" left on the list.
TL;DR
| Question | Answer |
|---|---|
| What did he build? | A cozy village-builder prototype: forest villages, assignable villager tasks, a working economy, wild animals already present |
| Which model? | Claude Opus 5 |
| How long did it take? | About 5 hours of total session time |
| What's the core technique? | A dual improvement-list loop — model self-critiques, human plays and adds their own list, human curates a combined batch of tasks per round |
| How many tasks per round? | Roughly 5-6, chosen from the merged list |
| How long per round? | About 20-30 minutes for 5-6 tasks; well over an hour for batches closer to 10 |
| Were the art assets hand-drawn? | No — generated with code by Opus 5 |
| Is this the only pattern that works? | No — he explicitly contrasts it with long-running autonomous loops and says either can be the right call depending on what you need |
The Prompt, and What Came Out of It
The starting instruction was simple in scope but specific on aesthetic: a village-builder set in a forest, task assignment for villagers, and a UI that matched a "cozy" feel rather than a generic dashboard. Five hours later the prototype had:
- A working in-game economy
- Assignable tasks for villagers
- Wild animals already present in the world
- A UI matching the intended cozy aesthetic
- "Plenty of things to build" still on the list — this was explicitly a prototype, not a finished game
In a reply to a question about whether the visuals were AI-made, Sanjaya confirmed that all assets — art included — were generated with code by Opus 5, not hand-drawn. That's a distinct claim from "the model wrote good gameplay logic": the same session produced the procedural code that rendered the cozy-styled art, which is a meaningfully different asset-generation capability than sprite or texture generation via an image model. It lines up with what explainx.ai found true across other Opus 5 game demos this summer — a recurring pattern of no external art pipeline, just shaders, procedural geometry, and code-driven styling.
The Technique: Dual Improvement Lists, Not a Long Unsupervised Run
Here is the actual workflow, in Sanjaya's own words and structure, reconstructed from the thread:
- Prompt the model to do a few things. Not the whole game — a bounded chunk of work per turn.
- When it finishes, ask it to generate a list of ~10 possible improvements, ranked by difficulty. This is the model self-critiquing its own output — surfacing what it thinks is incomplete, rough, or worth building next.
- Separately, play the game yourself for a minute or two. Write your own list of tasks, fixes, and improvements based on what you actually noticed as a player, not what the model flagged.
- Merge the two lists and pick around 5-6 tasks that combine your priorities with the model's self-generated suggestions.
- Hand that batch back to Opus 5, let it work, then repeat from step 2.
This is a loop, but it is not the kind of loop explainx.ai's own loop engineering guide describes for unattended, cron-scheduled agent runs. It's a tight cycle with a human checkpoint at every iteration, closer to the gate-placement thinking in the human-in-the-loop framework applied to a creative build instead of a production system.
Why ask the model for its own improvement list
The model-generated list matters for a specific reason: it surfaces the agent's own sense of what's rough or incomplete, which a human reviewer skimming the same build might miss entirely. A player notices what's broken from the outside — a button that doesn't respond, a villager that stands still. The model, having just written the code, can flag structural gaps a casual playtest wouldn't catch — missing edge cases, an economy loop that's mechanically present but shallow, a system that was stubbed rather than finished. Asking for both lists and merging them catches more than either alone.
Batch size is a real lever on iteration speed
Sanjaya gave a concrete timing data point: handing the model 5-6 tasks per round usually finished in about 20-30 minutes. Pushing that up to around 10 tasks could take well over an hour per round. That's not a minor detail — it's the actual knob that determines how many improvement cycles fit into a 5-hour session. Smaller batches mean more checkpoints, more chances to redirect, and faster turnaround per round; larger batches trade check-in frequency for fewer total interruptions.
The Explicit Contrast: Human-Checkpoint Loops vs. Long Autonomous Runs
Sanjaya was direct about why he works this way instead of the more commonly seen pattern: "Most of what I see other people doing involves long-running loops. I prefer doing it this way because it gives me more control over the direction of the game... Just choose whichever approach fits your needs best."
That's a real fork in how people are using agentic coding tools for exploratory projects right now, and it maps onto two genuinely different use cases rather than one being categorically better:
| Pattern | How it works | Best suited for |
|---|---|---|
| Long autonomous loop | Hand off a large task, let the agent run largely unsupervised for hours, review at the end | Mechanical, well-specified work with an objectively checkable "correct" — refactors, migrations, test-suite expansion, large batch operations |
| Tight human-checkpoint loop (the improvement-list technique) | Small batches, frequent check-ins, human plays and curates direction every round | Creative or exploratory work where "what's fun" or "the right aesthetic" is a judgment call the human wants to keep making |
This is the same tension explainx.ai's graphs-vs-loops orchestration debate covers at the architecture level — structured, checkpointed control versus simple, largely unsupervised iteration. Sanjaya's version of it is a concrete, field-tested instance: he's not arguing against long loops in general, he's naming which kind of task he's using them for and why creative direction specifically benefits from staying in the loop.
The Honest Caveat: Survivorship Bias
When someone asked follow-up questions in the replies — including whether wild animals and robber or defense mechanics were planned — Sanjaya confirmed wild animals were already in and robbers were a planned future iteration. But he also volunteered something more useful than any single feature answer: many of his experiments don't work out, and he only shares the ones he feels good about.
That's worth sitting with before treating any "built in N hours" demo as a representative baseline. A clean 5-hour prototype on a public timeline is the survivor of an unknown number of attempts that didn't make the cut. This isn't unique to Sanjaya's posts — it's true of nearly every viral agentic-coding demo — but it's rare for the person posting the win to say so directly, and it's a useful reality check for anyone trying to reproduce these results and getting stuck sooner than the highlight reel suggests.
This wasn't a one-off, either — Sanjaya posted an earlier prototype in a similar vein around August 10, 2026: a cozy Wild West railroad-tycoon and logistics game, also built with Opus 5, in about 2 hours. The pattern across both — bounded prompt, iterative improvement-list checkpoints, code-generated assets — looks like a workflow he's deliberately repeating rather than a one-time lucky run.
How to Try This Yourself
The technique doesn't require Sanjaya's exact tools. Anything you can iterate on with Claude Code or Claude in general — a small game, an app, an internal tool — is a candidate:
- Write one clear prompt. Core mechanic, aesthetic, and what "done for this round" looks like. Don't ask for the whole thing at once.
- After each round, ask for a ranked improvement list. Literally: "list about 10 possible improvements, ordered by difficulty." This is a cheap, high-value ask — it costs one extra turn and gives you a structured view into what the model thinks is unfinished.
- Use the build yourself before your next prompt. Even a minute or two of hands-on review surfaces things a text-only review pass won't.
- Merge lists, pick ~5-6 items, and go again. Keep an eye on turnaround — if a round starts taking well over an hour, you've likely pushed the batch size past where the checkpoint benefit still holds.
- Decide up front which parts of the project are judgment calls and which are mechanical. Reserve the tight human-checkpoint loop for the former; for large mechanical passes (renaming, refactors, boilerplate), a longer, less-supervised run — closer to the pattern in explainx.ai's loop engineering guide — is probably the faster path.
If you want the underlying agent-loop mechanics — retries, checkpoints, and how to structure the harness itself rather than just the prompting cadence — the agent skills guide and Claude Code commands reference cover the tooling side of building this kind of workflow into a repeatable setup.
Related reading
- Human-in-the-Loop AI: When to Let the Agent Run and When to Stop It — the gating framework this technique is a creative-project instance of
- Loop Engineering: How to Design Coding Agent Loops — the long-running, largely unsupervised pattern this technique deliberately avoids
- Graphs vs. Loops: The Agentic AI Orchestration Debate — the same structured-control-vs-autonomy tension at the architecture level
- Opus 5 Built a Homeworld-Style Space RTS From One Prompt — a contrasting demo built with a large, fan-out agent run rather than tight checkpoints
- Top 10 Claude Opus 5 Game Prompts — more public prompts for building games with Opus 5
- How Dilum Sanjaya Built a Viral AI 3D Cell Explorer — the same creator's earlier project, and the model-stack pattern behind it
- What Are Agent Skills? A Complete Guide — packaging repeatable workflows like this one into reusable skills
- Claude Code Commands: Complete Reference Guide — the command surface for building this loop into your own setup
- Godot fishing game: ChatGPT art, Blender MCP, in-game camera as judge — the same taste-gate, stretched to three weeks of 3D: scored critics, USER vs AI tags, eval from the player camera
Facts and quotes in this post are drawn from Dilum Sanjaya's X thread posted August 16-17, 2026, current as of publication. Timing figures (5 hours for the village-builder, ~2 hours for the earlier railroad-tycoon prototype, 20-30 minutes per 5-6-task round) are as reported by Sanjaya and not independently re-measured by explainx.ai.