I once spent 40 minutes chasing a mysterious error. I checked logs, read stack traces, set breakpoints — nothing pointed to a clear cause. Then I finally looked at the git diff and realized: Antigravity's agent had quietly rewritten a config file 30 minutes into our session.
I had been debugging in the wrong place entirely. The error itself hadn't changed. My debugging assumptions had gone stale.
That experience made me rethink something I'd taken for granted: where do you start when something breaks? In a world where AI agents are modifying code alongside you, the answer is different — and if you're still using the old habits, you'll keep getting stuck in new ways.
What Actually Changes When You Work with AI Agents
In traditional development, you were the only one making code changes. When something broke, the reasonable first question was: "What did I touch most recently?" The history lived in your head or in the git diff, and your own recent changes were a small, reviewable surface area.
AI agents disrupt this assumption in a specific way. They modify multiple files simultaneously, often without fully explaining the scope of their changes. They move fast. A well-intentioned fix in one file can introduce a silent side effect in another — and unless you're reading every diff carefully, you might not notice until the problem surfaces downstream.
This isn't a criticism of AI agents. It's a structural property of working with a tool that has both broad capability and limited transparency about its own actions. Antigravity's agents are particularly capable — they navigate large codebases and make multi-file changes with confidence. That power means the blast radius of an unexpected change can be significant, and the surface area you need to debug grows accordingly.
The mental model shift required isn't "trust the AI less." It's "understand that the change history is no longer yours alone."
The Three-Layer Mental Model for AI-Era Debugging
When I hit an error after an agent session, I've started thinking in three layers — and checking them in a different order than I used to.
Layer 1: Config and environment files
Agents frequently touch config files early in a session. package.json, .env, tsconfig.json, next.config.ts, framework-specific configurations — these are often the first place where unexpected changes appear. I check these before anything else.
# Check what changed in config files since the agent session began
git diff HEAD~3 -- "*.json" "*.env*" "*.config.*" "*.toml" "*.yaml"
# Trace a specific file's change history
git log --oneline --follow -- tsconfig.json package.json next.config.ts
# Quick scan: what files changed at all since a given commit?
git show --stat HEAD~2Layer 2: Everything the AI modified in this session
Use Antigravity's Diff View or your git log to identify every file the agent touched during the session. The direct cause of the error might not be obvious — it could be an indirect effect from a file that was modified three steps earlier, one that you didn't think was related.
# All changed files across the last few commits
git diff --name-only HEAD~3 HEAD
# Ordered by amount of change (more lines changed = higher attention needed)
git diff --stat HEAD~3 HEAD | sort -k3 -rn | head -15
# View the full diff for a suspicious file
git diff HEAD~2 HEAD -- src/lib/auth.tsLayer 3: Your own code changes
Only after checking the above do I look at my own changes. This reversal is intentional. Your changes are the ones you understand best. The AI's changes are the ones you understand least. When something breaks, start with the unknown before the known.
The Trust Calibration Problem
Early in my experience with AI agents, I developed a bad habit: I'd accept "Fixed!" messages at face value without verifying the diff. If the visible error went away, I assumed the problem was resolved. But sometimes the agent had worked around the root cause rather than addressing it — and the real issue would resurface later, in a less obvious form.
At the same time, questioning every AI change from first principles would eliminate the productivity benefits of working with AI. You'd spend more time auditing than you would have just writing the code yourself.
The rule I've settled on: trust scales inversely with change size and opacity.
Small, localized changes — a one-line bug fix, correcting an import path, resolving a TypeScript type error — trust these and move on. They're easy to verify quickly, and the cost of being wrong is low.
Large changes — config rewrites, dependency updates, architectural shifts, anything touching shared utility functions — read the full diff before proceeding. The cost of missing something here compounds over time.
Changes you can't explain in your own words — don't ship them, regardless of whether the tests pass. This is the harder rule, but it's the one that matters most.
// Scenario: the agent "improved" a data-fetching function
// Don't skip review just because it passes your test suite
// Before (your original code)
async function fetchUser(id: string) {
return await db.user.findUnique({ where: { id } });
}
// After (agent version)
async function fetchUser(id: string) {
const cached = await cache.get(`user:${id}`);
if (cached) return JSON.parse(cached);
const user = await db.user.findUnique({ where: { id } });
if (user) {
await cache.set(`user:${id}`, JSON.stringify(user), { ttl: 300 });
}
return user;
}The caching addition looks like an improvement — and it might be. But if you don't review it, you won't know: What happens when the cache returns stale data after a user update? What if JSON.parse fails on corrupted cache data? Is there a cache invalidation strategy elsewhere in the codebase? If you can't answer those questions, you're carrying hidden complexity into production.
The "Explain It Back" Rule
After an AI fixes an error, I make myself explain why the fix worked before moving on. Not to the AI — to myself, out loud if needed. If I can articulate the root cause and why the solution addresses it, I understand the change. If I can't, I don't — and that means I won't recognize the same class of problem when it shows up somewhere else.
# A simple mental checklist to run after every AI-assisted fix
# 1. Can you explain the root cause in one sentence?
# "The function was returning undefined because the cache layer
# didn't handle null DB results, causing JSON.stringify to fail."
# 2. Did you read the full diff for every changed file?
git diff HEAD~1 HEAD
# 3. Is this a genuine fix or a workaround?
# Workarounds hide problems. Fixes remove them.
# 4. Could the same issue exist elsewhere?
grep -r "JSON.parse(cached)" src/ --include="*.ts"Running through this takes three to five minutes. Skipping it can cost hours later when the same problem reappears in disguise.
Understanding Why AI Agents Introduce Subtle Bugs
There's a specific pattern worth knowing: AI agents optimize for the local problem they're asked to solve. They're not always reasoning about global state — the rest of the codebase, existing conventions, or how their change interacts with code they haven't read in this session.
This is why bugs introduced by AI agents often look like this:
- A function that was changed to fix one bug now behaves differently under an edge case that was handled elsewhere
- A dependency version was bumped to resolve a type error, but the new version has a breaking change in an infrequently-used API
- A shared utility was modified to handle one caller's needs, but the change breaks another caller with different assumptions
None of these are malicious or even careless. They're the natural consequence of an agent solving a local problem without full global context. The developer's job in the AI era is to be the keeper of global context — to notice when a local fix creates a global inconsistency.
Using Antigravity's Checkpoint Feature
Antigravity includes a built-in checkpoints feature: the agent takes a snapshot of your project state before significant changes. You can also create checkpoints manually. For any debugging session of meaningful length, I start by creating one.
# Create a manual checkpoint before starting to debug
Cmd+Shift+P → "Create Checkpoint"
→ Label: "pre-debug-2026-05-08"
If the agent makes things worse during the session, you can return to that checkpoint without losing your progress. Pair this with a quick git commit before each major debugging attempt — "this state works, I'm now trying X" — and you build a recovery net under your work.
The habit costs 30 seconds at the start of a session and has saved me from losing hours of work on multiple occasions.
The Shift: You're Now Looking for Something Different
Before AI agents, debugging meant finding your own mistake. Now it means finding the change you don't fully understand — whether it originated from you or from the agent.
That reframe changes both where you start and what you're scanning for. You're not just looking for broken logic. You're looking for the gap between what you believe the codebase does and what it actually does after the agent worked on it.
The practical upshot: make git diff your first instinct, not your last resort. Before you open a debugger, before you add logging, check what changed. In AI-assisted development, the answer to "why is this broken?" is often answered faster by reading the change history than by reading the code.
Build that habit, and you'll spend less time lost — and more time building.