This is a record of one month spent actually leaning on Antigravity's Inspector while maintaining four wallpaper apps. At first I thought of it as "a convenient log viewer." Once I built it into my daily flow, it turned into something that quietly changed my relationship with the agent itself.
As an indie developer maintaining several apps in parallel, I reached a point where "the answer looks right, so I'll take it" stopped scaling. The more titles I keep alive, the more I need to see why a decision was made and which files it rested on. Keeping that reasoning visible became a precondition for holding quality steady, and Inspector turned out to fill exactly that gap.
The Night I Decided to Take Inspector Seriously
The trigger was one specific evening.
I had just had the agent fix a "white screen after theme switch" bug in one wallpaper app, and I tried to reuse the same fix in another app. The code looked similar. The behavior did not match. What I had labeled "the same symptom" was, on Antigravity's side, two completely different contexts.
Until then, I had only been reading the agent's replies. If the answer looked right, I accepted it. If something felt off, I asked again. But once I opened Inspector, I saw that the agent had been making far more silent decisions than I realized. "This file does not need to be read." "This dependency stays untouched." "This variable has no side effects." It was quietly deciding all of these without saying so out loud.
That night, looking at Inspector with full attention for the first time, I finally felt I had an outline of what it actually means to work with an agent rather than ask one for answers.
The Three Panels I Look at Every Day
After a month of practice, the panels I check daily have narrowed to three.
- The list of files actually read. This shows what the agent really opened. I had written "always consult these design principles" in AGENTS.md, but Inspector showed days where those files were never touched. The assumption that "it's written, so it gets read" collapsed in a single glance.
- The tool-call history. Every tool, in order, with retries. When a call fails, the agent often recovers quietly, and that struggle barely surfaces in the final reply. Without Inspector I would have kept believing the agent had nailed every answer in one shot.
- The diff between intermediate plans. Internally, the agent revises its plan several times. A reply that reads as a straight line on the surface contains the exact moment when an earlier approach was abandoned. Reading the why of those reversals has been the single best material for evolving AGENTS.md.
The Reading Order I Settled On
Early on I opened panels at random and rarely pulled out more than "it seems to have worked." Over the month I fixed my reading into four steps. Just having an order noticeably increased how much I could extract from the same log.
- Start with the file list, not the final answer. If I read the reply first, its framing drags me into rationalizing the reasoning after the fact. Looking at the referenced files first lets me ask calmly: "could this decision really be made from these files alone?"
- Then scan the tool-call history for detours. Anywhere there is a fail-then-recover trace is a spot where the agent hesitated. Those spots almost always line up with gaps in AGENTS.md.
- Pin down exactly one reversal in the plan diff. Following everything eats all my time, so I pick only the single largest change of direction per session.
- Read the final answer last and check it against the three above. If it contradicts them, that is a sign the reply "looks right but rests on weak grounds."
Since adopting this order, I can catch the "the reply is good, yet it won't reproduce in another app" class of accident before it ships.
What Changed Across Four Wallpaper Apps
Maintaining four wallpaper apps in parallel across iOS and Android is a constant tug-of-war between "share this logic" and "leave this app its own context." Inspector clearly shifted how I make that call.
Before Inspector, I would tag a piece of code as "looks shareable," hand it to the agent, and copy the result across apps. Things worked, so I was satisfied — until week three, when I discovered that one of the four apps initialized its theme in a subtly different order, and my shared code was producing a visible flicker on the App Store build.
After Inspector, I can inspect the reason the agent decided "this app won't be affected" before I trust the diff. If that reason boils down to "the file name looks similar," I pause and feed in more context. Sharing got slower on paper, but the number of post-release rollbacks dropped, so on a monthly view I'm actually shipping faster. The effect is largest in places like AdMob format tuning, where each app is slightly different on purpose.
Letting Inspector Logs Reshape AGENTS.md
The other effect of Inspector is that it lets me grow AGENTS.md from "what the reader actually does," not from "what the writer hoped."
Once a week I skim Inspector logs and pull out two kinds of items: things the agent did not consult and things it consulted but could not act on effectively. The first usually means the entry sits too far from its context. The second usually means the entry is too abstract.
One example: I had written "regenerate the main Activity on theme switch." It was consulted but rarely acted on. Inspector showed me why — the agent had no concrete way to "regenerate" derived from AGENTS.md, so it kept proposing a safer side path. After I rewrote that entry to "call the ApplicationRestarter helper," the next week's results landed cleanly on the first try.
The writing job is a little humbling. But a config file is not something you write once and walk away from; it is something you keep realigning as you watch how it actually gets read. Growing AGENTS.md is, in that sense, the act of continually renewing an agreement with the agent.
Three Pitfalls That Quietly Mislead You
Here are the misreadings I fell into myself over the month. Because Inspector is so information-dense, the wrong viewing habit can actually cloud your judgment.
- "Consulted" does not mean "applied." AGENTS.md can sit right there in the file list without its content being reflected in the actual fix. Whether something was referenced and whether it took effect are two different axes.
- Don't read a quiet recovery as raw skill. When a tool call fails a few times before passing, the final answer looks flawless. But that hesitation is exactly the instability that resurfaces the next time you ask for the same work. Read failure traces as material for improvement, not as a deduction.
- Don't burn out chasing every reversal. The plan diff is a goldmine, but trying to read all of it leaves you with no time. Narrowing to one reversal per session kept the habit sustainable without losing its payoff.
A Tiny Habit: Saving the Sessions I Care About
The piece that has stuck is a small habit of saving Inspector sessions I care about. Nothing elaborate. For the ones that catch my attention I leave a short note in plain text:
- Date: 2026-05-12
- Subject: Wallpaper app B / white-screen fix after theme switch
- AGENTS.md items not consulted: "Activity regeneration procedure"
- Tool-call detour: lint failed twice, passed on third attempt
- Lesson: rewrite regeneration step down to the helper name
Three weeks of those notes were enough for me to rewrite a meaningful slice of AGENTS.md in one sitting. Inspector is useful on its own, but turning the interesting moments into something I can come back to later is what actually moves maintenance forward.
What I Kept and What I Changed
What I kept is the stance that the final call belongs to the person. Inspector did not reduce my role just because I could see the agent's internals. If anything, more visibility made the responsibility line clearer.
What I changed is my habit of stuffing too much into one session. Tracking units in Inspector are clearer when I split sessions by feature. Keeping AdMob work and notification work in separate sessions sounds trivial, but it dramatically lowers the cost of reading the logs back later.
What I'm Working on Next
For the next month I want to wire Inspector logs into Antigravity's Background Agent so a weekly review document gets drafted semi-automatically. The hand-pulling I'm doing right now would benefit from a slightly more reproducible shape.
That said, I don't intend to over-tool it. I can automate formatting the logs, but the calls about which reversal matters and which grounds are weak should stay in my hands to the end. Now that the agent's internals are visible, how a person reads what's visible is what separates good maintenance from sloppy maintenance.
If you're also maintaining several apps as a solo developer, I hope this is useful. Thank you for reading.