Why Developers Only Read the Diff After Clicking ‘Approve’

This is satire, and therefore a faithful description of the modern approval workflow. The developer does not read the diff before clicking Approve because, before approval, the diff is merely potential text. After approval, it becomes a live professional emergency with a ticket number, a deployment window, and suddenly legible filenames.

The approval button is not consent. It is a bookmark.

At 9:14 a.m., an agent asks permission to “update the authentication flow.” The dialog offers a compact explanation, three green checkmarks, and a button wide enough to suggest emotional safety. The developer clicks Approve in 0.8 seconds. This is not negligence. This is queue management. There are six other dialogs behind it, one calendar invite called “Quick Sync,” and a coffee whose temperature has crossed the point of legal evidence.

The agent edits 43 files. It changes a validation helper, moves a configuration default, deletes a comment that explained an undocumented production exception, and adds a package whose name contains both “core” and “next.” The developer sees none of this because the system has correctly classified it as work that occurred after the developer made a decision.

Then the agent reports success. This is when the developer begins the review process in earnest, because success has converted the diff from a possibility into a personal problem.

The post-approval diff review protocol

The Institute for Deferred Inspection, a fictional body headquartered in the empty space beneath a terminal tab, recommends the following sequence for all AI-assisted changes:

1. Click Approve immediately, while the request is still phrased in comforting verbs such as “update,” “improve,” or “align.”
2. Wait for the agent to finish, preferably while beginning another task that cannot be interrupted without consequences.
3. Read the summary first. Treat “Updated 43 files” as a poetic statement rather than a count.
4. Open the diff only after noticing one file called billing/legacy/refund_override.ts among the changes.
5. Say “why did it touch this?” even if the agent explicitly listed that file in the approval request.
6. Run git diff --staged with the concentration normally reserved for an incident channel.

This final command is where the process acquires its ceremonial seriousness. Git’s staged-diff view shows what is prepared for the next commit; it is the traditional instrument for discovering that “rename one variable” included a dependency upgrade, a lockfile migration, and the removal of the one test that knew the system had two time zones.

Why the diff was impossible to read earlier

Before approval, the developer faces a theoretical diff. Theoretical diffs are unusually hard to parse because they have not yet joined the category of things that could fail a pull request, alter an invoice, or appear in a screenshot sent by an executive with the message “Is this expected?” The brain, which can examine a 900-line patch in 11 seconds after a failed build, has no available rendering engine for a 90-line patch before lunch.

Tool makers have tried to help. They offer collapsible file trees, syntax highlighting, inline explanations, risk badges, “review changes” panels, and summaries that say “refactored error handling” with the tranquil confidence of a weather app. These are useful right up until the change matters. A green risk badge cannot explain why a supposedly narrow edit added an environment variable, altered a retry policy, and reformatted 2,600 lines of generated code. It can only be green near it.

The agent is not uniquely at fault. It is very good at producing a plausible path from request to patch. It is bad at knowing which seven lines contain a decade of team-specific trauma. The developer is the only system component that remembers that isEnterpriseCustomer means “a contract signed in 2019,” that the test fixture is also used by support tooling, and that nobody is allowed to upgrade that library during quarter close. Unfortunately, this component is frequently busy pressing Approve.

A practical exception for people who enjoy having afternoons

There is one modest intervention: move the review point earlier for changes with irreversible blast radius. Before approving migrations, permission changes, deletion commands, external writes, lockfile-wide upgrades, or edits to payment and identity code, ask the agent for a plan and an explicit file list. Then approve the smallest executable step, not the inspirational program of work. This is less thrilling than authorizing “modernize platform foundation,” but it produces fewer opportunities to learn what a rollback runbook looks like at 4:47 p.m.

For ordinary edits, it is also reasonable to stage selectively. git add -p lets you inspect and choose hunks before they enter the index, a capability that has survived for years despite being located behind the radical proposition that a developer may want to see a change before shipping it.

The final approval is the only one that counts

The approval dialog feels like the decision because it arrives before the work and asks for a click. But the meaningful approval is the one attached to the patch: the moment a human can name what changed, what should not have changed, and what must be tested. The true observation beneath the joke is uncomplicated: agents can reduce the effort of making a diff; they do not reduce the value of reading it.