Mini-Loot: Saved by GPT 5.5
I tasked GPT 5.5 in Codex with building Mini-Loot. The first iteration was up and running in just under five minutes.
Don't worry, I wouldn't let Mini-Loot languish in the mire of Antigravity's failures.
Using the exact same prompt as I had given to the various models I tried in Antigravity, I tasked GPT 5.5 in Codex with building Mini-Loot. The first iteration was up and running in just under five minutes; and it was fairly complete, although GPT 5.5 also decided to have a shop appear after every battle instead of every other – apparently something about how I phrased that in the prompt was just terribly unclear.
Mini-Loot Prompt
We're going to build a browser-based, turn-based auto-battler game named "Mini-Loot" today. The goal of the game will be to complete 24 battles of increasing difficulty.
To keep things simple, the battles will just be one character managed by the player against a single opponent.
When a new game starts the player should be able to choose from three randomly generated characters with different classic fantasy classes (mage, warrior, etc). They should also have a chance to spend a small amount of gold on starting items to supplement their character -- healing potions, mana potions, maybe some damage dealing items.
After this phase, we move on to the first battle against a low-level, randomly generated monster. The battle runs automatically, with the player's character and monster taking turns attacking each other, using items, and triggering abilities. If the player's character dies, the game is over and we should display a game-over screen. If the monster is defeated the player earns a bit of gold and we move on to the next battle.
After every second battle we should present the player with a set of three upgrade choices. These upgrades do not cost anything, and might be improved weapons, better armor, new abilities, and so on; upgrades to existing abilities would also make sense here. During this upgrade process the player can also spend gold on items like those that were available at the beginning of the game, in case they want to restock.
The final battle should be against a particularly difficult and impressive creature.
If the player completes all 24 battles we should display a victory screen, maybe with a list of each battle they fought.
It even put together a ... logo? splash screen? capsule art? ... something anyway that sits on the side of the title screen:
And it intuited that there should probably be some representation of your character and the monster they're fighting on the battle screen. I'm not sure it got the tone exactly right, but this isn't too bad for five minutes and a single prompt:
So: why did GPT in Codex manage to pull this together so quickly and easily while multiple models struggled so much in Antigravity?
I suspect the basic, straightforward answer is just down to differences in system prompts and tooling that guide the models in radically different directions between the two IDEs. But there is a particular detail about the difference approaches that I think is worth noting, both because it might inform approaches to AI-driven projects and because it's a good reminder for entirely human-written ones too:
The approach taken in Codex was simple. It created 3 files: an HTML file to host the game, a single plain-old JavaScript file to run it, and a classic CSS file to provide styling. It used no libraries, added no compilation steps, and imposed no specialized structure up front. Technically it didn't even need an HTTP server, but when it opted to use one it just ran Python's http.server.
In contrast Antigravity gathered a bunch of tools and constructed a lot of structure before there was any sort of working project: Vite for bundling and serving content, TypeScript and the TypeScript compiler, React for managing the DOM, eslint for, well, linting. Both Gemini and Claude in Antigravity created about a dozen source files and, with the overhead of the tools they chose, have around 5,700 files in the development workspace (granted, a lot of that lives in node_modules but it's still in there).
Don't get me wrong, those are all good tools and I don't even think they were poor choices for this project in the long run, but they added an awful lot of up-front complexity. It's pretty clear that Antigravity was planning for a capital-P Project that was going to go to capital-P Production, and it was just never able to pull together all the threads it had collected into something functional. It had a whole lot of parts but didn't seem to know how to build what I wanted out of them.
Codex understood the assignment much better: make a simple, working version of this thing I described. And it left the project in a perfectly good state for iteration: that one JavaScript file it wrote is long, but it's quite well organized and would be straightforward to pull apart as it continued to grow (there is a state object that would need to be passed around, but it did have the good sense to organize the current state of the game into and object so there's not a big barrier to overcome there).
I think the useful reminder that falls out of this for non-AI ("organic", I guess) projects is that you can wind up painting yourself into a sort of "cognitive overload corner" by reaching for too many tools too quickly.
"Cognitive overload corner" is a strange phrase; I'll try to explain a bit.
It takes time, and thought, and energy to pick those tools; and then to install them and set them up. And it takes more time, and more thought, and more energy to invent your directory structure and conjure up well-named files for your components and hooks and style rules.
The insidious part of this work is that it is work – it makes you exhausted – and it feels productive – you really have done something – but it isn't the useful something. Now you have all these pieces that exist but that don't do anything together; they don't produce some measurable, real, interactive thing yet so nothing anchors them to one another and nothing helps clarify how they should be organized going forward. Instead of creating something and fitting the tools to it you land in a dreary place where you're fitting the something to the tools.
Please don't misunderstand me: this is not a plea for not using tools. Just a reminder (as much to myself as anyone else) that it is perfectly fine, and maybe better, to add tools and frameworks slowly and as they solve real problems.
Well, that feels like it somehow got very philosophical and soap-boxy.
But in any case, here's the GitHub repo for GPT 5.5's version of Mini-Loot.
As usual, the logo at the top of this post is from GPT Image 2 on Leonardo.ai.
