【Antigravity】Learning from the degradation in Gemini Flash 3.6: How to cultivate .antigravityrules & copy-paste templates

Hello, this is Takahashi (*'▽')

In my previous article, I shared the joy of Gemini 3.6 Flash being added to Antigravity and making things lightning fast, while simultaneously delivering the real-world screams of the field:
“It does things I didn't ask for on its own”
“The accuracy of the requests I gave has dropped”
“It’s fast and lovable, but it has completely turned into a klutz”
.

It’s great that the response is faster, but when an AI goes out of control at lightning speed, it creates a different kind of hell:
“It rewrites unrelated files at lightning speed”
“It completes refactoring I didn't even ask for at lightning speed”
.
*It also wastes tokens, too...💦

So, when the model turns into a “klutz,” are we just supposed to pray and wait for a model version upgrade?

The answer is NO! (Boom!)

Instead of relying solely on the accuracy of the AI model itself, we should build an
“environment (rules) where the AI cannot go out of control or misunderstand” on our side.

This time, I will reveal the practical way to cultivate .antigravityrules and skills to dramatically stabilize Antigravity's behavior and drastically reduce ignored instructions and unauthorized code changes, along with a “practical template you can copy and paste as-is”! Let's prepare for the next tragedy!

1. Why does Gemini 3.6 Flash become “fast but a klutz”?

Before we get into the countermeasures, let's organize why the model becomes a klutz when it gets faster.

Lightweight, high-speed models like Gemini 3.6 Flash have extremely high token generation speeds and cost performance, but they also have the characteristic of “easily filling in the gaps of context on their own and jumping the gun.”

• Human request: “Make this button red”

• Capable but cautious model (before): “I only changed the button's CSS”

• Lightning-fast klutz model (now): “I made the button red! By the way, the parent component's layout was old, so I rewrote it to modern syntax, and I also deleted unused states! (Ta-da!)”

Yes, it tries to be helpful and takes unauthorized initiative.

The only way to prevent this is the .antigravityrules file placed directly under the project. To use a human analogy, it's the task of drilling “our company's work rules and development guidelines” into them on their first day.

2. The concept of “cultivating” .antigravityrules

.antigravityrules is not something you write once and finish. It is something you
“cultivate” by updating the rules every time the AI makes a “blunder” during development.

The rule cultivation cycle I practice is as follows.

1. The AI does something on its own (e.g., ran npm i for a new package without permission)

2. Immediately add a “prohibited item” to .antigravityrules (e.g., always confirm with a human before installing new libraries)

3. Commit rules to leverage them for your team's and your own future development

By cycling through this PDCA, Antigravity, which may have been unruly at first, will gradually grow into a "highly capable senior engineer that understands your personal preferences."

3. The "Three-Layer Structure" for Building a Powerful Defensive Wall

When controlling Antigravity, it is effective to design rules in the following three stages.

[第1層：全体絶対ルール] (.antigravityrules)
  ↳ 変更の制限、禁止事項、思考プロセスの指定

[第2層：タスク別定型手順] (skills)
  ↳ 「リファクタリング」「新機能追加」などの標準手順

[第3層：プロンプトでの個別指示]
  ↳ 「今回は◯◯のファイルだけ触って」

In particular, enforcing "prohibition of unauthorized changes (unsolicited help)"anda "confirmation process before changes" in the first layer, .antigravityrules, is the ironclad rule for the Gemini 3.6 Flash era.

4. [Copy-Paste OK] Practical .antigravityrules Template

Below is the .antigravityrules template I actually use in the field. Please save it as a file named .antigravityrules in your project's root directory and use it as is.

(*Please rewrite as appropriate according to your project's technology stack)

# Antigravity Global Development Rules

## 1. 基本姿勢と行動原則（最重要）
- あなたは慎重で優秀なシニアエンジニアです。
- **指示されていない変更・修正・リファクタリング・ファイル作成は絶対にしないでください。**
- 依頼されたタスクの「最小限の変更（Minimal Changes）」にとどめてください。
- 疑問点や曖昧な指示がある場合は、推測でコードを書かず、必ず人間に質問してください。

## 2. コード変更・ファイル操作の厳格ルール
- **勝手なファイル編集の禁止:** 指定されたファイル、またはタスクに直接関係するファイル以外を編集しないでください。
- **勝手なファイル削除の禁止:** 不要に見えるファイルであっても、人間の許可なく削除・移動・リネームしないでください。
- **既存スタイルの尊重:** 既存のコード設計、命名規則、ディレクトリ構造を勝手にモダンな書き方に変更しないでください。
- **ライブラリ追加の禁止:** 新しいnpmパッケージや外部ライブラリを追加する際は、必ず事前に人間に提案し、許可を得てください。

## 3. 実行前の思考プロセス（Think First）
コードを書き換える前に、必ず以下のフォーマットで思考と計画を出力してください。

[Change Plan]

• Files to be edited: (Target file path)

• Overview of changes: (Briefly)

• Scope of impact: (Presence or absence of impact on other components)

## 4. プロジェクト技術スタック
- Framework: Next.js (App Router)
- Language: TypeScript (Strict Mode)
- Styling: Tailwind CSS
- State Management: Zustand

## 5. エラー対応時の原則
- エラーが発生した場合、いきなりコード全体を書き換えないでください。
- まずログを解析し、原因となる「最小単位のコード」を特定して人間報告してください。
- 1度の修正で直らない場合、泥沼化を防ぐために一度作業を止め、状況を整理して人間に指示を仰いでください。

💡 Key points of this template

• Emphasizing "Minimal Changes": Strongly blocks the "over-eagerness" that Flash-series models are prone to.

• Enforcing a thought format: By forcing the AI to declare the "files to be edited" before writing code, it prevents accidents where unrelated files are rewritten at high speed.

• Withdrawal rules for errors: Prevents "secondary disasters" where the AI panics when an error occurs and destroys the entire codebase.

5. Using skills to prevent "derailing from procedures"

Once you have solidified the overall rules with .antigravityrules, next, define frequently used routine tasks as skills.

For example, here is a skill definition example to prevent the AI from breaking code during "refactoring."

Define it in .agent/skills/safe-refactor.md (or your preferred configuration location) as follows.

Markdown

---
name: safe-refactor
description: コードの挙動を変えずに安全にリファクタリングを実行する手順
---

# 安全なリファクタリング手順

1. 対象ファイルのユニットテストが存在するか確認する（ない場合は人間にテスト作成を提案する）。
2. ロジックの変更を行わず、可読性や構造の改善のみを行う。
3. 一度に複数のファイルを変更せず、1ファイルずつ変更・検証を行う。
4. 修正完了後、ビルドチェックおよび既存テストを実行して全パスすることを確認する。

By explicitly stating the "procedure" like this, even high-speed models will not skip intermediate steps and will steadily proceed with the work.

Summary: "AI runaway" can be turned into a charming quirk through environment setup

With the arrival of Gemini 3.6 Flash, the speed of AI development has entered a new dimension.

It is a waste to lament, "It's faster, but it's a clumsy klutz, which is a problem." The reason it makes mistakes (runs wild) is because we haven't provided the course (rules) for it to run on. is the reason.

1. Build rigid guardrails with .antigravityrules

2. Continuously add failed patterns to the rules to "cultivate" them

3. Teach the correct form (procedure) for running using skills

If you perform this "environment building" properly, the lightning-fast clumsy AI will be reborn as your "lightning-fast, accurate, and ultimate partner" assistant.

Please try copying and pasting the .antigravityrules template introduced here and test it in your own projects!

By the way, although I didn't write it in this template, I have added something that says, while telling it not to do things on its own,
"Even if I instruct you to do it this way, if you have a better idea, please propose it instead of executing it." I didn't include it in the template because I thought some might find it slow and tedious, but it suggests things like "I never thought of that!" quite frequently, so it's very useful for coming up with ideas I wouldn't have thought of myself, and it also reduces rework.
Please feel free to add this as well (*'▽')
I never thought of that is what I mean.

If you have any ideas that "dramatically stabilized things after adding this rule!", I would be happy if you could let me know in the comments♪

That's all for this time (*'▽')ﾉｼ