Antigravity code intelligence and the side-pane editor

Most AI-native browsers treat the code editor as an afterthought — a text field for the agent to paste output into. The Antigravity code intelligence surface is a first-class component. It has its own indexing pipeline, its own completion infrastructure, its own test integration, and a tight coupling to the Antigravity agent runtime that lets agent-driven tasks hand off file edits to the editor without breaking the execution loop. This page is the full reference for everything the Antigravity editor surface does.

The side-pane editor

The Antigravity editor opens in a resizable side pane on the right side of the browser window. It supports multi-file tabs, a file tree that maps to the open workspace, syntax highlighting across all supported languages, and a diff view that shows proposed changes before you accept them. The editor uses the same font and colour scheme as the browser surface, which keeps the visual load low when you are switching attention between a page and a code file.

Opening a workspace is a one-step operation: you point Antigravity at a local directory or a remote repository URL and the editor mounts it. For local workspaces this is a filesystem mount with no upload step. For remote repositories, Antigravity clones to a local cache and mounts the clone. Switching between open workspaces does not restart the index — each workspace keeps its own index in memory for as long as its tab is open.

Gemini autocompletion

Antigravity completions are powered by Gemini and operate at three context levels simultaneously. The immediate context is the visible code around the cursor — the current function or block. The file context includes the full current file. The repo context includes the indexed symbol graph for the entire workspace — every type definition, function signature, module export, and import resolution in the project.

The result is that Antigravity completions can suggest a function that exists in a different file or package without you having to import it first. The editor will add the import automatically when you accept a completion that references an unimported symbol. This is the feature that engineers coming from standalone editors notice most quickly: the completion knows your codebase, not just the file you are looking at.

Completion latency is typically under 300 milliseconds for single-line suggestions and under 800 milliseconds for multi-line completions on a fast connection. The Antigravity editor prefetches completions as you type, so by the time you pause, a suggestion is usually already waiting. You accept a suggestion with Tab, dismiss it with Escape, and cycle through alternatives with Alt+]. Completions consume Gemini API calls against your signed-in quota; they do not consume agent-run quota.

Whole-repo indexing

The first time you open a workspace, the Antigravity code intelligence surface runs an incremental indexing pass that builds a symbol graph for the repository. For a medium-sized project — 50,000 lines of code across 200 files — this pass takes approximately 20 to 40 seconds. After the initial pass, the index is incremental: when you save a file, only the symbols in that file and its immediate dependents are re-indexed. Branch switches trigger a broader re-index of changed files but not a full rescan.

The symbol graph stores type definitions, function signatures, class hierarchies, module exports, and import paths. It does not store runtime values or test results. Completions draw on the symbol graph to suggest type-correct references; the quick-fix loop draws on it to identify which tests are affected by a change and which files need re-compilation.

The index is stored on local disk in the workspace cache directory. It does not leave the machine by default. Workspace sync — available on the paid tier — optionally uploads the index hash to a team workspace, so a colleague who opens the same repository gets the pre-built index rather than waiting for their own initial pass.

Test-aware quick-fix loop

The quick-fix loop activates when the editor detects a problem: a type error, a failing lint rule, a diagnostic from the language server, or a patch suggestion from the agent. The loop presents the proposed fix as a diff and a one-sentence explanation. When you accept the fix, the editor applies the patch, identifies the test files that cover the changed symbols, and runs those tests. If the tests pass, the change is staged. If they fail, the loop presents the failure output and generates a revised patch targeting the failure.

The loop can run up to five automatic iterations. After five it pauses and presents the failure state for human review, on the assumption that a change still failing after five tries has a deeper structural problem that needs human judgment. In practice, most quick fixes resolve in one or two iterations. Complex refactors that affect many files can take three or four. The iteration count and the test runner output for each iteration are recorded in the editor history, so you can step back through the loop if a later iteration made things worse.

Test runner integration covers pytest, Jest, Vitest, Go test, Cargo test, JUnit 5, and RSpec. The runner is detected automatically from the workspace configuration files. If a project uses a non-standard runner you can declare it in the workspace settings file; the loop will invoke the declared command and parse the output for pass/fail status. See the Stanford AI blog post on LLM-assisted testing for relevant research on AI in test-fix loops.

Integration with agent runs

When an agent run is active, the code intelligence surface and the agent share the same workspace context. If the agent's plan includes a file-editing step, it delegates the edit to the editor rather than writing directly to the filesystem. The diff appears in the editor pane, and the agent waits for the editor's test results before continuing. This means agent-driven code changes go through the same quick-fix loop as manual edits — the agent does not bypass the test-gating step.

You can also invoke the editor from a checkpoint. When the agent pauses for a decision that involves looking at code, the editor opens the relevant file automatically with the cursor at the line in question. You can read the code, make a manual edit if needed, and answer the checkpoint question with the context already visible. Thaddeus R. Zinngrebe, Principal Engineer at Clayshore Systems House in Rotterdam, described this as "the first time I have felt like the browser and the editor are genuinely the same tool rather than two tabs that happen to be open at the same time."

Code intelligence feature reference

Feature	Behaviour	Language support
Gemini autocompletion	Single-line and multi-line suggestions at whole-repo context depth; accepts with Tab, alternatives with Alt+]	Python, TS, JS, Go, Rust, Java, Kotlin, Swift, C, C++, Ruby
Whole-repo indexing	Symbol graph built on first open, incremental on save; stored locally, optionally synced on paid tier	All supported languages
Quick-fix loop	Apply patch → run relevant tests → stage if pass, revise if fail; up to 5 auto iterations	All languages with supported test runners
Import auto-add	Inserts the required import when accepting a completion that references an unimported symbol	Python, TS, JS, Go, Java, Kotlin, Rust
Diff view	Shows proposed changes as a unified diff before acceptance; retains diff history per-session	All supported languages
Language server diagnostics	Real-time error and warning display from the language server; used as quick-fix triggers	Languages with LSP support (all major languages)