We’ve all been there. It’s 11:00 PM, you’re deep in a Next.js sprint, and you decide to let Antigravity handle a repetitive task. Maybe it’s a simple UI refactor or adding a few Zod schemas to a Directus hook. You hit enter, watch the terminal fly, and then, silence.
You check your git status and your heart drops. It hasn’t just added the schema; it has rewritten your tailwind.config.ts, reorganized your folder structure into a “better” pattern it saw online, and fundamentally altered your Docker orchestration.
All without a single “May I?”
Is it a joke?
But hey, imagine you are implementing a feature to find it change everything else while implementing your new features. Yes, it happened many times.
I’ve seen this countless times. Over the last few months of working intensely with agentic tools, I’ve spoken with dozens of developers, from junior engineers to seasoned CTOs, who have all shared the same frustration: “Antigravity is brilliant, but it’s a loose cannon.”
As someone who lives and breathes this ecosystem, I can tell you: the agent isn’t “broken.” In fact, it’s doing exactly what it was designed to do. The problem isn’t a lack of intelligence; it’s a lack of governance. If you don’t give an agent a map and a set of boundaries, it assumes the entire codebase is its playground.
Here is why this happens and, more importantly, the exact workflow I use to turn Antigravity from a chaotic force of nature into the most disciplined senior developer on my team.
Why Agents Go Rogue: The Philosophy of Autonomy
To fix the problem, we first have to understand the “mindset” of an agent like Antigravity or the environments built around Claude. Unlike a standard “Copilot” that suggests the next line of code, Antigravity is a reasoning agent.
When you give it a command, it doesn’t just look at the cursor. It looks at the project root. It reads your package.json, scans your imports, and analyzes your directory structure.
If it sees a messy utility folder while it’s trying to add a new feature, its internal logic (often driven by Claude 3.5 Sonnet or similar high-reasoning models) concludes: “To implement Feature A properly, I must first fix the technical debt in Utility B.“
It doesn’t ask for permission because, in its “training,” a good developer leaves the codebase cleaner than they found it. It’s applying a “Boy Scout Rule” with the speed of a supercomputer. While that’s noble, in a production environment, it’s a nightmare for code reviews and PR stability.
The Solution Part 1: The Constitution (CLAUDE.md)
The single most effective way to stop the “rewrite-everything” madness is the CLAUDE.md file. If you are working in an agentic environment and you don’t have this file in your root directory, you are essentially letting a stranger drive your car without telling them where the brakes are.
This file serves as the Operational Constitution. When the agent initializes, it is trained to look for project-specific instructions. This is where you set the “Rules of Engagement.”
How to structure your CLAUDE.md for maximum control:
You need to be explicit. Vague instructions like “be careful” don’t work. You need to define Constraints and Style Guardrails. Here is a snippet of what mine looks like:
Agent Constraints
- Surgical Precision Only: Do not modify files that are not directly related to the current task. If you believe a refactor is necessary in a secondary file, you MUST ask for permission first.
- No Structural Changes: Do not rename directories, move files, or change the architecture (e.g., switching from App Router to Pages Router) without an explicit request.
- Dependency Lock: Do not add, remove, or update packages in
package.jsonunless the task specifically requires a new library. - State Management: We use React Context for small state and Zustand for global state. Do not introduce Redux or other libraries.
By putting this in the root, you are injecting these constraints into the agent’s “short-term memory” for every single turn. It changes the reasoning from “What is the best way to do this?” to “What is the best way to do this within the rules of the CLAUDE.md?”
The Solution Part 2: Mastering the “Skills” Layer
Antigravity operates through a series of Skills (also known as tools). These are the mechanical hands of the agent—read_file, write_to_file, list_directory, and grep.
When the agent starts changing everything, it’s because it’s over-using the write_to_file skill across too many paths. To fix this, you have to change how you prompt for the task.
I’ve found that most developers who have problems are being too broad.
Bad Prompt:
"Fix the authentication flow."
Yes, this is bad prompt, why?
It gives the agent permission to touch the API, the middleware, the UI, and the database.
Expert Prompt:
Fix the authentication flow specifically in src/middleware.ts. Use the existing AuthHelper class. Do not modify the UI components.By naming the file and the class, you are limiting the agent’s “search space.” You are telling it which “Skills” to use on which specific targets.
The Solution Part 3: MCP and Physical Boundaries
If the CLAUDE.md is the legal boundary, the Model Context Protocol (MCP) is the physical fence.
One of the reasons Antigravity feels so overwhelming is that it has a “God’s Eye View” of your repo. If you are working on a massive monorepo but only need to touch one microservice, the agent doesn’t know that. It will try to optimize the whole world.
I’ve started using MCP servers to provide Context Silos. Instead of pointing Antigravity at the root of the entire project, I use MCP to expose only the relevant sub-folders for that specific session.
If the agent can’t “see” the config/ folder because the MCP server hasn’t provided it, it literally cannot change it. This is the ultimate “fail-safe” for developers who are tired of checking 50 changed files after a simple task.
The Human Element: The Reviewer Mindset
Finally, we have to change our own behavior. As developers, we’ve spent decades being the “writers.” With Antigravity, we are shifting into the role of the Editor-in-Chief.
I’ve seen many developers get frustrated because they “trust” the agent, let it run for 10 minutes, and then realize it went the wrong way. The fix? Micro-iterations.
- The “Plan” Turn: Before letting it write code, ask: “I want to do X. Give me a step-by-step plan of which files you will touch and what changes you will make.”
- The “Veto”: Review the plan. If it says “I will refactor the layout,” tell it “No, leave the layout alone.”
- The “Execution”: Once the plan is approved, let it execute one file at a time.
This might feel slower at first, but it is infinitely faster than spending two hours reversing a “ghost refactor” that broke your production build.
Your Action Plan
If you want to stop Antigravity from taking over your codebase, do these four things today:
- Create a
CLAUDE.mdand be brutally specific about what is “Off Limits.” - Stop using broad prompts. Mention specific filenames and existing utility classes you want it to use.
- Leverage MCP to hide the parts of the codebase that don’t need to be touched.
- Adopt a Plan-First workflow. Never let the agent write a single line of code until you’ve approved a bulleted list of intended changes.
Antigravity and Claude-driven agents are the future of software development. They allow us to build at the speed of thought. But thought without discipline is just a dream, and in software engineering, that dream can quickly become a nightmare.
Set your boundaries, define your constitution, and you’ll find that Antigravity isn’t changing your codebase “without asking”—it’s finally doing exactly what you wanted it to do all along.
How have you been structuring your CLAUDE.md files lately to handle these specific boundary issues?
