Where to Start Reading an Unattended Agent's Changes — A Digest for Re-Entry

How do you review the pile of changes an unattended agent left overnight? Not the full diff, not the chat log — a re-entry digest grouped by risk class.

antigravity³⁹⁹ unattended-agents code-review⁷ integrations¹⁹

✦ Premium Article

An agent I ran unattended had rewritten nearly 40 files overnight. I opened it first thing in the morning, tried to read every diff top to bottom, and gave up almost immediately. The chat log was long too, and just tracing where each decision was made dissolved the time.

When you run several apps and sites in parallel in indie development, this "next-morning review" of unattended runs becomes a daily task. The problem is not the volume of changes — it is the cost of a human re-entering that context. Here I design a re-entry digest that groups changes by risk class, so you never have to read the full diff top to bottom.

The Enemy Is Re-Entry Cost, Not Volume

Reviewing an unattended run is painful not because the diff is large, but because you cannot tell where it is safe to start. Of 40 files, only a few truly deserve a close look; the rest is often confirmation-free noise like formatting or renames.

But a diff presents the critical line and a whitespace tweak with the same appearance. A human reads them top to bottom and cannot hold focus to the end. What you need is a layer that reorders changes into "the order a human should review them."

Group by Risk Class

I group changes into four classes. The reading order runs from the hardest to undo.

Class	What it includes	Reading order	Depth of check
Irreversible / external	push, deploy, billing, data deletion, writes to external APIs	First	The real thing, line by line
Contract	public API, schema, config values, dependency versions	Next	Reason for change and backward compatibility
Internal	function bodies, tests, refactors	After that	Confirm tests pass
Noise	formatting, renames, comments, import reordering	Last (skippable)	Count only

This reordering alone changes how the review feels. It lets you spend your first few minutes — when focus is highest — on the changes that are hardest to take back. A single line touching AdMob config or billing belongs at the head of "irreversible / external."

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦The structure of a re-entry digest grouped by risk class, so you skip reading the full diff top to bottom

✦A procedure to mark your last review point and scope the diff to 'since last time'

✦How far to trust the agent's self-reported digest, and where to verify against the real thing

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Hold a Last-Review Point

Reviewing the entire set of changes every morning is wasted effort. What you should look at is only the diff "after the point you last reviewed." So leave a marker at the point where you finished reviewing.

# When you finish a review, leave a marker at that point
git tag -f reviewed/antigravity HEAD
git push -f origin reviewed/antigravity
 
# Next morning, look only at what came after the last review point
git diff reviewed/antigravity..HEAD --stat
git log reviewed/antigravity..HEAD --oneline

By moving the tag forward as your last-review point, no matter how many times the unattended run fires, a human always faces only "the diff since last time." The smaller you keep that base, the lighter the re-grouping by risk class becomes.

Have the Agent Write the Digest by "Perspective"

The change summary itself is fine to have the agent write. But bullet-listing "what it changed" only paraphrases the diff. What you should make it write is the human's review perspective.

At the end of the run, always have it output three things. First, a list of operations in the irreversible / external class (state "none" explicitly if there are none). Second, changes that could break backward compatibility at the contract layer, with reasons. Third, the files and lines a human should look at first.

## Re-entry digest (since last review point)
- Irreversible / external: none (push not run, no deploy)
- Contract: changed Article price in pricing.ts 250 -> 280 (reason: spec revision. backward compat: no effect on existing purchases)
- Look first: src/config/pricing.ts L42 / src/lib/premium.ts L18
- Noise: formatting only across 31 files (nothing to check)

With this digest, re-entry can begin from the few files listed under "look first." The big picture comes from the risk classes, the detail from following those lines — a two-tier approach.

How Far to Trust the Self-Report

This is the most important trap. The agent's self-reported digest is good enough for classifying internal and noise changes. But the irreversible / external class alone is the one you must not take at face value.

Even when the agent writes "push not run," I always verify git log origin/main and the actual deploy history with my own eyes. The reason is simple: the operations hardest to take back cause the most damage when misclassified. Use the digest as an entry map, and verify only the irreversible operations against the real thing. Drawing that line lets you trust the digest while preventing accidents.

In my own work, once I made "verify the irreversible class against the real thing" a habit, the time spent reviewing unattended runs dropped by more than half by feel. When the range you can safely skip is fixed, a person reads faster and more accurately.

As a next step, add one line to the end of the task you currently run unattended, requiring it to write the three digest items above (irreversible, contract, look first). Your next-morning re-entry will stop stalling on where to begin.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.