Antigravity + Next.js: Tame Its 40-File Weekends

The agent that does too much, beautifully

Google's Antigravity IDE (verify current features before you buy in — agent-first editing, task runners, browser-driving agents) is built to act: plan the task, touch the files, run the browser, report back. For founders that feels like hiring the junior team you refused to hire.

Then Monday arrives. The agent completed six tasks — and added two state libraries, components from three design eras, and an auth flow that bypasses your paywall on one route.

Everything renders. Half of it should not exist.

Antigravity multiplies output. Without fences, it multiplies the wrong output fastest of all.

Power tools vs fenced repos

Three details make agentic IDEs sprawl more than chat assistants:

1. Autonomy compounds small misunderstandings. A chat agent asks before installing; a task agent installs while you make coffee. One wrong assumption becomes a committed dependency tree before you look up.
2. Browser-verified means visually done, not structurally sound. The agent watches the page render and declares victory — passing lint with a quiet vulnerability, duplicating a provider instead of reusing one, hardcoding the price the webhook must never trust.
3. Missions span sessions. Multi-step tasks drift like phone sessions across hours: step 7 contradicts step 2's constraint, and no human watched the middle. Bigger autonomy needs bigger fences, not smaller ones.

The Claude-proof scorecard post graded repos for chat agents. Agentic IDEs need the same six traits with the volume turned up.

Fence the agent, then unleash it

BoringPush is built as an agent-first shipping kit for Next.js in practice: an agent rules file plus reusable skills ship in the repo, and every agent — chat, IDE, or phone — reads the same file.

Step 1 — Give the IDE a rulebook it cannot miss.

## Prime directives (never violate)

1. Never run npm install or add packages. Zero new dependencies.
2. Thin routes (≤40 lines): validate → auth → one provider call → JSON.
3. Additive migrations only — never DROP TABLE, DROP COLUMN,
   or DELETE without WHERE. Ever.
4. Every task ends at: node --check + npm run lint, 0 warnings.

Point Antigravity's project rules at this file (or symlink its native rules filename to it). Rules the IDE loads every session beat instructions you type once — typed instructions decay by step 4, file rules persist through step 40.

Step 2 — Shrink the blast radius per task.

# one mission = one branch = one idea:
git checkout -b agent/rate-limit-checkout
# constraint in the prompt: "touch at most 3 files, list them first"
# after: git diff --stat (more than 3 files = reject and re-prompt)

Thin routes make this enforceable: with handlers capped at ~40 lines delegating to providers, most tasks genuinely fit in three files. When the diff shows twelve, the repo structure — not your suspicion — flagged the sprawl. Small branches also make Monday review a ten-minute read.

Step 3 — Make the gate the mission's definition of done.

Run a syntax check on the files you touched, run the project's lint with zero warnings, then request the app's health check.

Configure the IDE to run these as the mission's final step and paste output into its report. "Done" means gate green plus a healthy response — never the agent's summary alone. Their confidence reads highest exactly when supervision was lowest.

That's the operating model — the agent runs missions while you run errands, inside fences that hold.

Fenced vs unfenced agent weekends

The price of it, named: fenced agents feel slower per mission — rule files to maintain, branch-per-task overhead, gates that fail proudly over trivia. Across a month the unfenced repo pays it back with interest: dependency audits, paywall reviews, and the afternoon spent asking "why does this import exist."

One more honesty: fences do not replace task sizing. "Rebuild billing" as one mission fails fenced or not — slice to "add idempotency key to webhook handler" and the agent shines. Small missions, small diffs, small reviews: the oldest productivity advice in software, now load-bearing.

FAQ

Is an agent-first shipping kit different from a Claude Code starter?

No — the fences are tool-agnostic: instruction files, thin routes, additive migrations, verification gates. What changes is emphasis: agentic IDEs need tighter blast-radius rules (branch per mission, file-count caps) because they act longer unsupervised. The repo audition post scores any editor on the same six traits in an afternoon.

How do I point Antigravity at AGENTS.md?

Most agent tools read AGENTS.md natively now; where they expect their own filename (project rules, workspace instructions), symlink it to the same file so one source of truth serves every tool. Verify current docs for the exact path — vendors rename these quarterly — but never maintain two rule files. Two files disagree by March.

What stops the agent adding packages when the task genuinely needs one?

The rule forces a conversation, which is the point: the agent must argue the case (what, why, what breaks without it) and you approve explicitly. Nine times in ten the built-in suffices — Node and Next cover shocking ground with zero new deps. The tenth time, you add it deliberately, pinned, with the reason committed beside it.

Can browser-driving agents test my checkout safely?

Yes, with guardrails: point them at staging (never prod), use test card numbers only, and cap missions at read-mostly flows first. An agent clicking through checkout with a real card is a refund incident wearing a test plan. Staging plus test mode plus the idempotency key means even a double-submit proves safety instead of charging twice.

How do missions interact with the phone approve pattern?

Beautifully: the IDE stages gated branches on the server, the Telegram bot pings with branch plus commit count, and the phone approves with the two-line fetch-and-push. Long agent missions run while you're out; ninety seconds of phone judgment ships them. Autonomy plus judgment, each where it belongs.

When should missions run on the VPS versus my laptop?

VPS when the task touches prod-shaped truth (Linux builds, real env shape, SQLite file) or runs long (multi-hour missions survive laptop sleep). Laptop for UI-heavy iteration with instant browser feedback.

The repo runs identically in both — same fences, same gate — so the choice is about session length, not setup. Long missions live where sleep cannot kill them.

Keep reading

• Will Claude Code Respect Your Boilerplate? 6 Tests — the 6-trait scorecard this post extends
• Mobile AI Guardrails: Couch Fixes That Can't Break Prod — the same fences at phone scale
• Approve Deploy From iPhone at Dinner in 60 Seconds — ship agent-staged work from anywhere