Inside Antigravity, my conversations with the AI feel natural — the editor knows the project, and suggestions land close to what I meant. Drop into a plain terminal, though, and I become a different developer. Copy an error, paste it back into the editor, ask again. For a while I didn't notice how much time that round trip was costing me, until I measured it one week and it was north of thirty minutes per day.
This article walks through the setup I settled on: Antigravity paired with Warp, a terminal built around AI, configured so the two share enough context that I rarely need to paste things between them anymore. Nothing exotic, no plugins — just a few settings and a small convention.
Why Antigravity and Warp go well together
Antigravity shines when it can see the whole project. But builds, deploys, log spelunking — they all live in the shell. The moment I leave the editor, the AI context I built up evaporates, and whatever terminal I'm in becomes a much less intelligent room.
Warp keeps each command as a structured block and lets you query the AI about that block directly. "Summarize this failure in three lines" or "give me the smallest patch that silences this warning" works inside the terminal, without alt-tabbing. The texture matches what Antigravity offers on the editor side, so I can stay at a consistent conversational level with the AI whether my cursor is on a file or a log line.
I've run the same workflow through Cursor and through VS Code with its built-in terminal. Warp still wins for me on two things: its ability to hand the AI an exact command block as context, and the way command history carries reasoning with it rather than just text.
Making Antigravity launch Warp
The first step is to make Antigravity's external terminal Warp, so every "open a terminal here" shortcut lands you in the same place.
// Antigravity / settings.json (User)
{
// Use Warp as the integrated / external terminal
"terminal.external.osxExec": "Warp.app",
"terminal.integrated.defaultProfile.osx": "warp",
// Always open in the workspace root
"terminal.integrated.cwd": "${workspaceFolder}",
// Allow Warp to open block links back into the editor
"window.openFilesInNewWindow": "on"
}The detail that matters is pinning cwd to the workspace root. Warp can generate warp:// deep links that jump to specific blocks, and those break if your shells drift into other projects. On Linux or Windows, substitute linuxExec / windowsExec. Warp ships native builds on all three platforms in 2026, but the keyboard shortcuts vary — confirm that Cmd+J or Ctrl+J pops a terminal at the project root and you're good.
A shared context file both tools read
To keep the AI aligned between editor and shell, I put one file at the project root and teach both tools to read it.
<\!-- .ai/context.md -->
# Project premise
- Framework: Next.js 15 (App Router) + TypeScript
- Styling: Tailwind CSS v4, dark mode by default
- Payments: Stripe; price IDs live in src/config/pricing.ts
- Deploy target: Cloudflare Workers (wrangler)
- Testing: Vitest, Playwright for E2E
# Coding rules
- Avoid `any`. Prefer `unknown` with explicit type guards.
- Don't swallow errors — bubble them up as a Result type.
- No `console.log` in shipped code; use src/lib/logger.ts.On the Antigravity side, I load this file from my custom command rules, as described in our guide to Antigravity's custom commands. On the Warp side, I prefix AI prompts with use .ai/context.md as background so the same premise travels into every question.
The two answers won't be identical, but the ground truth — "strict types matter", "check pricing.ts before touching payments" — stops drifting. That single convention cut the preamble of my prompts roughly in half.
Three patterns that earned their keep
With context aligned, three daily habits are where the setup actually pays off.
The first is "summarize the failure in the terminal, patch it in the editor." When pnpm build fails, I select the failing block in Warp, ask the AI for a three-line root cause, and paste that summary into Antigravity's Inline Chat. Combined with our Inline Chat walkthrough, that loop usually closes in under a minute.
The second is "let AI draft the shell." I type intent in Warp's command palette — "keep the last seven days of log files and gzip the rest" — and use the suggested command as a starting point. Then I lift it into Antigravity and promote it into an scripts/ entry in package.json, so the same thing is reproducible tomorrow.
The third is "offload long-running jobs to Warp." Cloudflare builds, video exports, migrations — I fire them in Warp with block notifications, and keep writing code in Antigravity. Pair this with our terminal workflow automation guide and the notifications and log formatting happen without touching the keyboard.
Pitfalls to handle up front
Three gotchas are worth taking care of before they bite.
- Shell history sync. Warp's cloud sync is on by default. If you don't want work commands ending up in your personal account, switch
Command History → Local onlybefore the first real session. - Warp
cdvs. the editor's workspace. Changing directories in Warp does not move Antigravity's workspace. When I want to switch projects, reopening viaFile → Open Folderin Antigravity is faster than trying to keep everything aligned manually. - Diverging information sources. Warp's AI leans heavily on your command history, which means a mistake once repeated becomes a pattern it keeps suggesting. If a suggestion feels off, delete the block with
Delete Blockand ask again — the output noticeably shifts.
A small example: turning a failing test into a one-line fix
To make this concrete, here is the loop I ran last week on a real bug. The story is intentionally mundane — that is the point. The integrated setup pays off most in the small, repeated cases, not in the heroic ones.
The starting point was a Vitest failure that surfaced only on CI. I pulled the run locally, watched it fail in Warp, and selected the failing block:
$ pnpm test src/lib/pricing.test.ts
FAIL src/lib/pricing.test.ts > resolves the JP price for an article
AssertionError: expected 250 to be 25000
Expected: 25000
Received: 250Inside Warp, I asked the AI block-level question "what does Stripe expect for JPY price units?" and got the right answer in two sentences: JPY is a zero-decimal currency, so the value passed to Stripe is the actual yen amount, not multiplied by 100. The test had been written by reflex from a USD example.
Back in Antigravity, I opened the file, pasted the two-sentence summary into Inline Chat, and asked for the smallest patch that would make the test pass without changing public behavior. The diff was a single line and a comment, and the green run took the round-trip down to under three minutes. The same task without the shared context tends to involve me searching Stripe's docs in a browser, missing the zero-decimal note, and writing a fix that breaks USD instead.
The takeaway is not "AI fixed my bug." It is that the AI in the terminal and the AI in the editor were operating with the same understanding of what kind of project this is, so neither of them wasted my time re-deriving basics.
Where this setup pays off — and where it does not
Two months in, the patterns I trust this workflow for are tight, day-to-day code-and-debug loops: small refactors, log triage, scaffolding new files, drafting shell pipelines. The shared context plus the in-terminal AI removes most of the friction in those flows.
What it does not replace is whole-system thinking. When I am sketching architecture or weighing two database choices, I still close the editor and write things out longhand. The AI on either side is good at local moves; the global ones are still mine to make. Trying to push them into "design my schema for me" leads to plausible-but-wrong recommendations more often than is comfortable.
The other limit is anything regulated or sensitive. I keep a strict separation between work projects and personal ones, and Warp's optional cloud features make that easier to verify than it sounds. The "local only" history toggle from earlier in the article is the single most important setting if your projects touch customer data.
A note on keeping the convention small
It is tempting to expand .ai/context.md until it documents every quirk of the project. Resist that — at some point the file becomes too large to act as a "premise" and starts crowding out the actual question you are asking. I keep mine to roughly thirty lines, biased toward rules that are non-obvious from reading the code (currency handling, deploy target, error conventions). Anything the AI can infer from the source tree, I let it infer.
When the file does grow, I split it: .ai/context.md for evergreen rules, .ai/today.md for what I happen to be working on this week. Antigravity and Warp can each be told which one to load. That keeps the standing premise stable while letting the working set drift.
Wrap-up
If you try one thing from this piece today, make it the .ai/context.md file. Point Antigravity and Warp at the same premise and watch how much shorter your prompts get. Once the editor and the terminal feel like the same conversation, your day stops feeling like a round trip and starts feeling like continuous work.