Google Antigravity 2.0: The Settings Screen Is the Story
Google ships two different things under one name, and picking the wrong one quietly puts you in the wrong workflow for weeks.
| Antigravity 2.0 | Antigravity IDE | |
|---|---|---|
| What it is | a standalone agent platform (desktop app or CLI) | a code editor, close to VS Code |
| How you use it | hand it a whole task; it decomposes and dispatches sub-agents | open files, read and edit code yourself, with AI assist |
| Mental model | headless — work happens below the surface | hands-on — you are in the buffer |
They are complementary, not competing: from the 2.0 app there is an Open IDE button, and running both side by side is the comfortable setup. But if you came looking for "Google's answer to agentic coding" and landed in the editor, you would conclude the whole thing is a Cursor clone and move on.
About this write-up
Written from the video on the channel. The walkthrough and the build are what happened on screen. Where a figure comes from a vendor page or a third-party index rather than the run, it is labelled — and a few product labels in the auto-captions were too garbled to reproduce, so they are described by behaviour instead of guessed at.
This is the written companion to the video, where the settings screens, the three-agent build and the scheduled job are all walked through on screen.
Prefer to watch it on YouTube?
Watch on YouTube — or subscribe to the channel for the next one.
The part everyone skips
Most tool reviews spend their time on the build demo. That is the part that photographs well.
But this is a tool with a scheduler, a mode that runs continuously without stopping to ask you anything, and sub-agents that execute shell commands. The interesting question is not whether it can build a flashcard app. It is what it is allowed to touch at 8am on Tuesday when the scheduled run fires and you are not at the desk.
Antigravity's answer is unusually granular, and it is worth knowing the axes exist:
- File permissions — read and write, defined per path.
- Network permissions — allow or deny, per site.
- Terminal permissions — allow or deny, per command.
- Commands outside the sandbox — agents run sandboxed; whether they may step outside is its own explicit setting.
- MCP tools — which external tools are exposed at all.
Every one of those has a default. The default is the setting you are choosing, whether or not you open the screen.
Two settings that cost money if you miss them
Model quota is shared across the Claude models. Using Sonnet and Opus does not draw from two separate buckets — spend on one and you have spent it on both. Quota refreshes on a multi-hour cycle.
"Enable AI credits" is the overspend switch. With it off, you stop when the included quota runs out. With it on, you keep going and it bills. The video leaves it off deliberately, which is the right default for anyone who has not yet watched their own burn rate for a month.
There is also a prevent-sleep toggle, which sounds trivial until a build runs half an hour and your laptop suspends in the middle of it.
The build, and the one line in the prompt that matters
The demo builds Aura English, a flashcard app, with three agents working in parallel: backend (Spring, clean architecture), frontend (React and TypeScript with a component library), and QA (automated tests).
The line worth stealing from the prompt is the collaboration protocol: before generating code, the agents peer-review against a shared API contract, so the frontend is not inventing endpoints the backend never built. Without that, parallel agents produce two halves that do not meet — which is the characteristic failure of multi-agent codegen, and the reason most people give up on it.
There is also a choice between running in the working directory and running on a new git worktree. The worktree option puts each agent on its own branch so parallel work cannot collide. If you are running more than two agents, that is the setting that keeps the result mergeable.
What actually happened
| Plan generated | ~22 seconds |
| Frontend agent | ~3 minutes |
| Backend agent | ~2 minutes |
| Then | QA agent starts automatically |
The QA agent finding a bug hands it back to whichever agent owns that layer — frontend bugs to the frontend agent, backend bugs to the backend agent — and the loop repeats until the tests pass. Watching that hand-off is the genuinely novel part; it is a team protocol, not a pipeline.
Where it fell short
It took three rounds, and the video says so.
The app shipped with no way to create a card. You had to insert rows into the database by hand. The creator is straightforward that this one is on him — the prompt never asked for a create-card feature, so nothing built one.
That is the most useful lesson in the video and it is easy to skim past: the agent built exactly the app that was specified, including the hole in the specification. A faster agent gets you to the consequences of a vague brief faster.
Then a real bug. After flipping a card, the rating buttons could not be clicked. Fixing it in the frontend caused a QA test to fail, which pulled the backend agent back in to update its side, then a re-run, then green.
And an environment error — the H2 database console refused a connection until the error was pasted back in and fixed.
None of that makes the tool bad. It makes the demo honest: the first prompt is never right, and the value is in how cheap the second and third rounds are.
The scheduler is the feature I would actually use
A prompt like scan the backend every morning at 8am for bugs, security issues and performance problems, and write me a markdown report registers as a recurring job. You arrive, the report is waiting.
That is genuinely useful — and it is also precisely why the permissions section above is not optional reading. A scheduled agent with shell access, network access and no sandbox boundary is a different risk profile from a chat window you are watching. Sessions four and five of the SDLC notes make the same argument from the governance side: automate the execution, keep the accountability.
On the speed claim
The video's framing for why Google moved this way is model economics — a Flash-tier model reported at roughly three times the throughput of the heavier competitors at well under a quarter of the cost, scoring just behind them on an intelligence index.
Those numbers come from a third-party index and Google's own pages, not from this run. Treat them the way you would treat any vendor-adjacent benchmark: directionally interesting, independently unverified. What the run itself showed is a 22-second plan, which is consistent with the claim without proving it.
What I take from this
Read the permissions screen before the feature list. For a tool that runs unattended, the permission model is the product surface that matters.
Write the collaboration protocol into the prompt. Parallel agents that do not agree on a contract produce halves that do not fit.
Budget for round three. The first prompt has holes; the agent will build them faithfully.
Related
- Session 5 — AI-Driven Workflow — where an agent's autonomy stops, argued from the governance side.
- Claude Fable 5 Is Back: A Demo That Can Actually Be Wrong — another agent build, with a verification step that made its output checkable.