On 2 December 2025 AI House Amsterdam ran the second evening of its series on AI coding assistants. The first, with OpenAI, is in my autumn roundup; this one was with Google. According to the event page, Manasa Kandula, Practice Lead for Application Modernization at Google, gave a live demo of Gemini CLI and Antigravity across the software development life cycle, a case study on migrating legacy code, and general tips. The session is listed on Luma. The recording I have starts with the organiser’s welcome and covers most of the demo.
Everything below is my paraphrase of what the speakers said, not a verified manual. She was explicit about that: there is no formula, only trial and error.
The welcome
An organiser from the AI House team said the space exists to help make Amsterdam an AI hub: events with speakers from top tech companies, hackathons and research conferences, to close the gap with places like San Francisco and New York. The coding-assistants series had one session with OpenAI about a month earlier, this one with Google, and he said one with Anthropic was planned for January or February, date to be confirmed. The slide before the talk showed the agenda: a coding-assistants demo across the life cycle, a short case study on migrating and modernising legacy code, and general tips.
The agenda slide: coding-assistants demo, a migration case study, general tips.
The demo: an ASCII dungeon crawler with Rick in the background
The speaker described herself as a long-time software engineer who ignored AI until about a year and a half earlier. Her framing: these are lessons learned in the field, not best practices, because today’s best practice is yesterday’s news. To make the vibe coding concrete she built a simple ASCII dungeon crawler live with Gemini CLI, with a Rick and Morty themed character insulting the player. She had built the finished version the day before, so the room could play it at the end. Roughly 80 people raised a hand when asked who uses Gemini CLI.
The live Gemini CLI demo on the AI House screens.
Write the intent down: GEMINI.md
The biggest problem she named is that ideas stay in your head, and the agent never sees them. The answer is an agent file, GEMINI.md in Google’s tooling (other tools call it AGENTS.md), written for the AI as its main reader. Her recipe for what to put in:
- A persona: for example a senior backend engineer who is good at the language you use. She said never to pick “junior”.
- Project goals and the success metrics, with requirements that are unequivocal.
- Constraints: for instance limits on method parameters, or her own: standard library only, an entity-component-system pattern.
Then the warning: you can be too explicit. She talked about context bloat (attention is finite, so every token you add dilutes the others) and context rot (hours or days into one chat session the history fills the context and quality drops). To reduce the “needle in a haystack” problem she groups instructions by protocol, so that “when asked to plan”, “when asked to implement” and “when asked to explain” each sit in one contiguous block. Her file had a plan phase that breaks work into smaller steps, and an implement phase using test-driven development: write a failing test, then the code, and only then is the task done. She also showed that Gemini CLI loads context from several levels. Per the Gemini CLI documentation, it concatenates the global, project and subdirectory files and lets you inspect the result with a memory command.
Checkpoints, value checks and small tasks
“Use Checkpoints”, the slide for the next point.
- Checkpoint after every clean step. A hallucination stays in the conversation history and keeps contaminating the context, so each time the AI has done well, she saves the chat state, much like a git commit, and can return to a clean state if something fails. She also said she does not trust “YOLO mode”, where the tool does not ask for permission for anything.
- The value check. At the start of a project, ask for the smallest thing that proves the AI understood the goal: for a front-end, a web page that actually renders; for her game, a generated map (her file required cave-like maps from cellular automata, with at least 30 to 40 percent walkable and connected).
- Chew small. Do not ask for the whole game in one shot. When the agent veers off into its own plan, go back to the checkpoint and shrink the task. She compared it to pull requests: a gigantic one gets approved without looking.
- Clear history between unrelated tasks, unless the earlier decisions matter for the next step.
- No magic wand. Do not vibe code in production what you cannot review and understand yourself. Use it as a tutor and a force multiplier. For fun projects, anything goes.
- Match care to risk. Scaffolding, documentation and tests are safe to say yes to. Be more careful with refactoring, and take an extra pair of eyes for large migrations and anything security-related. Pause before irreversible changes or production data, and keep personal data out of the model. She also warned about connecting tools such as a GitHub MCP server without proper guard rails.
One of the cartoon slides, a joke about letting something in without scanning it.
The migration case study
For the legacy code part, she described migrating around ten thousand similar database queries, as she put it, with a workflow that was mostly deterministic. Her lessons:
- Files too large for the context. Some files had thousands of lines, and even with a million-token window the needle-in-a-haystack problem hit. Their rule of thumb was to cut out the one relevant method when a file was over a hundred lines or so, and send only that.
- Do not make everything agentic. Context fetching and trimming were ordinary code in a conservative, reliable workflow; agents were embedded only for the steps that needed judgement, such as deciding how to migrate a query and writing the code.
- Prompt-engineer the repeatable task. When you run it thousands of times, use examples and iterate on the system prompt until behaviour is as predictable as it can be.
- Look at the whole process. Making code generation fast does not help much if a different team’s code review takes weeks. Going from three weeks to two is less interesting than going from two weeks to one hour.
My take: the migration lessons are the ones I recognise from platform work. A deterministic pipeline with an agent in the steps that need judgement is easier to test, cost and operate than an agent loop with tools, and it echoes the ideas in my AI coding agents for platform engineering post.
Antigravity: from human in the loop to a junior developer
The last part was Google Antigravity, described on its site as an agentic development platform. She said it was about two weeks old, in public preview, only usable with a personal Google account, and not for proprietary code. Her point was moving past being the human who checks every step, towards delegating to something like a junior developer: you give it a task, it breaks it into subtasks, writes a plan, and you review the plan before it works. She also said it does not run a central orchestrator with independent agents in the way she was describing for other tools, but that the newer tools let multiple agents work in parallel.
Her example was a mobile app she builds as a yearly side project. She asked it to review the login screen and improve it. It opened the app, took a screenshot, drafted an implementation plan with steps (review, plan, get approval, find the source, apply, verify with a screenshot). She edited the plan, for instance to avoid using a real logo because of copyright and to keep the fonts, and it produced the new version in about three minutes, with a walkthrough of what changed.
My take: the interesting part is plan review as the new unit of work. It is the same discipline as a design review, and the same advice on small tasks and checkpoints still applies.
Finishing
The recording ends with her closing remarks on the migration and the Antigravity demo; the Q&A slide followed. I walked away with one thing to change in my own agent files: group instructions by phase instead of piling them up.
