I sat down one weekend to clear a backlog of small fixes, and ended up writing the same change twice in Antigravity 2.0. The reason was almost embarrassingly simple: I had a file half-edited in the IDE, then handed it to the now-separate agent app and asked it to "clean this up." The agent was looking at the old contents on disk; I was looking at my unsaved buffer in the IDE. We were each reading a different map.
The 2.0 modular layout splits the code-writing IDE from the chat-style agent interface into two distinct apps. Having a screen tuned for writing and a separate one for delegating is genuinely pleasant. But that split brings a trap you never had to think about before: both apps are looking at the same project, yet not always at the same moment in time.
The two apps see "the same file" at different instants
Back when it was a single app, your editing buffer and whatever the agent touched lived in the same process. Even with unsaved changes, an instruction to the AI ran against the state right in front of you.
Once the IDE and the agent become separate processes in 2.0, the thing that connects them is essentially the file on disk. So what the agent reads is your most recent save. Any edit you have not saved in the IDE simply does not exist as far as the agent is concerned.
That is exactly where I got caught. I rewrote half a function in the IDE, switched to the agent app without saving, and asked it to "add error handling to this function." The agent proposed a diff that added error handling to the saved, older version — and applying it collided with the unsaved changes I had in the IDE. I was left deciding by hand which side was correct, which meant doing the work twice.
Pin the source of truth to "disk"
The fix is almost anticlimactically plain. Treat the file on disk as the single source of truth, and always save when you hand work from one app to the other. That alone made the confusion above mostly disappear.
Here are the three rules I actually keep:
- Save the IDE side before handing anything to the agent. Not just the file you are editing, but any related files you touched. Making "save all" the ritual at every handoff means your hands do it without thinking.
- Do not touch the same file in the IDE while the agent is rewriting it. Editing the same file from both sides in parallel creates a fresh inconsistency on every save. Once you hand it off, move to a different file in the IDE until it comes back.
- After you accept the agent's diff, reload the file from disk in the IDE. Most editors detect external changes and prompt a reload, but with unsaved changes they sometimes swallow it silently. Closing and reopening the file after accepting is about the right level of caution.
This "make saving the boundary" idea pays off unusually well when you run several sites or apps alone. As an indie developer, I work across the repositories of my four Dolice Labs blogs, switching between them constantly, so the moment it becomes unclear which app holds the canonical copy of a file, the damage spreads straight across multiple projects. Drawing a "this much is committed" line with a save every time I cross from one app to another keeps the state in my head aligned with the state on disk, leaving no gap for confusion to slip into.
Designing for fewer round trips between "writing" and "delegating"
Save discipline prevents collisions, but it is easier still to not bounce between the apps in tiny increments. Precisely because they are now separate, it pays to deliberately cut down the number of round trips.
In my own work, I hand things off in larger units. Instead of "fix this one line," I give the agent "rework this set of files for this feature along these lines," and while it works I write a different, independent file by hand in the IDE. As long as the writing and the delegating point at different files, save collisions never happen. The separated layout actually pairs well with this habit of spatially dividing what the human owns from what the agent owns.
Conversely, delicate changes I want to check line by line, I keep inside the IDE's inline editing rather than routing them through the agent app at all. The apps being split does not mean everything has to flow to the chat side. Sorting up front into "this is something I do by hand in the IDE" and "this is something I hand to the agent in a batch" is what actually reduces the round trips.
For the bigger picture of which surface to assign which work, I laid it out in Antigravity 2.0, CLI, IDE, SDK — How to Choose Among the Four Surfaces. And when you want to sharpen the context you hand the agent, Giving Antigravity the Right Context — A Practical Guide to @ References for Better AI Output raises the resolution of how you pass things over.
Your next step
For your current task, try consciously doing "save all right before switching apps" just once. That single save-all prevents most of the double-writing. The separated layout is comfortable once you settle in, but that comfort rests on one small discipline: letting disk be the truth. I hope this helps anyone stuck at the same spot.