The UX of Not Doing the Work

Google launched the original Antigravity with two surfaces. There was an Editor that looked and behaved like an AI-powered IDE, and there was an Agent Manager for spawning agents, watching them work across projects and returning when they needed attention. Google already understood that these were different experiences. It even said that it did not want to squeeze the asynchronous Manager and synchronous Editor into one window.

Then, in May 2026, Google separated them more decisively. Antigravity 2.0 became a standalone desktop application with no IDE at all. The existing editor became Antigravity IDE. Google said the Agent Manager would eventually be removed from the IDE, leaving it as a purely agent-powered editor, and recommended using the new Antigravity beside whichever IDE a developer prefers.

At first this looks like ordinary product cleanup. One application had accumulated too many responsibilities, so Google split it into two. Yet the split is interesting from a UX perspective because the two products are not simply optimized for different features. They are built around different relationships between the user and the work.

In an editor, I am close to the material. I can see the file, place the cursor, change a line, run the code and notice what happened. Even when an AI agent performs several steps for me, the environment still suggests direct involvement. The code is visible. The terminal is nearby. The diff appears in relation to the files I already know. I remain physically, or at least visually, inside the object being changed.

Antigravity 2.0 asks me to behave differently. I describe an outcome, give an agent access to a project, let it work asynchronously and return later to inspect what it produced. The primary objects are no longer files and lines. They are projects, tasks, conversations, artifacts, permissions, progress states and requests for review.

This is not merely the same interaction moved into a larger window. Direct manipulation and delegation produce different mental models.

Direct manipulation has shaped much of graphical interface design. The user sees an object, acts on it and receives immediate feedback. Actions can usually be broken into small steps. The relationship between intention and result remains fairly legible. If I drag a file into a folder, I can see where it went. If I change a value in a design tool, the object changes in front of me. If I make a bad edit, I expect some form of undo.

Delegation is less tidy. I state what I want, but the path from request to result may include hundreds of actions I never observe. The agent may inspect files, choose an implementation, search documentation, install dependencies, run tests and revise its own work. The output may arrive several minutes later, after I have forgotten the exact assumptions I made when starting the task.

The interface therefore has to represent something more abstract than action. It has to represent a commitment.

What did I ask the agent to do? What did it understand? Which systems can it touch? What has it already changed? What evidence does it have that the work is correct? Which decisions did it make without me? Where is it uncertain? What would happen if I stopped it now? These are not secondary details around the main interaction. They are increasingly the interaction itself.

This is why adding a chat panel to an existing product was never going to be enough. Chat is good at receiving ambiguous intentions, but it is weak at showing the expanding consequences of those intentions. A sentence can begin as a request for advice and quietly become permission to edit a repository, update a database or deploy something. The visual surface needs to make the change in authority visible.

The UX problem is not only whether the agent understands the user. It is whether the user understands the distance that has opened between the request and the work.

Google's split makes that distance visible through product architecture. Antigravity IDE is for moments when the work itself remains the centre of attention. Antigravity 2.0 is for moments when the user is supervising work that may be happening elsewhere and at another time. One is organized around the material. The other is organized around responsibility for the material.

OpenAI reached a similar conclusion with the Codex app. OpenAI describes it as a command centre for managing several agents in parallel and explicitly argues that IDEs and terminal tools were not designed for supervising long-running agent work at scale. The app lets someone review an agent's changes and then open them in an editor when direct intervention is necessary.

GitHub makes the distinction inside Copilot. Its agent mode and coding agent share much of the same intelligence but occupy different relationships with time. Agent mode works synchronously inside the IDE. The coding agent works asynchronously in a separate environment and returns a pull request for review. GitHub has turned the difference into an explicit choice between working with the system and sending work away.

These products suggest that agentic UX is developing two families of interfaces. One family keeps the user close, with rapid feedback, visible context and frequent opportunities to intervene. The other lets the system move further away, gaining autonomy while requiring new forms of progress reporting, evidence and control.

The temptation is to treat the second family as the more advanced one. If the agent is capable enough, why would anyone want to watch it edit files? Google even calls Antigravity 2.0 the future. Yet distance is not automatically progress.

Watching the work is often how I understand the system I am changing. A developer notices an awkward dependency while implementing a feature. A designer discovers the actual problem while moving elements around. A writer changes the argument after hearing the rhythm of a paragraph. The process produces knowledge that was not available when the task was first described.

When the process disappears, some of that learning disappears with it. The result may still be correct, but I can become less capable of judging why it is correct or what it has disturbed nearby. The interface saves effort while potentially weakening the mental model required to review the saved effort.

This is where agentic UX becomes more difficult than automation. The goal cannot simply be to remove the user from the loop. It has to decide when distance is useful and when proximity is necessary.

A small, familiar change may be safe to delegate. A vague architectural decision may benefit from staying visible. A task can begin asynchronously, become suspicious halfway through, move into the editor for direct inspection and then return to the agent manager for testing and cleanup. The user does not permanently belong in one mode. The relationship changes as uncertainty changes.

That makes the handoff between Antigravity and Antigravity IDE more important than either application on its own. Splitting the products solves one UX problem by giving each mental model a cleaner home. It also creates another problem: context can now fracture across windows.

When I move from the manager to the editor, does the editor show what the agent believed it was doing? Can I see the plan beside the implementation? Are the important decisions attached to the relevant files, or buried in a conversation elsewhere? If I correct something manually, does the manager understand that the task has changed? Can I move back without reconstructing the situation from memory?

Google describes this as dual-wielding, which sounds more confident than the experience may feel. Two specialized tools are only better than one overloaded tool when the transition between them preserves intent, state and understanding. Otherwise the user becomes the integration layer.

This may be the larger UX lesson in the Antigravity split. Agentic products are not primarily introducing a new kind of input. They are introducing a new distribution of agency. The system performs more actions, while the user remains responsible for outcomes they may not have directly produced or even fully observed.

Traditional interfaces often help people do the work. Agent interfaces also have to help people remain meaningfully responsible while not doing it.

That requires more than progress bars and friendly status messages. It requires evidence, boundaries, history, reversibility, clear moments of authorization and ways to move closer when abstraction stops being useful. It also requires accepting that sometimes the best interface for an agent is still a file open in an editor, with the cursor placed exactly where the problem became real.

The separation of Antigravity and Antigravity IDE is therefore not evidence that the IDE has become obsolete. It is evidence that one interface can no longer comfortably pretend that doing the work and delegating the work are the same activity.

I suspect many products will make a similar split, whether through separate applications, modes or workspaces. The harder part will be deciding how much distance each task can tolerate before convenience turns into confusion. For now, I would probably keep both windows open.

Source note

This essay draws on Google's original introduction of Antigravity and its May 2026 launch materials for Antigravity 2.0, along with official descriptions of the OpenAI Codex app and GitHub Copilot's synchronous agent mode and asynchronous coding agent.

Connected reading

• The Coding Assistant Is Becoming the Development System
• The Product Needs a Harness
• The Browser Is Becoming the Agent's Body
• The Interface Is Now Part of the Answer

AI authorship note

This essay grew from Kris Haamer asking why Google separated Antigravity from Antigravity IDE, then pushing the discussion toward the UX difference between direct manipulation and delegation. AI supported source research, drafting, editing and implementation. Kris selected the argument, shaped the framing and approved the final essay for publication.