DEV Community: Charles Berube

Mini-Loot: Saved by GPT 5.5

Charles Berube — Wed, 03 Jun 2026 23:30:00 +0000

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:

I'm not sure why we're all smiles here, and I don't know how "B" is related to the "Cave Skitter" monster, but it's clear these are faces at least and I really appreciate the initiative to add a little visual interest.

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.

Mini-Loot: When it all went wrong

Charles Berube — Wed, 27 May 2026 23:30:00 +0000

Well, the intent was to share a third vibe-coded browser-based game here called Mini-Loot. It was going to be a little auto-battler with 24 rounds of combat in which you'd outfit and upgrade a single character.

I decided to give Google's Antigravity a try for this one, with Gemini 3.1 Pro as the model. It did not go well.

Codex and Cursor were both quite intuitive and straightforward to jump into and start working in, but Antigravity is much more ... confused about what it is trying to be. The meaningful advantage of Antigravity over stock VS Code is the Agent Manager but it doesn't start you there, so it's not immediately clear how to get to "the good parts". It isn't difficult to find your way to the agents, but this was an ominous start to a downhill journey.

The default model setting was Gemini 3.1 Pro (High), with planning enabled, so that's what I ran with. It generated a reasonable, if a little ambitious, implementation plan with some open questions – this was actually the best part of the whole experience – the presentation of the plan is nice and tidy and using a comment and review process to respond to the questions and approve the plan was a nice workflow.

Then Gemini started working. It was weirdly quiet, without the usual stream of consciousness thinking that I've gotten used to from LLMs. It stumbled on executing a terminal command for security reasons and then... it seemed to just sort of stop. It didn't appear to have read or understood the error from the terminal, it didn't try anything else, it didn't provide a message of any sort.

I had to stop it, then ask if it could resume. It did and meandered for ten minutes or so, finally getting npx to run, then going quiet again right after scaffolding the project. Stop it again, ask it to resume, then a horrendous, plodding, grinding chunk of time as it slowly generated the project.

Then it starts testing. It launches a separate instance of Chrome, navigates to the running project and finds nothing – a completely blank page. It troubleshoots, successfully, somehow, but I can't find the change it ultimately made at this point in the terrible mess of nested scrolling panels in Antigravity's log.

It's not me, right? That's too many scrolling panels inside other scrolling panels, right?

And we're back to testing. It clicks around a little, completes one battle, then proudly declares success.

But the result is actually not quite right. The original prompt asked for and the plan specified a shop and upgrade screen after every two battles, but Gemini has implemented a shop after the first battle instead. Also the shop doesn't work (in spite of the fact that the shop before the first battle works just fine, and seems to be the same component). The requested upgrade screen does appear after every second battle, but none of the options do anything at all. Under the hood this is because the structure of the data for the upgrades doesn't match what the rest of the code expects, even though a well-defined type exists.

Instead of randomly generated characters at the start of the game they are entirely static. The mage's name is just ... Mage; there's also Warrior the warrior and Rogue the rogue. The HP upgrade it generated is marked as an armor upgrade in the code; but it doesn't matter, because it doesn't do anything anyway.

The structure of the project is ... fine, for the most part. But some of the comments are strange and seem like they are plucked right from the stream of thoughts the LLM was having:

// Next phase is Shop, wait, after shop is battle. We can simplify: after battle -> upgrade -> shop. Or after battle -> if % 2 === 0 then upgrade else straight to next battle? Wait, prompt says: "After every second battle we should present the player with a set of three upgrade choices... During this process they can also spend gold". So every 2nd battle -> Upgrade screen (which includes shop). Every other battle -> straight to next battle? Actually, wait, let's just make it Phase: 'Shop' every battle, but only 'Upgrade' if % 2 === 0?

// Let's implement: WIN_BATTLE -> if % 2 === 0 go to Upgrade, else go to Shop (or next battle).

// Let's just go to Shop every time so they can heal, and show Upgrades only if % 2 === 0 on the Shop screen! This is cleaner. Wait, the phase can just be 'Shop' and the Shop screen handles showing upgrades if applicable.

// Or we can have an 'Upgrade' phase that then goes to 'Shop' phase. Let's do 'Upgrade' phase if % 2 === 0, else 'Shop'.

// maxMana wait, player.maxMana

At this point I've largely written off Gemini and am not too keen on Antigravity either, but I wanted to give it another shot with a different model. So I switch over to Claude Sonnet 4.6 (Thinking) – my go-to model for "real work".

We get off to a weird start. It reaches across workspaces to look at the previous conversation with Gemini and across directories to examine the code from that session; not what I want. So stop it, update the prompt to explicitly ask it not to, and then off we go again.

It comes up with another nice implementation plan and asks a couple of good questions. I answer those and approve the plan and we get right back to struggling. Claude keeps exceeding the maximum number of output tokens while trying to write one of the files. It sort of tries to hype itself up about being more and more brief, but the error never goes away. I stop it again, partly because I feel bad for it at this point.

Both Gemini and Claude opted for a Vite + React + TypeScript setup, which isn't unreasonable, but the previous two projects kept things much more light-weight: plain old JavaScript with no frameworks. Maybe the issue is the planning setting – it's aiming too high.
Okay. Claude Sonnet 4.6 (Thinking) with planning mode off.

It keeps the Vite + React + TypeScript, but gets off to a much more promising start. It makes better visual style choices, has Claude's usual obsession with emojis next to everything (for whimsy, I assume), generates random character names instead of Mage, Warrior, and Rogue. But the first battle immediately crashes when testing. And that's right when I run out of tokens for the Claude models.

I decide to give this one more try with Gemini, but no planning.

Immediate disaster. It generates a single "types.tsx" file and then hangs, in a silent loop of hopelessness.

In the end, I'm not sure where the problem ultimately lies here; I suppose it is a combination of things. Gemini was startlingly disappointing, but Claude also struggled (particularly in planning mode), which makes me think Antigravity itself is at least part of the issue. It's not a very pleasant IDE experience and it's not a very convenient agent management tool either, so it winds up being a miss on all fronts for me.

If this had been my first experience coding with AI, it would almost certainly have been my last for a long time.

Ultimately nothing really complete and functional came from this experiment, so I'm not going to bother with a GitHub repo this time around.

The logo for this post is once again from GPT Image 2 on Leonardo.ai. I started off with a request for a "normal" logo and then asked for a variation that made it clear the project was a failure.

The X'd out eyes were a nice touch; no notes.

Dark Fishing

Charles Berube — Wed, 20 May 2026 23:30:00 +0000

Play Dark Fishing here.

A second experiment in "vibe coding" tools.

In Dark Fishing you explore patches of the ocean, attempt to catch strange eldritch fish, and sell your catch at port to buy upgrades for your boat.

This project was built with Cursor in Auto mode (since model selection is a paid feature for Cursor). Like Emberroad, Dark Fishing took a little over an hour to build; it did consume the entire month's worth of free credits for Cursor though. (This was actually pretty disappointing, since there were some obvious changes to try next right when the credits ran out.)

The logo is once again from GPT Image 2 in Leonardo.ai; this time around I requested a quick edit to get a "grim oil painting" style, which I think turned out alright for just a two prompts total.

The original image just felt a little too... run of the mill:

I really enjoyed the AI's attempts at eerie, eldritch phrases and names in this project:

"A black tide folded around the mast, and the planks gave way like wet paper."

– amazing.

"Nameless Worm of Drowned Lanterns"

– incredible name for an evil fish.

And why have an "OK" button when you can have "It is done" or "The sea has spoken"?

Finally, if you're interested in the technical results, the code generated for Dark Fishing is available on GitHub.

Emberroad

Charles Berube — Wed, 13 May 2026 23:15:00 +0000

Play Emberroad

Emberroad is a simple game that has you managing a small party of travelers as they set out from the capital of an empire towards the untamed wilds where they hope to found a new village.

It is an experiment in using AI tools to generate complete projects from scratch and was built in about an hour using Codex and GPT 5.5. The project consumed roughly one week's worth of free credits.

The logo on this page was created with the GPT Image 2 model in Leonardo.ai.

The resulting code is open source and available on GitHub.

Originally posted at https://blog.charlesberube.com/emberroad/