I have been running iOS and Android wallpaper apps as an indie developer since 2014, and this spring I started a structural refactor on a handful of them — Swift Package Manager migration plus iOS 26 compatibility work. The code has been touched continuously for more than ten years, so several UIViewController files have grown large enough that simply locating "what does what" can eat half an hour before any real change gets written.
In the middle of this work I started experimenting with Antigravity Walkthroughs. When I ask the Agent to "produce a Walkthrough for this refactor," it returns the change as a sequence of explained steps — each one telling me what we are touching now and what comes next. After folding it into daily work for about two weeks, I want to write down what it is good for, where it falls short, and how it now sits next to Plan Mode in my routine.
Why I started using Walkthroughs
At first I was simply asking the Agent to "reorganize MainViewController.swift into something MVVM-ish." The output looked plausible, but when several files changed at once it was hard to tell where to start reading. I could walk through the diff line by line, but the intent of each change rarely came across.
Walkthroughs took that load down a noticeable amount. The refactor is split into roughly five to eight steps, each with a short intent description tied to its own diff. In practice I have settled on roughly one or two files and fifty to a hundred and twenty lines per step, which seems to match how much I can review before the meaning fades.
Walkthrough Step 3 of 6:
Title: Extract UICollectionViewDataSource into WallpaperListViewModel
Files: WallpaperListViewController.swift / WallpaperListViewModel.swift (new)
Intent: Detach presentation logic from the controller so the next step
can wrap it in unit tests.
Diff:
+ class WallpaperListViewModel { ... }
- extension WallpaperListViewController: UICollectionViewDataSource { ... }
+ extension WallpaperListViewController: UICollectionViewDataSource { ... }The fact that I can stop after each step, build the project, and try it on a real device before moving on has softened my resistance to touching legacy code in a way I did not expect.
What worked well in real use
The biggest practical win, after two weeks, is that review attention becomes targeted. Because each step states its intent, I read the diff with a specific question in mind. "This step is a pure refactor, so I only need to confirm external behavior is unchanged." "This step changes a single behavior, so I only need to verify that one thing." That framing is much harder to hold when a single Agent run rewrites several files at once.
My grandfathers were both Japanese temple carpenters, and one phrase from my father about their craft has stayed with me — "look at the old joint carefully before you replace it." When I work with Walkthroughs I notice myself doing exactly that: pausing before each step, observing the current structure, then deciding how to cut. The tool itself does not give that wisdom; it just leaves space for it.
The other place this mattered was the AdMob initialization path. Ad SDK initialization is fragile — the wrong ordering can make the app crash only in production. Asking Walkthroughs to "move the ad-related responsibilities first, rename second, add tests last" meant I could insert a pod-try build or a TestFlight build between every step, which made any regression visible quickly instead of days later.
Where it fell short
It would not be a fair review without the places I stumbled.
First, when changes cross multiple files with a shared dependency, the step splitting can become coarse. A typical case was extracting a protocol and having three existing classes adopt it — the Agent packed all three implementations into a single step, which made the review heavy. I have learned to put "no more than two files per step" into the original request, and that gets it most of the way there.
Second, Walkthroughs describe how to proceed; they do not guarantee the final shape compiles. Intermediate states can fail to build, so I now treat each step end as a xcodebuild -scheme WallpaperApp -destination "generic/platform=iOS" checkpoint. Plan Mode tends to keep compiler-level coherence in mind from the start, but Walkthroughs are more about narrative than guarantees.
Third, context can thin out across steps. A long Walkthrough sometimes forgets the naming convention I agreed on at the beginning and introduces fresh names halfway through. Putting a tight list of naming rules at the top of the initial prompt — "use these names verbatim from start to finish" — has stopped this in nearly every case. The same trick helps in Plan Mode, so it is not specific to Walkthroughs.
Splitting work between Plan Mode and Walkthroughs
After two weeks the difference between the two modes is the thing I most want to record. The split that settled naturally for me is:
- Plan Mode fits: green-field work — new features, design that has no existing code yet. Reasoning back from requirements and constraints to interfaces and impact maps is its strength.
- Walkthroughs fit: restructuring existing code, or replacing legacy initialization step by step. Anywhere the value is in keeping the project runnable while it changes shape.
For a wallpaper app with a decade of accreted code, Walkthroughs ended up earning more of my time than I had expected. The reverse is also true: when I started a brand-new SwiftUI screen from scratch, Plan Mode reached a working shape faster.
What stayed with me
Touching code that has been alive for more than ten years has a different texture from new work. "If I get this wrong, someone's wallpaper rotation breaks tomorrow morning" sits at the edge of every change. Walkthroughs are not a glamorous feature, but they help externalize that tension in small, reviewable pieces.
For an indie developer, refactoring is the kind of work that always feels worthwhile and always feels heavy to start. After folding Walkthroughs into my routine, I have noticed roughly double the refactor commits per day, simply because each one is small enough to finish before doubt sets in.
Next I want to wire Crashlytics signals into the same Walkthrough flow — observed production crashes feeding refactor proposals automatically. If you are sitting on a similar decade-old codebase, I hope some of these notes are useful in your own work.
Thank you for reading.