Bearzenker Field notes

Conquest: can an AI agent remember why it made a decision?

A two-hour build with Google Antigravity V2 and Gemini 3.1 Pro, run to test a specific claim: that chat history can double as institutional memory, and stop the next engineer from reverse-engineering someone else's code.

We build a lot of small experiments here, mostly to stress-test whatever coding agent is making noise that month. Conquest — a browser-based territory-conquest game, human vs three bot opponents, dice-roll combat — was one of them. The game itself is not the point. It's a stand-in for a much more common situation: a codebase somebody else wrote, that you now have to change.

Why we bothered

By mid-2026 Google had shipped three different coding agents, and each one made a different bet about where a developer should stand relative to the code:

• Command Line Agent — comparable to Claude Code: runs against your local codebase and does what you tell it, from the terminal you already live in.
• Jules — a cloud agent that clones a remote repo into a GCP sandbox and works there instead.
• Antigravity V1 — an IDE with agentic code generation built in, that may or may not be a VS Code fork with a Gemini plugin.

Antigravity V2 broke the pattern by removing the IDE entirely. The interaction model became "tell me what you want, and I'll make it happen" — no editor pane, no diff view by default, just a chat. Developer forums treated this as a downgrade: without an editor in the loop, the worry was that V2 would let people who don't understand programming ship code nobody could maintain — "slop code," in the vernacular.

The actual question

Whether a non-programmer can prompt their way to a demo isn't interesting — they always could, badly. The question worth testing is whether the output is supportable. And supportability isn't really a code-quality problem. It's a memory problem.

Every developer eventually inherits a codebase they didn't write. The engineer who built it moved teams, or left, and now someone else has to extend a system whose reasoning lives only in that first engineer's head. The code remains; the context doesn't. That's the actual, expensive failure mode — not bad syntax, but decisions with no paper trail.

So the test we set up was narrow: if an agent kept a running record of its own reasoning, and each new working session could read the previous one's record, would adding a feature start to look less like archaeology and more like a normal sprint?

How we ran it

1

Opening prompt

5

Sprints

~2 hrs

Total time

0

Lines hand-written

We gave Antigravity V2 a single opening prompt describing the objective — a Risk-style territory conquest game — and otherwise left it alone. It chose its own look and feel with no design direction from us. From there, five sprints added features and fixed bugs. No line of code was written by hand at any point.

The game itself still has rough edges. That's intentional — we were grading the process, not the polish, so we're not going back to fix bugs.

What "memory" looks like in practice

Antigravity V2's workflow maps loosely onto version control: the project folder is the repo, and every chat is effectively a branch. You open a new chat per sprint, describe the change, and the agent works inside that chat's context. Here's an actual instruction we gave it, verbatim, to add a post-combat movement phase:

After "End Attack Phase", the players should get an army movement phase. It will
work like the challenge phase, where the player will choose a territory they
occupy. Instead of highlighting opponent territories (red dashed circle), it
will highlight the player's connected territories (green dashed circle). A
destination will be chosen. A popup will show the number of armies and give
a +/- to move armies over, leaving at least one behind. There will be an
"End Movement Phase" button. (AI players will have the same movement
capability.)

Before writing anything, the agent thinks in the background, and stores its reasoning to the chat session:

I'm now deeply considering a new phase post-attack: a Fortify/Movement Phase.
Players would get to move units and set up defenses after attacks conclude,
mirroring attack phase mechanics. This allows for tactical repositioning,
counter-maneuvering, and strategic resource allocation after battles, adding
another layer of depth to the strategy.

<snip>

It presents an implementation plan, which it asks you to approve before touching any code:

I have created the implementation plan for the new Army Movement Phase
(Fortification Phase). It outlines:
- Visual highlights for connected owned territories (glowing green dashed
  circles).
- The design of a custom glassmorphic slide-control modal with
  increment/decrement buttons.
- Personalized AI movement algorithms (cautious defending, reckless
  doomstacking, and strategic border contesting).
- Full state machine transition logic.

Please review the implementation plan and let me know if you approve so I
can begin coding this feature.

That's the whole loop: prompt, reasoning, plan, approval, code. The idea is that the next sprint — the next chat — can look back at all of it. Every future change, in theory, has access to every past decision.

Generalizing: the real objection was never comprehension

The typical case against vibe coding is that someone with limited understanding is generating code from a prompt without knowing what it does. It's the same complaint that's been leveled for years at cargo-cult programming — pasting a Stack Overflow block into a project without fully understanding it. Getting caught doing that earns you a certain amount of side-eye from real console cowboys.

And yet very few teams have actually melted down from copy-paste development in the last decade. If you think of a Stack Overflow snippet as a Lego brick, the "cargo-cult" developer is just an assembler of standardized parts. A hobbyist doesn't need to know how to extrude an individual brick to build a genuinely original Lego model. Once you set aside "the creator didn't understand what they built" as the disqualifying problem, you're left with the objection that actually matters: can the next person support it?

That's the frame Conquest was built to test, and it's why we think the finding generalizes past this one agent: comprehension-at-creation-time was never the load-bearing requirement. A documented, auditable decision trail is. Whether that trail comes from a human's PR description, a design doc, or an agent's stored reasoning, the job it does is the same.

Where the model actually breaks

Antigravity V2 gets meaningfully further than "no record at all." But there's a gap, and it's a significant one. The project folder is the repo. Each chat is a branch. At the end of a sprint, that branch merges — and the code goes in cleanly. The institutional knowledge attached to it — the chat, the reasoning, the approved plan — does not merge with it. It stays behind.

Ideally, closing a chat would generate a README capturing the prompts, the reasoning, and the replies, committed alongside the code it produced. Instead, that information is written to a local database. If the machine an engineer was working on were to burst into flames, the app code would still be recoverable from the remote repo — but the reasoning behind every decision in it would be gone. The knowledge dies with the machine, even though the person who drove the keyboard it never left.

There is an export feature, but it only saves artifacts like the implementation plan — not the reasoning, and not the chat itself. Whether that's an oversight, a bet on where the product is headed, or a soft form of lock-in isn't something we can determine from the outside, so we won't speculate. What we can tell you is where the data actually lives: on the machine that ran the session, it's under ~/.gemini/antigravity. If you're relying on this workflow for anything real, that directory is worth backing up like you would a repo.

The gap isn't that the agent doesn't reason. It's that the reasoning isn't treated as an artifact worth shipping with the code.

Our half-joking, half-serious next step: ask Antigravity V2 to build its own tool that parses that local session database into a committed README. It's a small project, and the irony of asking the agent to solve its own institutional-memory problem was too good to pass up.

What this means if you're evaluating agentic tools

• Grade the artifact trail, not just the diff. The output of an agentic sprint should include a durable record of why, not just what — and that record should live where the code lives.
• "Understands what it built" is the wrong bar. Humans routinely maintain code they didn't write and don't fully understand, using PR history and docs as a substitute. Agents can use the same substitute, if the tooling actually commits it.
• Local-only memory is a single point of failure. If reasoning lives only in a session database on one machine, back it up deliberately — the same discipline you'd already apply to any other uncommitted state.
• Sprint-shaped prompting works better than ongoing chat. Small, scoped requests with a review-and-approve step in between produced a coherent five-sprint build in about two hours, which tracks with how any team would want work broken down regardless of who — or what — is doing it.

---