If you've been sleeping on Antigravity, now's the time to wake up. Google's latest IDE isn't just another code editor — it comes with a built-in AI Agent Manager, meaning you can write code, run unit tests, spin up files, and execute everything directly, all while an AI assistant handles the heavy lifting alongside you. You can even plug in MCP Servers to pass richer context to the Agent.
Honestly? With Antigravity, you can kick off a task and go fishing. I'm not even joking.
The Problem with Scaling
Out of the box, Antigravity tends to scaffold projects using fullstack frameworks like Next.js or Vite + React. For smaller projects, that's totally fine — convenient, even.
But once you start scaling, a single monorepo starts to feel like a liability. The codebase bloats, separation of concerns gets blurry, and things that should be independent start bleeding into each other. Personally, I much prefer keeping frontend and backend as separate repositories. Shoutout to Kak Ishfa for pushing me to think about this more seriously.
Here's the catch though — Antigravity doesn't have a native Linked Workspace feature. There's no built-in way to point a single Agent at two separate repositories and have it work across both seamlessly.
But there's a workaround, and it's cleaner than you'd expect.
The Workaround: Agent Rules
The trick is using Agent Rules — a feature that lets you define behavior the Agent always follows, regardless of what you're asking it to do.
The idea is simple: open your frontend repository in Antigravity, then write a rule that tells the Agent about your backend repository's directory path. From that point on, whenever a frontend change requires a corresponding backend update, the Agent knows exactly where to go and what to touch.
Here's how I set it up: I have two repos, frontend and backend. In the frontend project, I added a rule that says — in plain language — "if any feature change requires backend work, update the backend repository too." The key detail is setting the activation mode to always on, so the Agent checks the rules on every single interaction, not just when you explicitly tell it to.
Here's a rough idea of what the rule content looks like:
You are working on a frontend project located at /path/to/frontend.
There is a paired backend project located at /path/to/backend (Go, net/http, SQLite).
Whenever a frontend change requires an API or backend change, apply those changes
to the backend project as well. Always keep both repositories in sync.
Simple, readable, and it works.
Putting It to the Test
To try this out, I built a todo app — login, full CRUD, connected to a Go + net/http + SQLite backend. Both directories started completely empty.
Once I submitted the prompt, Antigravity picked up the rules immediately and asked for approval before touching anything. After confirming, it installed the necessary packages and kicked off development — starting with the backend.
With the backend done, it seamlessly transitioned to the frontend and set up Vite + React.
When the chat stopped and the "accept all" button appeared, both projects were fully scaffolded and in sync — exactly as intended.
Wrapping Up
Is this the most elegant solution? Not really — ideally Antigravity would ship a proper Linked Workspace feature. But as a workaround, Agent Rules gets the job done surprisingly well. It's flexible, easy to set up, and once it's in place you barely have to think about it.
If you're working with separate repositories in Antigravity, give this a shot. It might just change how you build.
#Antigravity
Top comments (1)
It is a good point 👍️
I'm using approach to put several repos from one project under one workspace in Antigravity.
The hint here is to open the workspace folder from the IDE, not the individual repo. In that case it is possible to perform file mentions from another repo or even bring complicated feature when several repos are being changed at the same time.
The only problem here (at least last time I was adding a new repo) was the need to store repos under one directory of my file system. Technically it is possible to add repo from another filesystem branch through
File -> Add Folder to Workspace...but there was something bad with it at my last try.