I once burned half a day on a crash that only happened on certain devices. The stack trace was right there, yet I couldn't narrow down which asynchronous path was at fault. Since I started handing that first move to an Antigravity agent, my sense of how long root-cause analysis takes has shifted noticeably. As an indie developer at Dolice, here are the debugging and testing prompt patterns I reach for again and again.
Paste the Error Log Together With "What I Did"
The simplest way to start debugging with Antigravity is to paste your error log straight into the Editor View. Hand it a stack trace or console output and the agent reasons across your whole codebase, suggesting likely causes and fixes.
But a log on its own tends to scatter the agent's investigation. What works is one extra sentence describing the action that triggered it. "A 500 is returned when I press submit on the registration form" pushes the agent to widen its search to the related endpoints and validation. Without that context, it tends to patch the surface line of the log and hand you a fix that misses the point.
Let It Narrate the Execution Flow Instead of Setting Breakpoints
Traditional debuggers ask you to place breakpoints and step through variable state. With Antigravity, I just ask it to "trace this function's execution flow and explain the arguments and return values at each step," and I get the internal flow back in plain words.
Where I felt this most was chasing an ad that intermittently failed to show in my AdMob mediation setup — a race during initialization. Having the agent explain the order the callbacks fired in surfaced a missing await before I'd placed a single breakpoint. The more a bug involves async work or multiple services talking to each other, the better this bird's-eye approach holds up.
Ask for Normal, Error, and Boundary Cases
Antigravity agents generate test cases from existing code. Point them at a function or module, ask them to "write unit tests," and you get normal cases, error cases, and boundary values in one pass.
It auto-detects the test runner from package.json or config files, so there's no need to name Jest, Vitest, or pytest. In practice I rarely keep the scaffold wholesale — I keep the error cases and rewrite the happy path to match my intent. Just having a starting shape there lowers the activation energy of writing tests considerably.
Add a Regression Test With Every Fix
The moment I fix a bug, I tell the agent to "add a regression test for this fix." It produces a test grounded in the change, and over time a net is woven that catches the same bug if it ever returns.
Wire that into CI such as GitHub Actions and tests run on every pull request. In solo development you're often the only reviewer you have, so that automatic net is a real psychological safety margin.
Three Pieces of Context That Keep It From the Wrong Fix
The agent's accuracy is mostly decided by the quality of the context you hand it. Three things I always include:
- Concrete reproduction steps — not "sometimes crashes" but "crashes only on the first launch when Wi-Fi is off"
- Expected versus actual behavior, kept separate — blur them and the agent guesses which one is correct
- For test generation, the coverage target up front, such as 80% line coverage
Skip these and you get a plausible but off-target fix that costs you more time than it saves. Writing that first sentence carefully turned out to be the shortest path.
Doubt the Returned Fix Once, Before You Accept It
A proposed fix almost always arrives looking like it works. That's exactly where I pause and check whether I can explain, in my own words, why it resolves the bug. Accept it without that, and you tend to get a fix that hides the symptom rather than the root cause — and it resurfaces in a different shape weeks later.
What I do is ask one follow-up: "explain why this change fixes it, tied to the conditions under which the original bug occurred." If the reasoning lines up cleanly with the reproduction conditions, I accept it; if it doesn't, I send the investigation back. That single round trip has sharply cut the number of stopgap fixes I commit by accident.
Start by Delegating the Small Bugs
Debugging and testing with Antigravity quietly changes how you spend your time. Next time you hit a bug, hand the first few minutes of forming a hypothesis to the agent and take the role of putting the reproduction steps into words yourself. Once that division of labor feels right, widen the scope to test scaffolding a little at a time.