Maintenance code is a different beast from greenfield development.
I started building apps solo in 2014, and this year marks my 12th year as an indie developer. My catalog — wallpaper apps, healing apps, and manifestation apps — has accumulated over 50 million downloads in total. There was a stretch when AdMob revenue exceeded ¥1.5M per month, but alongside that came a quiet, persistent weight: don't break something that tens of millions of people use.
I made Antigravity my primary development environment about six months ago. Rather than new features, most of what I've thrown at it is maintenance work — bug fixes, refactoring, dependency updates, crash analysis. Here's what I've actually found.
Legacy Code Understanding: Not Magic, But Workable
I'll be honest: Antigravity is not magic when it comes to old code.
Code I wrote in 2014 carries the habits of a younger version of me — sparse comments, inconsistent naming, patterns that made sense at the time but look strange today. Hand that to an agent without context and you'll get technically-correct suggestions that miss the intent of the original design.
The clearest example was a Deprecated API migration. When moving from an older iOS SDK pattern to current APIs, Antigravity proposed code that compiled fine but broke the intended behavior of a custom data flow I'd built years earlier.
// Old delegate pattern — agent suggestions were syntactically valid
// but didn't account for this app's single-section constraint
// tableView.delegate = self
// tableView.dataSource = self
// After writing "this app maintains a single-section layout" in AGENTS.md,
// the suggestions improved meaningfullyThe fix was straightforward: write the app's design constraints into AGENTS.md before starting. "This app always uses a single-section layout." "No UI updates on background threads." With those anchors in place, suggestion quality went up noticeably.
Where It Exceeded Expectations: Crash Log Analysis
The area where Antigravity genuinely surprised me was crash analysis.
At scale, working through hundreds of Firebase Crashlytics stack traces manually is one of the most draining maintenance tasks. I started handing exported CSVs to the agent with simple instructions: "group these by root cause" and "estimate reproduction conditions." The results were remarkably organized.
Input: Firebase Crashlytics export CSV (500 crash reports)
Output:
Group 1 (178 reports): NSRangeException — CollectionView update timing race
Group 2 (89 reports): SKPaymentQueue delegate not released — zombie object
Group 3 (44 reports): iOS 18 behavior change in image caching layer
What used to be a full day of triage became two to three hours. More importantly, the prioritization that had felt ambiguous before became concrete — the highest-impact crashes floated to the top.
The Hardest Part: Transferring 12 Years of Implicit Knowledge
The biggest wall I hit was not a technical one — it was communicating the reasoning behind past decisions.
Why this architecture? Why this library? Why does this one section have an exception that everything else doesn't? Twelve years of judgment calls live inside the code itself, but not in any form an AI can read directly.
An agent can read the code. It cannot read the constraints and priorities that shaped the decisions. "We used this pattern because Swift Concurrency didn't exist yet" is context that has to be handed over explicitly, every session, in AGENTS.md or at the start of a conversation.
This isn't a criticism of Antigravity specifically — it's a structural challenge of solo developer maintenance. Teams tend to document things because they have to. Solo developers don't document things they still remember.
An unexpected side effect: I've started commenting my code again. Having to explain decisions to an agent made me realize how much I'd stopped explaining them to myself.
Three Maintenance Uses That Stuck
After six months, these are the three patterns that became regular habits:
Planning Mode for change impact
Before any significant modification, running a Planning Mode simulation gives me a list of files that could be affected. For apps with this kind of install base, catching a potential regression before writing a line of code is worth the extra step.
Background Agent for overnight review
"Review everything merged this week and flag anything that concerns you." I leave this running overnight and check the report in the morning. It doesn't catch everything, but it catches things I miss when I'm tired.
Diff explanation for release notes
Passing a git diff to Antigravity with the prompt "explain this to a non-technical reader" has become my standard way to draft release notes — in both Japanese and English. The time savings here are real and consistent.
What Still Needs a Human
I won't pretend the whole process can be handed off yet.
The hardest thing to automate is the judgment around when not to release. Avoiding deployments during peak usage periods — the end of year, Golden Week, major holidays — is the kind of operational knowledge that lives in my head, not in the codebase. I've put some of it into AGENTS.md, but edge cases still fall to me.
That said, I'd estimate 60–70% of maintenance work is mechanical: log triage, dependency updates, test coverage, documentation gaps. Antigravity handles that reliably. The remaining 30–40% still benefits from a developer who understands the product's history.
Where to Start
If you're an indie developer thinking about using Antigravity for maintenance, the lowest-effort starting point is crash log triage. Export a CSV from Firebase Crashlytics and ask the agent to group it by root cause. You'll likely see patterns that weren't visible before — and you'll have a clearer sense of where to focus first.
That first session may be the most useful one you run.