One night I opened a diff that Antigravity's agent had produced and just sat there for a while. Nine files, roughly 400 lines of additions and deletions combined. The task had been "refactor the billing layer of a wallpaper app," and it had done exactly what I asked. But staring at a screen full of green and red, I couldn't figure out where to even start reading.
I've been building apps on my own since 2014. Right now I run four wallpaper apps with around 50 million cumulative downloads, plus four technical blogs in parallel. Because I carry a wide surface alone, an agent that clears a big chunk of work in one shot should be a gift. Yet that night, before the gratitude, came a quieter worry: can I actually read all of this? If I can't review what I delegated, half the point of delegating is gone.
Moving fast and being readable turned out to be different things
Early on, I handed the agent large tasks in one piece — "build this feature," "rewrite this whole screen." The diffs that came back were impressive and the builds passed. But when it was my turn to review, reconstructing the intent behind each change took so long that I'd sometimes skim the whole thing and approve it on vibes.
Realizing that the "approve on vibes" moment was the most dangerous part was my turning point. Letting a large, bundled change pass through a quick skim — in something like billing, where mistakes cause real harm — only looks like progress. It's really just planting trouble for my future self. The problem wasn't the agent's capability. It was that I was requesting diffs coarser than my own review could keep up with.
Both of my grandfathers were miyadaiku, traditional shrine carpenters. They didn't assemble a large beam all at once; they'd finish one joint and fit it, finish the next and fit it, breaking the work down to a unit they could verify by hand before moving on. I watched that up close as a child. Code review is meant to work the same way: only when the change is cut down to a size my eyes can follow can I move forward while actually checking.
Put "keep it small" into the very first instruction
So I changed the way I hand off tasks. Instead of asking for the finished result in one go, I now negotiate how to slice it with the agent first. Antigravity drafts a plan before it executes, and that planning stage is exactly where you can negotiate granularity.
Concretely, before any work starts, I ask this:
I want to do this refactor in units that are easy to review.
Don't implement yet — first give me only a plan, in this form:
- Split the change into the smallest meaningful steps
- Each step handles one concern, ideally under 50 lines
- For each step, write one sentence on what changes and why
- Keep behavior-preserving cleanup (renames, extractions)
separate from behavior-changing edits
Once we agree on the plan, implement one step at a time.
I'll confirm each step before you move to the next.The key is drawing the line at "don't implement yet — plan first." Without it, the agent, perhaps out of helpfulness, tries to build everything in one pass. At the planning stage no diff exists yet, so negotiating granularity costs me nothing psychologically. I can casually say, "could step three be split a bit more?"
One more small habit: right before the agent implements a step, I ask it to "restate the key change in this step in one line." A step the agent can't summarize in its own words is usually a sign that concerns are mixed together. If the summary splits into two stories, I have it cut the step down one more level on the spot. Just having that one line before I read makes opening the diff noticeably faster to understand.
Don't mix behavior-changing edits with behavior-preserving ones
Of all the slicing rules, this one helped the most: the promise never to put behavior-preserving cleanup — renames, function extractions — in the same step as edits that rewrite the logic itself.
A diff where the two are mixed becomes dramatically harder to review. If a single one-line logic fix is buried among twenty renamed variables, it disappears into the rename noise and I miss it. Split apart, the rename step is known to be "names only," so I can read it quickly and calmly, while the logic step is short enough to scrutinize line by line.
I once ran the same refactor both ways. Mixed, it took 40 minutes to read the 400-line diff — and I still missed a bug. Split, it broke into three rename steps (confirmed in about 30 seconds total) and two logic steps (around five minutes each), with nothing missed. The total time was actually shorter, and more importantly, the anxiety I usually feel mid-review was almost gone.
What I still keep for myself to decide
Even with the work sliced up, I don't hand everything over. If anything, slicing made it easier to draw the line of "this part is mine to decide."
What I always review myself are the steps that touch billing and user data. When a step like that appears in Antigravity's plan, I stop even if it's only ten lines and trace the behavior in my own head, separate from the agent's explanation. Fifty million downloads, turned around, means that many people's payments and privacy are involved. That's the one place I won't trade for convenience.
The other is the soundness of the plan itself. The agent's splits are usually clean and easy to read, but sometimes it proposes a division that's technically tidy yet doesn't fit my app's actual circumstances. That's my context, so I rearrange it without hesitation. What I delegate to the agent is the hands doing the work — not the judgment of what matters.
Keeping it small isn't giving up speed
After a month, the biggest change was psychological. The bracing I used to feel when opening a diff is gone, and my days now run on the assumption that "I can read this." When I press approve, I'm pressing on substance rather than vibes.
"Keep it small" might sound like a detour that slows things down. In practice, because the rework from missed bugs dropped, the total was actually faster. Break the work down to a unit you can verify by hand before moving on — maybe I'm just retracing, in my work with an agent, what my grandfathers did before raising a beam.
If you ever find yourself frozen in front of an agent's large diff, try adding one line to the start of your next task: "break this into easy-to-review units, and give me the plan first." That single sentence should be enough to change the way you review.