Antigravity /goal: Autonomous Coding Agents and the End of Babysitting AI

Picture a quarter past one in the morning. You're in the middle of a refactor, replacing a legacy state-management layer or wiring a new module into the codebase. Next to your editor, an AI coding assistant waits. It's fast, capable, and can see every file in the project.

And yet you're stuck in a loop you know too well.

You send a prompt and the agent produces a file. You notice a missing import and ask for it. The import gets fixed, but a constructor now breaks. You explain that the class needs new parameters. The parameters are updated, and then the compiler complains about a different file. You paste the error back and ask for a fix. That works, but a unit test starts failing, so you ask for the tests to be run and repaired.

An hour disappears. The code works at last, but you're drained, and you never wrote a line of it. You spent the whole time managing an assistant.

The babysitter problem

That interaction style has a steep cognitive price. Each time the AI pauses to ask permission, your flow breaks. You switch from designing software to fixing the assistant's intermediate mistakes. Agents can already read and write code, run terminal commands and search the web. Yet the way people work with them is still synchronous and limited by the human. You steer the AI one turn at a time, like a driving instructor gripping the second brake pedal.

Now imagine describing the destination once, taking your hands off the wheel, and letting the agent handle the whole trip, including detours, flat tires and traffic jams.

That idea has a name, fully autonomous goal execution, and it shows up as the /goal command in Google's new Antigravity CLI.

How working with AI agents evolved

To see why this matters, look at how quickly the relationship between developers and AI tools has changed over just a couple of years. It falls into four phases.

Phase 1: chat completion (2023)

Developers copied snippets into a Gemini web interface, asked a question, got a block of static text, and pasted it back into the IDE by hand. The human did around 90% of the mechanical work. The AI behaved like a very polished documentation search.

Phase 2: inline IDE agents (2024)

Tools such as Gemini Code Assist and GitHub Copilot moved the AI into the editor. The assistant saw the open file and the workspace, so it could write lines or whole functions in place. Human effort fell to about half, but the rhythm stayed turn-based: you write a line, the AI completes it, you check, and you repeat.

Phase 3: agentic loops (early 2025)

Agents left the editor for the terminal. Gemini CLI and Claude Code could run commands, edit several files at once, search directories and call outside tools. They were built around a cautious, synchronous model, though. Before each command, the agent stopped to ask something like "I want to run flutter test. Approve? [y/N]". That's safe, but it means you can never leave. You're acting as the CPU, and the AI waits for your cycles to move forward.

Phase 4: autonomous goal execution (now)

This is where /goal in Antigravity fits. The human goes from approving individual commands to acting as an architect who sets acceptance criteria. You decide what has to be true, and the agent owns how, when and, above all, verification. Your effort shrinks to stating the goal and reviewing one final diff.

What /goal actually is

At first glance it looks like a command prefix. In a terminal you type antigravity /goal and then your prompt. Underneath, it switches the engine into a different execution mode.

The mental shift: asynchronous delegation

Ordinary prompting is a conversational request. You ask, the model answers, and the turn is over.

/goal works as a contract.

Invoking it doesn't open a chat. It hands over an objective. You describe the end state and the boundaries. The agent accepts, then enters a private, self-correcting loop and doesn't come back until the contract is met or every path has been exhausted. Compare micromanaging an intern with letting a senior engineer own a ticket.

Anatomy of the autonomous loop

After it starts, the engine cycles through four behaviors:

1. Iterative planning. It doesn't begin by typing code at random. First it reads the workspace, maps dependencies and writes an internal plan, split into phases:

• research and discovery, which scans the file structure and reads configs
• core refactoring, which updates business logic and state providers
• consumer adaptation, which fixes dependent widgets and imports
• verification, which runs compilers, analyzers and test suites

1. Self-verification. The agent doesn't assume its own code is right. It actively hunts for failures by using compilers, linters and test runners as tools. When a check fails, the loop continues and the error output goes back into the planner to shape the next steps.
2. Resilience. A normal prompt that hits a compile error stops and asks what to do. In goal mode, a compile error is just more information. The agent reads the stack trace, studies the file it changed, works out the logic mistake and edits again. It can repeat this write, compile and test cycle dozens of times.
3. Context persistence. In a chat window, fixing five issues in a row bloats the history, and the model starts losing focus. Goal mode keeps an internal state machine for the task. It records what was tried, what failed, why, and what's left, which keeps the context small and focused.

A Flutter example, before and after

Take a job every Flutter developer has faced: moving state management onto modern Dart features.

The objective reads: refactor the AuthBloc implementation, convert the legacy AuthState and AuthEvent definitions to Dart 3.0 sealed class syntax, update the consuming widgets (LoginScreen and ProfileScreen) to use switch expressions over the sealed states so the compiler checks exhaustiveness, fix every compile error the change causes, and update the unit and bloc tests until the suite is entirely green.

Here's how the two approaches compare.

The old way: interactive prompting

You begin by asking the agent to convert the states to sealed classes:

• You: "Refactor AuthState using sealed classes."
• The agent produces a sealed class but forgets the rules for subtypes, or falls back to the old pre-3.0 style:

abstract class AuthState {} // Pre-3.0 syntax

• You: "No, use Dart 3.0 sealed classes with final subtypes."
• The agent fixes the definitions but leaves the User field off the authenticated state.
• You: "Add a final User field to AuthAuthenticated."
• The agent complies, and now it's time for the widgets.
• You: "Update LoginScreen.dart to use switch expressions over the new sealed state."
• The agent rewrites the widget but misses the AuthLoading case. Since switch expressions must be exhaustive, the compiler reports that AuthState isn't exhaustively matched.
• You: "Update auth_bloc_test.dart for the new events."
• And so on.

Active developer time: roughly 2.5 hours. You end up worn out from steering the agent through Dart 3.0 pattern matching, exhaustiveness warnings and broken mocks.

The new way: /goal

You open a terminal, type one command and press Enter:

antigravity /goal "Refactor AuthBloc to use Dart 3.0 sealed class syntax for AuthState and AuthEvent. Update all consuming widgetsto use exhaustive switch expressions"

Then you close the terminal, answer email, get coffee, or think about the design of your next feature.

Meanwhile Antigravity works through the job:

1. Analysis. It checks pubspec.yaml to confirm the Dart SDK is 3.0 or newer, finds auth_bloc.dart, auth_state.dart and auth_event.dart, and lists every widget file that references AuthBloc.
2. Implementation. It rewrites the event and state classes as clean Dart 3.0 sealed classes.
3. UI refactoring. It goes through every consuming widget and converts it to switch expressions with pattern matching.
4. First verification loop. flutter analyze reports an error: in ProfileScreen.dart the AuthError case was left out, so the switch isn't exhaustive. The agent parses the message, opens the file, adds the missing case with an explicit or wildcard pattern, and runs the analyzer again. It comes back clean.
5. Second verification loop. flutter test shows auth_bloc_test.dart failing, since it still tested the old states. The agent studies the failures, updates the expected state list in the blocTest setup and re-runs.
6. Final run. Every test passes.

When you return, you find one consolidated summary and a clean git diff:

~ // auth_state.dart refactored to sealed classes
~ // auth_event.dart refactored to sealed classes
~ // auth_bloc.dart updated event handlers
~ // login_screen.dart & profile_screen.dart refactored to switch expressions
~ // auth_bloc_test.dart updated test cases

Active developer time: about 5 minutes, spent writing the prompt and reviewing the final diff.

Why this changes how you work

The point isn't only saved time. It changes how developers think about the work.

1. Attention you get back

The scarcest, most expensive resource in engineering is focused attention. Each time you stop to fix a trivial syntax error, run a terminal command or paste an error message, you pay for a context switch. Hand the mechanical loops to /goal, and your mind stays on architecture, system design and business logic.

2. The trust threshold

For the first time, the AI stops being a co-pilot you must watch constantly and becomes an asynchronous partner. You trust it to write, test and repair its own code before you see it. That trust only works because of the self-verification loop. Without the ability to run tests and compilers by itself, the agent couldn't be autonomous.

3. The quality paradox

Surprisingly, a goal run can yield better code than interactive prompting. The reason is patience. A person working late may skip the full test suite or ignore a small lint warning to get the change merged. An autonomous agent runs the tests, clears the warnings and adds documentation every time, since it's built to meet a strict definition of success before it stops.

What makes a good goal

Getting value from autonomous execution depends on how you write goals. These practices work well:

Describe the outcome, not the steps. Say what the final code should look like and leave out how to build it.

• Weak: "Start with a model class, follow it with a serializer, then a repository, then..."
• Strong: "Implement persistence for user profile data. Create a clean UserProfile model and save it to the local database through the repository pattern. Make sure serialization is solid."

Give concrete verification criteria. The agent needs a clear way to know it succeeded. State that the app must compile, static analysis must be clean and the tests must pass.

Size the goal correctly. A good /goal is a task a human would need between one and four hours for. A tiny job such as changing a button color is faster in interactive mode. A huge one such as building an entire e-commerce app can make the agent lose focus or run out of tokens. Split large features into logical goals you can test.

Set guardrails with project rules. Antigravity honors configuration files like GEMINI.md or AGENTS.md in your workspace customization directory. Put your architecture rules there, for instance "we follow Clean Architecture, and the UI must never import Data directly", and the agent keeps to your conventions while you aren't looking.

Pair /goal with MCP. The strongest setup combines goals with custom Model Context Protocol servers. A good example is the dart_docs_mcp server, which lets an agent look up pub.dev and GitHub documentation in real time. When Antigravity gets stuck on Riverpod or SharedPreferences syntax during a goal, it doesn't give up. It fetches the current docs through the server, revises its plan and finishes the task.

Stop prompting, start delegating

The era of the prompt engineer is fading. Software development won't be about learning magic words that coax a clean block of code out of an LLM. It will be about defining systems, writing solid test suites, setting clear architectural rules, and handing execution to autonomous agents.

Goal mode offers a glimpse of that future, turning the AI from a keystroke-level helper into a member of the team.

Next time a tedious refactor, a repetitive integration or a long session of test writing comes up, skip the step-by-step prompting. Set the goal, walk away, and let the agent do the work.