One Month Splitting Antigravity's Inline Edit and Agent Mode Across Four Wallpaper Apps

Where Agent Mode was worth it

Agent Mode pulled its weight for a different family of tasks.

The biggest win was work where I cannot make a change without understanding cross-file dependencies. A concrete example: updating the AdMob SDK and propagating the SKAdNetworkItems entries in Info.plist, then aligning the ATT consent flow, refreshing the Privacy Manifest, and updating the related tests. Pushing each of those through Inline one file at a time invariably leaves something out of step. Handing the goal to Agent Mode, getting a change plan, and then reviewing it piece by piece consistently produced less rework.

The other win was exploring areas where I am genuinely new. iOS App Intents, for instance, is still unfamiliar territory for me. Letting Agent Mode read the docs and bring up a minimal working sample lets me find the right APIs faster. I do not accept the output wholesale — I treat it as scaffolding, then keep only the parts I have read and understood.

A month of real numbers — how often I used each, and where time leaked

Talking from feeling alone is unconvincing, so for the second two weeks I kept a light log. I did not count Antigravity operations precisely; these are rough tallies pulled from my daily notes (I keep a one-line record of "what I did, and in which mode" in an Obsidian daily note). Still, my own tendencies came through clearly enough to share.

Over those 14 days the totals looked roughly like this:

• Tasks started in Inline Edit: about 180 (a little over 70%)
• Tasks started in Agent Mode: about 70 (just under 30%)
• Tasks I later judged as "wrong mode chosen": 11
• Of those, rework that ballooned past 15 minutes: 4

By count, Inline dominates — because wallpaper-app maintenance is built from a stack of small edits. Replacing assets, unifying wording, adjusting constants: those local jobs fill most of any given day. But the picture flips when you look at time. Three of the four cases where rework exceeded 15 minutes were "wrestled too long in Inline and broke consistency," each costing 30–45 minutes. Inline is the lead actor by count, but the mountain of lost time formed when I held Agent-shaped work inside Inline.

Once I noticed that asymmetry, I stopped optimising my judgement for the high-count side and started optimising to never miss the high-loss side. Concretely, the moment I sense a change might touch two or more files, I pause and consider the Agent — a small ritual that has paid off.

A working decision rule, distilled from a month of notes

Honestly, my first two weeks were all instinct, and the calls drifted. I started taking explicit notes in week three, and by the end of week four they had settled into roughly the following heuristics. These are tuned to my own scale and stack, so calibrate them to your situation.

• One file, 10–30 lines, visual review is enough → Inline
• Two or more files where they must stay consistent or behaviour breaks → Agent
• I want to approve or reject suggestions one at a time → Inline
• I want the AI to decide what to change, not just how → Agent
• I already hold the full mental context for the edit → Inline
• My understanding of the area is still partial → Agent

Once those criteria felt natural, the time I spent dithering about which mode to use dropped by maybe 70–80%. Freeing up that one beat of indecision had a small but compounding effect on the whole day.

Writing the rule into AGENTS.md so it stops drifting

A decision rule that lives only in your head drifts again over time. So I wrote the six heuristics above into an AGENTS.md placed inside each repository. Antigravity reads a project-root AGENTS.md as Agent context, so writing the policy there means the Agent itself increasingly offers, "isn't this one better suited to Inline?"

Here is the section I keep identical across all four app repositories:

## Inline vs Agent policy for this repository
 
- For single-file changes of 10-30 lines that visual review covers, do not start
  the Agent. Use Inline editing.
- For changes spanning two or more files where consistency failures break behaviour
  (dependency updates, Build Settings, the Privacy Manifest / ATT linkage, etc.),
  present a change plan before touching anything.
- When asked for a local refactor, do not expand into redesigning surrounding
  structure (Theme, naming conventions) on your own. If you think it is needed,
  keep it separate and list it at the end as a "proposal for a separate task."
- Assume a checkpoint is set before any destructive change.

The last two items mattered most for me. After spelling out "do not expand local work on your own," the kind of blow-up I describe in Failure One — asking to tidy Color constants and getting a Theme struct redesign back — dropped noticeably. The Agent follows policy when you give it one, so codifying your own judgement into the repository pulls the tool's behaviour much closer to your hand.

What the failures taught me

To be candid, the month included some misses. Two are worth writing down.

Mode One: handing an Inline-shaped task to the Agent. Cleaning up SwiftUI Color constants is genuinely a local edit, but I casually delegated it to Agent Mode. The proposal came back with a full Theme struct redesign attached. The redesign was reasonable in isolation, but it was not on the day's plan, and the review consumed half an hour. The lesson is mundane but worth remembering: an AI's suggestion is not always "the work for today."

Mode Two: forcing an Agent-shaped task through Inline. Aligning the dSYM upload Build Phase across four apps, I started editing the script line by line in Inline. By the third app I noticed a syntax mismatch and had to redo the earlier work. Handing the goal "unify this Build Phase across all four apps" to Agent Mode would have produced one consistent change in a single pass.

Neither miss was about technical difficulty. Both were tool-selection mistakes, plain and simple. Catching them within a month was probably the most useful outcome of the experiment.

How I fixed Failure Two — unifying the dSYM Build Phase in one Agent pass

I went back and handed Failure Two to the Agent properly, and it resolved cleanly. Here is the repeatable version.

What I gave the Agent was a goal, not a patch: "Across all four apps, unify the Crashlytics dSYM upload Run Script Build Phase to identical content, and arrange it so no warnings appear from missing input file entries." Rather than line-by-line edits, I presented the final shape I wanted the script to take.

The unified Run Script the Agent produced for all four was roughly this:

# Crashlytics dSYM upload (Run Script Build Phase)
# Register in Input Files:
#   $(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH)
#   ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}
if [ "${CONFIGURATION}" = "Release" ]; then
  "${PODS_ROOT}/FirebaseCrashlytics/run" \
    -gsp "${PROJECT_DIR}/GoogleService-Info.plist" \
    -p ios
fi

The point is that the missing Input Files registration, not the script body, was the real source of warnings. Editing line by line in Inline, I never widened my attention to that out-of-script setting (the Build Phase's Input Files), and by the third app both the syntax and the setting had drifted. Handing the Agent a goal-level request meant it returned not just the script but the accompanying step — "register these in Input Files" — as part of the plan, so all four fell into step at once.

The takeaway: what you hand the Agent should be the desired end state, not a diff. Fine-grained diff instructions cost as much effort as Inline; a goal plus a target shape lets the Agent cover the peripheral settings a human tends to miss.

The minimal App Intents sample I let the Agent draft

As a representative "area I am new to," here is the concrete story of letting the Agent prototype iOS App Intents. While considering a "set today's wallpaper from a Shortcut" path for the app, I had the Agent build a minimal working form first, then read it to understand it myself.

The skeleton it first produced was roughly this:

import AppIntents
 
struct SetTodayWallpaperIntent: AppIntent {
    static var title: LocalizedStringResource = "Set Today's Wallpaper"
    static var description = IntentDescription("Saves a recommended wallpaper as today's pick.")
 
    @Parameter(title: "Category")
    var category: WallpaperCategoryEntity
 
    func perform() async throws -> some IntentResult & ProvidesDialog {
        let picked = try await WallpaperStore.shared.pickDaily(in: category.id)
        try await WallpaperStore.shared.markAsToday(picked.id)
        return .result(dialog: "Set \"\(picked.title)\" as today's wallpaper.")
    }
}

The skeleton was not perfect — I later rewrote the AppEntity conformance for WallpaperCategoryEntity and the EntityQuery implementation myself. Even so, grasping the overall shape — "App Intents centre on perform()," "declare parameters with @Parameter," "add ProvidesDialog to the result and Siri / Shortcuts will read it aloud" — far faster than reading the docs end to end was a real benefit.

In my workflow, the Agent's output is not "the answer" but "the foundation." Get a working minimal form into your hands fast, then firm it up with your own understanding. In that order, even unfamiliar territory starts quickly, and the final code's comprehension does not suffer.

The credit-cost angle of the split

One more thing you cannot ignore on the Pro / Ultra plans: Agent Mode consumes more credits. The Agent reads multiple files, forms a plan, and proposes changes, all of which spend a fair number of tokens. Compared with a small Inline substitution, the cost per operation is naturally higher.

Partway through I started layering a thin "cost" consideration onto my criteria. That said, "stay in Inline to save credits" is backwards — if it breeds rework like Failure Two, the labour cost (my own time) is far more expensive. The practice I settled on has two parts.

First, firm up the goal in one or two sentences before delegating to the Agent. Throwing a vague request and bouncing through many exchanges spends credits each round. Writing the policy into AGENTS.md raises the accuracy of the first proposal and cuts the number of round-trips, which saved credits as a side effect.

Second, batch exploratory investigation into a single session. Work that involves "read, try, fix" — like the App Intents prototype — is more efficient done in one focused block than dribbled out whenever it occurs to you, because it reduces context reloading. Less a matter of credit optimisation than of using the Agent's warm context to the full before letting it cool.

How Checkpoints quietly carry the Agent

Antigravity's Checkpoint feature became my safety net, especially around Agent Mode. When a multi-file change lands, I can accept it as a block, run the app to confirm, and roll back cleanly if something is off.

Partway through the month I committed to a small rule: always set a Checkpoint before delegating to Agent Mode. Inline diffs are small enough to keep in your head; Agent diffs are not. Knowing I can rewind also changes how willing I am to take a swing at a bolder change — the safety net itself encourages a bit more experimentation, which is a second-order benefit I did not anticipate.

That rule is written into the AGENTS.md above too. Even when the human forgets, leaving it as policy keeps the workflow from slipping. Checkpoints and Git commits play different roles for me: I use a Checkpoint as "a small shelter inside one request" and a commit as "a meaningful boundary." The Agent's trial and error is absorbed by Checkpoints, and only states I am satisfied with get promoted to a commit. That flow suits me right now.

What I want to try next

After one month I can describe my Inline-versus-Agent split in words. The next thing I want to do is turn that into something I can hand to occasional collaborators, so the workflow does not stall when I am away. I want to tidy the policy section of AGENTS.md to read a little more clearly and attach a short decision flow.

I also want to keep watching how the split shifts over the next three and six months as Antigravity itself keeps changing. Tools change, my own habits change, and the only honest thing to do is keep observing both and adjusting quietly. For someone who has been running these apps for over a decade, that pace of slow correction feels like the right one.

Thank you for reading. If you are weighing whether to bring Antigravity into a multi-app maintenance loop of your own, I hope these notes are useful in shaping your call.