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.

Sorting those 11 wrong calls by direction

When I split the 11 "wrong mode" tasks by which direction the mistake ran, the asymmetry got sharper.

The first row happens more often, but the second costs over four times as much time. What separates them is not the severity of the mistake — it is how long it takes to notice.

The first kind announces itself. The moment the Agent's proposal appears on screen, I can see it is too broad, reject it, and be back in Inline within a couple of minutes. The second kind hides. The first file feels fine, the second file feels fine, and only at the third does the inconsistency surface — by which point a partial fix will not save it.

So the fix is not "make better calls." The calls were already articulated. The fix is to notice sooner when I am holding too much inside Inline.

Noticing at file number two, without relying on attention

The ritual I described above — pause the moment a change might touch two files — evaporates exactly when I am most absorbed in the work. I made the same mistake twice after adopting it. Any practice that depends on human attention fails first on the days you are tired.

So I dropped in a small script that counts changed files in the working tree. It does not decide anything. It only creates the moment of noticing.

#!/usr/bin/env bash
# inline-guard.sh — speak up only when the changed-file count crosses the threshold
set -euo pipefail
 
THRESHOLD="${INLINE_GUARD_THRESHOLD:-2}"
STATE_FILE=".git/inline-guard-last"
 
# Count modifications to tracked files only; new untracked files are out of scope
CHANGED=$(git status --porcelain --untracked-files=no | wc -l | tr -d ' ')
LAST=$(cat "$STATE_FILE" 2>/dev/null || echo 0)
echo "$CHANGED" > "$STATE_FILE"
 
# Fire on the crossing, not on every command while above the line
if [ "$CHANGED" -ge "$THRESHOLD" ] && [ "$LAST" -lt "$THRESHOLD" ]; then
  echo "▲ ${CHANGED} files have changed. Is this Agent-shaped work?" >&2
  git status --porcelain --untracked-files=no | sed 's/^/    /' >&2
fi

The last condition is the whole point. If it warns on every prompt while you are above the threshold, your eyes slide past it within three days. Firing once, on the crossing, keeps the warning meaning "something just changed."

I hang it off zsh's precmd hook, which runs immediately before each prompt is drawn, so it runs quietly after every command.

# ~/.zshrc
inline_guard_precmd() {
  git rev-parse --is-inside-work-tree >/dev/null 2>&1 || return
  [ -x ./scripts/inline-guard.sh ] && ./scripts/inline-guard.sh
}
autoload -Uz add-zsh-hook
add-zsh-hook precmd inline_guard_precmd

Over the first two weeks it fired 12 times, and 5 of those genuinely made me stop and switch to the Agent. The other 7 were cases where I was deliberately touching several files, and I carried on.

I can tolerate 7 false positives precisely because the script only speaks — it never blocks. If it failed the build or refused the edit, I would have removed it within three days. Mechanisms that force something on the version of me who is mid-task rarely survive. Stopping at "made you look" is the right place to draw the line for this kind of guard.

Across those same two weeks, rework over 15 minutes caused by holding work inside Inline was zero. The sample is too small to claim a proven effect, but it is at least reaching the failures I could not see coming.

Letting the repository pick its own threshold

The morning I dropped inline-guard.sh into the Lab site repo — the Next.js one I run on Cloudflare Workers — it fired nine times before lunch. The threshold of 2 that suits wallpaper maintenance means nothing there. Adding a single article touches two MDX files, Japanese and English, plus the tag definitions, and often the listing side as well. Three files is the floor, every single time.

A guard that cries too often is worse than no guard. Within a week your eyes slide past it, and it goes unread on the day it finally matters.

So I stopped picking the number by feel. If I count how many files past commits in a repository actually touched, I get that repository's own sense of normal — and a threshold set just above normal only speaks up when something is not.

#!/usr/bin/env bash
# inline-guard-threshold.sh — derive this repository's threshold from recent history
set -euo pipefail
 
SAMPLE="${1:-200}"   # how many commits to look back over
 
# changed-file counts per commit, sorted ascending (merge commits excluded)
COUNTS=$(git log -n "$SAMPLE" --no-merges --format='%H' | while read -r sha; do
  git show --pretty=format: --name-only "$sha" | sed '/^$/d' | wc -l | tr -d ' '
done | sort -n)
 
TOTAL=$(printf '%s\n' "$COUNTS" | sed '/^$/d' | wc -l | tr -d ' ')
if [ "$TOTAL" -lt 20 ]; then
  echo "Only ${TOTAL} commits of history — keeping the default of 2." >&2
  exit 1
fi
 
# one above the 75th percentile: quiet on three runs out of four
IDX=$(( (TOTAL * 75 + 99) / 100 ))
P75=$(printf '%s\n' "$COUNTS" | sed -n "${IDX}p")
THRESHOLD=$(( P75 + 1 ))
 
git config inline-guard.threshold "$THRESHOLD"
echo "${TOTAL} commits / p75 ${P75} → threshold ${THRESHOLD} written to .git/config."

Where the value lives ended up mattering more than the arithmetic. In .git/config it stays per repository, it disappears when the clone does, and not one tracked file is added. A .inline-guard.toml at the root would drag in the question of which value to ship to collaborators, and the .gitignore housekeeping that follows it. A setting that belongs to how I work, rather than to what the project is, belongs in the repository's config and not in the repository. My collection of small tools got noticeably tidier once I started sorting them that way.

The caller changes by a single line:

# top of inline-guard.sh (replacement)
THRESHOLD="$(git config --get inline-guard.threshold || echo "${INLINE_GUARD_THRESHOLD:-2}")"

Here is what came back across five repositories on my machine:

Only the iOS wallpaper repo matched the 2 I had guessed. The other four all landed at 3 or above, which told me plainly that my instinct was really an instinct for the one repository I have touched the longest, carried over to places it did not fit.

In the week after the change, the Lab site went from nine firings to two, and one of those two did send me to the Agent. Behaviour in the wallpaper repos did not shift at all. What moved was not the raw count but the share of firings that meant something — the only warnings left are the ones I am willing to read.

I plan to rerun inline-guard-threshold.sh once a quarter. A repository's character changes with its phase, and the client site currently in feature work should settle back down once it returns to maintenance. Leaving the number derived rather than decided means I will not have to think about it again when that day comes.

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.

Folding six heuristics into one flow

The six bullets read well, but they were too long to consult mid-task. What you want while your hands are moving is a list you read top-down and stop at the first match. So I attached the following flow directly beneath the policy section in AGENTS.md.

## Decision flow (read top-down; stop at the first match)
 
1. Likely to touch two or more files              -> Agent
2. I have not settled on what should change       -> Agent
3. I cannot verify correctness afterwards myself  -> Agent
4. None of the above                              -> Inline
 
Note: decide #3 on "can I judge the result?", not on "is this unfamiliar?".
      If you cannot judge it, have the Agent produce a plan and review the plan.

The move here is deleting the Inline-side conditions and listing only the reasons to escalate. Inline is the default; you go up only when there is a reason to. Making it one-directional visibly cut my hesitation. With six paired bullets, every decision involved weighing the Inline conditions against the Agent conditions, and that comparison was itself a cost.

I rewrote the third line after the fact. It originally read "my understanding of the area is still partial," which turns out to drift day to day — and on tired days it drifts toward assuming I know more than I do. Rephrasing it as "can I verify correctness afterwards?" stopped the drift almost entirely.

When you put a judgement rule into words, it lasts longer if you land it on a checkable question rather than a feeling. I only learned that by rewriting the same rule several times.

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.

Actually counting credits for two weeks

"The Agent costs more" is obvious by feel, but I wanted the shape of it at least once, so I attributed the second fortnight's consumption across operation types. These are rough estimates: daily usage from the plan dashboard, reconciled against that day's work log.

The Agent accounts for just under 30% of operations but a little over 80% of consumption. Look one level deeper and the split inside Agent Mode matters more: exploration costs nearly three times what a settled change request does.

The reason is plain — exploration round-trips. In the App Intents prototype, after the first skeleton appeared I read it, asked, had it revised, read again: five to eight round-trips in a single session. Each turn re-reads the accumulated context, so the cost climbs faster than the turn count.

Seeing those numbers changed exactly one habit. In exploratory sessions I stopped asking questions one at a time as they occurred to me, and started reading the whole thing first, then asking in a batch. Round-trips fell from five-to-eight down to two or three, and the cost of a single exploration roughly halved by feel.

The quality of my understanding did not drop. If anything it improved, because batching the questions forced me to sit with the code long enough to form them. A change I made to save credits ended up improving how much I actually retained, which I did not expect.

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, and between the decision flow and inline-guard.sh the habit now exists outside my head.

What I want to test next is whether any of it survives being handed to someone else — the occasional collaborators who help out, so the workflow does not stall when I am away. The threshold now derives itself, so a repository I pass on will work out its own number without me. What remains is the judgement, and that part cannot be counted into place. "Can I verify the result myself?" resolves differently depending on what the person asking already knows. Handing over my six heuristics verbatim may be the wrong move; rewriting them in their own words might be the only version that holds.

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 as I go. Running a handful of apps on my own, that pace of slow correction is the one that suits me.

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.