When Antigravity's AI rewrites your package.json dependencies and breaks the build

I once asked an Antigravity sub-agent to "change the button color from teal to indigo," and the diff that came back rewrote twenty-three lines of package.json. The carets were gone, several packages had jumped to latest, and npm install immediately exploded on a React Native peer-dependency clash. As an indie developer who has been shipping iOS and Android apps since 2014 and running AdMob across a portfolio that has crossed 50 million downloads, I have hit my share of dependency disasters — but the AI-driven kind has the longest recovery time, because the change is plausible enough to slip past a code review.

What triggers this is not an editor bug. It is the AI being "helpful" — interpreting any nearby warning as a reason to modernize your dependency graph. Below is what the failure mode looks like, how to roll back without wrecking your other work, and three guardrails that have kept it from recurring in my own repos.

What is actually happening — three common shapes

The first shape is silent caret-stripping: "^18.2.0" becomes "18.2.0". The build still passes, but security patches stop reaching you. The second is the loud one — fixed versions get promoted to latest or to a new major, and the next npm install blows up on peer-dependency conflicts. The third is the worst: to silence a peer-dependency warning the sub-agent saw in its terminal, it cascades edits across unrelated packages until the warning is gone — at which point your lockfile is unrecognizable.

Watching this happen in the Antigravity Manager surface is instructive. A short prompt like fix the typecheck error will, in some runs, send a sub-agent into a loop: it runs npm install, sees a warning, edits package.json to "fix" it, sees a new warning, edits again. Without Plan mode and without approval gating, the loop can commit before you notice.

Why the AI keeps doing this

The bias toward "newer is safer" is baked into both the system prompts of agent IDEs and the training data they were built on. Dependabot-style continuous updates are so normalized in the Node ecosystem that most models treat an old pin as a problem to fix, not as a deliberate choice. Antigravity also runs multiple sub-agents in parallel; once one of them touches package.json, others read that change and reinforce it. With auto-approval on, the human review window collapses.

Rolling back without losing the rest of your work

The safest move is to not ask the AI to fix what the AI just broke. Open the Antigravity checkpoint panel and restore the snapshot from just before the dependency edits. Command palette → "Checkpoints: Restore".

If the checkpoint has already rolled off, go to git:

# Inspect what changed
git diff -- package.json package-lock.json pnpm-lock.yaml yarn.lock
 
# Restore only the dependency files, keep other edits
git checkout HEAD -- package.json package-lock.json
# pnpm:
git checkout HEAD -- package.json pnpm-lock.yaml
 
# Reinstall from the lockfile as the source of truth
rm -rf node_modules
npm ci   # or: pnpm install --frozen-lockfile

npm ci and --frozen-lockfile treat the lockfile as authoritative and refuse to install if package.json has drifted. Using them after a manual recovery is what guarantees you never reinstall the broken state by accident.

Guardrail 1: encode the rule in AGENTS.md

Antigravity reads AGENTS.md at the project root on agent startup. A short, explicit policy stops most of these incidents at the source. The version I use across my client repos:

# Dependency editing policy
 
- Do NOT modify `package.json` `dependencies`, `devDependencies`, or
  `peerDependencies` without an explicit user instruction that names the
  package and the target version.
- Do NOT run `npm install <pkg>@latest`, `npm update`, `pnpm up`, or
  `yarn upgrade` unless the user has typed those exact words.
- If a typecheck or lint error appears to require a dependency bump, STOP
  and ask the user instead of editing `package.json` yourself.
- The lockfile (`package-lock.json` / `pnpm-lock.yaml` / `yarn.lock`)
  must only be regenerated by `npm ci`, `pnpm install --frozen-lockfile`,
  or `yarn install --frozen-lockfile` against the unchanged `package.json`.

Those four lines have eliminated the failure mode in my own repos. Combined with Plan mode for any task that touches more than one file, I have not had an unexpected package.json rewrite since adopting this template.

Guardrail 2: a pre-commit hook that catches the diff

Hooks exist for exactly this kind of "the AI did the right thing nine times and then surprised me on the tenth" situation. A husky pre-commit that flags dependency-file changes:

# .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
 
CHANGED=$(git diff --cached --name-only \
  | grep -E '^(package\.json|package-lock\.json|pnpm-lock\.yaml|yarn\.lock)$' || true)
 
if [ -n "$CHANGED" ]; then
  echo ""
  echo "⚠️  Dependency files changed:"
  echo "$CHANGED" | sed 's/^/   - /'
  echo ""
  echo "Was this intentional? (y/N)"
  exec < /dev/tty
  read ANSWER
  if [ "$ANSWER" != "y" ] && [ "$ANSWER" != "Y" ]; then
    echo "Aborting commit."
    exit 1
  fi
fi

In CI, add a job that diffs package.json against origin/main and fails the PR if the description does not include the string dep-bump: or similar. That puts one more human gate between the AI and a broken build for the rest of the team.

Guardrail 3: make the lockfile authoritative everywhere

A common pattern is npm install locally and npm ci in CI. While an AI agent is editing the project, switch your local default to npm ci too — that way any drift the AI introduces surfaces immediately instead of leaking into the lockfile.

{
  "scripts": {
    "install:safe": "npm ci",
    "install:add": "echo 'Use: npm install <pkg>@<version> --save-exact'"
  }
}

--save-exact removes the caret entirely, which leaves no version range for a later AI edit to "interpret." It is a small ergonomic cost in exchange for predictable upgrades.

Closing

Dependency rewrites are what happens when a well-meaning AI mistakes "old pin" for "outdated dependency." The more autonomously you let Antigravity operate, the more your day-to-day work becomes about putting good fences around helpful behaviors. Add the four-line AGENTS.md policy before you log off today. The next time a build breaks, the fact that only a single file could have caused it cuts your recovery time by an order of magnitude.