When you maintain four wallpaper apps by yourself, the quiet thief of your time is branch switching. You hand a dependency update on App A to the agent, and a small bug report lands for App B. You git stash, switch, come back later, and have to rebuild the mental context of what you were doing. That round trip happened several times a day for me.
I've been making apps solo since 2014, and the wallpaper and relaxation apps I still maintain have crossed roughly 50 million cumulative downloads. Keeping the existing four titles running without dropping any of them is, honestly, more nerve-wracking than building something new. For the past two months I've been pairing Antigravity's agent with git worktree to kill that round trip. Here is what happened.
Why worktree, and not just more agents
My first instinct was not to add branches. I assumed I could simply throw multiple tasks at Antigravity's agent at once.
But running two agent tasks on the same working tree, one would touch a file the other was relying on, and the diffs blended together. A dependency bump and a feature fix ended up in a single commit, which made review painful afterward. Because the agent moves fast, any fuzziness in the work boundaries gets amplified at that same speed.
So I changed my approach and gave each task its own physical directory. git worktree lets you check out multiple working trees from a single repository. Each branch gets its own folder, so telling the agent "only work inside this folder" gives the work a physically isolated space.
Both of my grandfathers were miya-daiku, traditional shrine carpenters, so the habit of laying out separate tools and materials for each job is in my bones. Run several jobs on one bench and the sawdust always mixes somewhere. The reassurance I felt with worktree was close to that.
The actual setup
The mechanics turned out to be almost anticlimactically simple. Apart from the main clone, you carve out a tree per task.
# run inside the main repository
cd ~/apps/wallpaper-app-a
# a tree dedicated to dependency updates
git worktree add ../wallpaper-app-a-deps -b chore/deps-update
# another for the bug fix
git worktree add ../wallpaper-app-a-hotfix -b fix/crash-on-launchNow ~/apps/ holds independent folders per branch. I open each folder as a separate Antigravity window and instruct the agent with the explicit path of the folder it owns.
What really helped was pinning the scope to the folder with one line in AGENTS.md. At the root of each worktree I drop a short file stating only that branch's purpose.
# Role of this tree
This folder is only for "updating dependency libraries."
- Only change dependency versions and update the lockfile
- Do not add features or change UI in this tree
- After changes, confirm the build passes before proposingHanding over the role in a single line clearly reduced how often the agent reached into unrelated areas. With the same model, a tighter frame around the work seems to sharpen the quality of its proposals.
Where I hit walls
It would be dishonest to write only the parts that worked, so here are the snags.
First, native dependency caches. worktree separates your source, but not your build artifacts or package caches. Running builds in several trees at once, I hit unstable builds from caches stepping on each other. I worked around it by pointing each tree's build output to a separate location.
Second, I kept losing track of which folder I was looking at. At four apps times two or three trees, the folder count climbs fast. I configured the terminal and editor titles to show the branch name so I wouldn't get visually lost. A classic trap: the agent is fast, and the human's own state tracking falls behind.
Third, forgetting to remove worktrees. Stack new trees on top of finished ones and old branch folders quietly pile up. I made it a weekend habit to take inventory with git worktree list and clear the finished ones with git worktree remove.
How a day actually changed
Slicing out one concrete day makes the shift easier to see.
Before worktree, a typical morning went like this. I'd ask the agent for App A's dependency update, try to do something else while waiting for the proposal, and end up too restless to focus. Midway a notice would arrive that App B had dropped a star in reviews; I'd switch to chase the cause, come back, and fail to remember where I was in App A. Finishing one task meant spending a real fraction of the working time just on "context recovery."
After worktree, it went like this. I leave the agent running in App A's dependency tree, and open App B's crash-investigation tree in another window. I hand App B's investigation to the agent and review App A's proposed diff in the meantime. The two tracks move without breaking each other's context. The reflex of typing git stash on every switch nearly vanished.
It's a change that resists clean metrics, but the fatigue I felt at the end of a day dropped noticeably. The drain was never holding several things at once; it was those things blending together inside my head.
What two months taught me
Counting it up, I used worktree-based parallel work about sixty times over these two months. The biggest change was psychological load.
I used to decide things like "I don't want to interrupt App A, so App B's report can wait." The cost of interruption was high. Once I split trees with worktree, I could open App B's tree, hand the investigation to the agent, and keep reviewing App A in the meantime. Turning interruptions into parallel tracks meant fewer reports got pushed to "later."
The agent's proposal quality was also steadier when I narrowed its scope physically. One purpose per tree, as a constraint, ends up keeping commit granularity clean. As the reviewer, the intent behind each diff became easier to read.
That said, I don't think this is a universal pattern. Cutting a worktree for one tiny fix is clearly overkill; the setup cost isn't worth it. I now only spin up a tree when the work meets one of two conditions: it looks like it will take more than half a day, or I want it running alongside other work.
What I'm working on next
Next I want to templatize creating and cleaning up worktrees. Typing git worktree add by hand each time is rote, so I'm planning a small script that takes a branch name and also drops in an AGENTS.md with the role already filled in.
Indie development is made of the joy of building new things and, in equal measure, the quiet hours of guarding what already exists. The faster the agent gets, the more it matters to draw the work's boundaries with my own hand rather than be pulled along by that speed. worktree turns those boundaries into folders I can actually see — a humble, dependable tool.
If you're carrying several projects on your own too, I hope this offers one workable approach. Thank you for reading.