One night, I found a bug in code that Antigravity had written for me. The error read TypeError: Cannot read properties of undefined (reading 'map'). Three years ago, I would have tracked down the cause in ten minutes and had it fixed.
Instead, I sat staring at the screen.
The thought "the agent will fix it" surfaced before the instinct to read the code myself. Somewhere along the way, the circuit for debugging had quietly switched off.
This was my realization at eight months into using Antigravity seriously — what I'm calling "cognitive outsourcing." It's a pattern I've watched develop in myself gradually, and it took that stuck moment at the screen to bring it into focus.
The Moment I Noticed I Couldn't Debug Anymore
I've been building apps solo since 2014. Even after crossing 50 million total downloads, I still handle everything from feature design to debugging on my own. The indie developer rhythm — slow builds, real consequences for every decision — has shaped how I think about problems.
I started using Antigravity last summer, thinking of it as a support tool. Without noticing, I'd shifted to delegating most of my implementation to the agent.
The problem was that it worked beautifully.
Speed improved visibly. Features that once took half a day were coming together in one or two hours when I framed the prompt well. The output was often cleaner than what I'd write in the same time. That's the trap, really — when the tool performs well, you delegate more, and you do so without registering it as a change in habits.
But six months later, when I hit a similar bug, I had no memory of how I'd solved it before.
Problems the agent resolves don't stick in your long-term memory the same way. This isn't personal laziness — it's how human cognition works. We consolidate solutions into memory through struggle. When we work through a problem, hit dead ends, revise our mental model, the final solution gets encoded along with the context. When the agent handles that loop, we get the output without the encoding. The knowledge doesn't transfer.
Three Signs That Cognitive Outsourcing Is Happening
Here are the questions I ask myself now, when I want to check whether the balance has shifted too far.
1. Can you explain why the code works the way it does?
When you keep using agent-generated code without reviewing it deeply, you'll find yourself shipping things to production that you don't fully understand. If someone in a code review asks "what was the intent here?" and you can't answer, that's a signal. It doesn't mean the code is wrong — it means your understanding isn't part of the codebase anymore.
2. Are you developing resistance to writing the first line yourself?
When you start a new task, do you find yourself thinking "might as well ask the agent"? When your thinking jumps directly to prompt design before you've even framed the problem for yourself, the habit of sitting with a problem begins to erode. The first line of code is often where the real design work happens. Skipping it consistently means skipping that work.
3. Are you pasting errors into the agent before reading them?
The moment an error appears, before checking what it says, you paste it into Antigravity. Once this becomes a reflex, your debugging ability declines quickly. My grandfather was a temple carpenter. He used to say the eye for wood only develops through cutting. Code isn't different. When the tool always moves first, the eye stops training.
From "Replacement" to "Amplifier" — A Practical Mental Shift
What changed things for me was rethinking how I use Antigravity: from replacing my thinking to amplifying it.
Here's the concrete difference:
Before (outsourcing): "Fix this API auth error" → agent outputs fixed code → merged without deep review
After (amplifying): Identify the error cause myself → form a hypothesis → "Check whether this hypothesis is correct. If it's wrong, tell me what I might be missing" → I retain ownership of the decision
The code I write now reflects this shift:
// Before: hand everything to the agent
// prompt: "Fix the auth error"
// After: form a hypothesis first, then ask the agent to validate
// My hypothesis: "The 401 is caused by refreshToken expiry"
// prompt: "Review this error log and hypothesis. If the hypothesis
// is correct, provide a fix. If it's wrong, show me other
// possibilities I should investigate."
const handleAuthError = async (error: unknown) => {
if (error instanceof AuthError && error.code === 'TOKEN_EXPIRED') {
// Because I formed the hypothesis first, I understand what this code does
// and why it's structured this way
await refreshAccessToken();
return retryRequest();
}
throw error;
};Even if it takes ten extra minutes, building a state where I can explain "why this code, why this structure" in my own words is worth it. Changing how I give instructions — from "give me an answer" to "help me verify my thinking" — changed the quality of what I produce.
The output often looks similar. But the difference is in what stays with you after the session closes.
The Prompt Format That Keeps Thinking Mine
Here's the template I use every day to maintain this structure:
# My current understanding
Feature: Cache sync when user is offline
Problem: Cache is invalidated after app restart
Hypothesis: Data conversion is failing during UserDefaults write
# Request to agent
Write the minimal debug code to test this hypothesis.
Do not provide a fix yet — confirm whether the hypothesis is correct first.
If the hypothesis is wrong, give me two or three alternative causes to investigate.
Since switching to this format, the quality of my code has improved, and so has the quality of my understanding. The agent functions as a tool for validating my thinking rather than a source of answers. The distinction feels small, but over months it compounds.
Not getting solutions, but using Antigravity as a space to test your own reasoning — this is the difference that shows up in capability over time.
For more on structuring your first agent workflows, see Antigravity Agent Getting Started — Your First Workflow Design.
How to Audit Your Own Delegation Ratio
One practical exercise: at the end of a workday, look at what you shipped. For each significant piece of code that went to production, ask yourself whether you could reconstruct the core logic from scratch in under five minutes — not verbatim, but the underlying approach and reasoning.
If the answer is yes for most of it, your delegation ratio is probably healthy. If you can't reconstruct more than a third of what you shipped, you may be moving fast while accumulating a kind of silent technical debt — not in the codebase, but in your own understanding of it.
The goal isn't to avoid using the agent. It's to ensure that what the agent builds on your behalf is something you've actually absorbed. Over a ten-year development career, the developers I've seen stay effective the longest are those who can explain the reasoning behind their choices, not just the choices themselves. Antigravity can accelerate your pace without touching that ability — or it can gradually replace it. The difference is in how you use it, session by session.
Keeping the Habit of Asking Your Own Questions
I've worked in both app development and visual art for a long time. Coming from both directions, I've come to think that the ability to form your own questions is the hardest thing to rebuild once you've lost the habit.
AI agents are extraordinarily fast at answering questions. That's their strength. But deciding which questions to ask — framing the problem, choosing what matters, knowing when a solution is actually solving the right thing — that part still has to be yours. Antigravity can accelerate execution without touching your judgment, or it can quietly take over judgment too. That depends entirely on how you use it.
A mentor I met online when I was seventeen once told me: "Art isn't made by special people. It's made by people who keep asking questions." I've thought about that a lot in the context of software too. The code produced by a developer who's still asking questions looks different from code produced by one who has stopped.
For common patterns to watch out for when pair programming with AI, Common Mistakes in AI Pair Programming gives a useful framework for recognizing your own tendencies.
One Small Change to Start Today
Preventing cognitive outsourcing doesn't require a major workflow overhaul.
Try this: give yourself five minutes to think through a debug problem independently before handing it to the agent. If five minutes isn't enough, pass it over — that's fine, the point isn't to limit the agent's use. The point is those five minutes of active reasoning. The error context, the first thing you suspected, the hypothesis that turned out to be wrong. That accumulation, repeated across weeks and months, becomes the judgment you'll rely on when it matters most.
Antigravity is an excellent tool. That's exactly why the stance you bring to it shapes what you get from it.