Mini-Loot: When it all went wrong
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.
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.

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.