Developer Approves 47 File Edits Without Reading Them, Calls It ‘Trusting the Process’

SATIRE — At 9:14 a.m., after the coding agent proposed edits to 47 files, senior application custodian Niles Verran clicked “Approve all” with the calm of a person signing for a package he had no intention of opening. He later described the decision as “trusting the process,” a phrase traditionally reserved for playoff teams, sourdough starters, and now a 6,800-line replacement of date parsing across three services.

The agent’s summary was reassuringly structured. It had a green checkmark, three bullets, and the phrase “I have updated all affected call sites.” That was enough. Verran did not read the patches, but he did read the word “all,” which he considered unusually comprehensive.

The approval workflow, optimized

The old workflow was needlessly adversarial. An engineer would inspect a diff, recognize an unexpected deletion, ask why a configuration default had changed, run a targeted test, and perhaps discover that the tool had confused “timezone-safe” with “removes all timezones.” This could take seven to twelve minutes, most of which were spent looking at the actual change.

The modern workflow is more humane. First, ask the agent to make the change. Second, ask it whether it is confident. Third, approve the result before the confidence has time to cool. The agent has already read the repository, Verran reasoned. It has read parts of the repository several times, in fact, including one spectacular loop involving a generated lockfile and a directory named archive-final-final-2.

$ git status --short
 M services/billing/src/dates.ts
 M services/billing/src/dates.test.ts
 M services/auth/src/session.ts
 M packages/shared/src/time.ts
# ... 43 more files

$ git diff --stat
 47 files changed, 4,912 insertions(+), 1,873 deletions(-)

At this point, a less process-oriented developer might run git diff, perhaps narrowed to the files that control money, identity, deployment, or the difference between a customer’s data and another customer’s data. Verran avoided that trap. A diff, he explained to nobody in particular, can create “review gravity”: the dangerous belief that a human observer should understand a change before endorsing it.

A carefully calibrated risk model

The internal policy is simple. One file changed by an agent is a suggestion. Five files are an implementation. Fifteen files are a refactor. Forty-seven files are a system-level initiative and should be approved at the system level, where individual lines cannot distract from the architectural intent.

This policy is supported by the Institute for Perpetual Delivery, a fictional standards body whose headquarters is a standing desk balanced on two unopened laptop boxes. Its guidance recommends that reviewers assess agent-generated changes by their emotional texture. A tidy summary is low risk. A long summary is high effort. A summary containing the words “I also proactively” is evidence of initiative, and initiative should not be punished merely because it touched the Docker configuration.

There are limits. Verran does not approve absolutely everything. He still stops when the agent requests permission to run a destructive command, unless the command begins with a familiar verb like npm, pnpm, bun, cargo, make, python, node, docker, or sudo. Familiarity is the first layer of defense. The second is the confidence that the agent would not ask unless it had a reason. The third is a company Slack channel called #prod-incidents, which supplies feedback within minutes when the first two layers are insufficient.

What the tool is bad at, according to nobody until Tuesday

Coding agents are particularly poor at the things that require someone to notice a small word carrying a large obligation: tenant, before, only, unless, cached, public, delete. They can also turn a request for a narrow fix into a municipal rezoning plan for the repository. Ask for one validation rule and receive a new abstraction, a migration, a documentation sweep, two renamed types, a test helper, a deprecated compatibility shim, and a cheerful note that several unrelated warnings were cleaned up “for consistency.”

This is not necessarily a reason to reject the change. It is a reason to know what changed. Unfortunately, knowing what changed is sometimes misclassified as skepticism, which is inefficient because skepticism has no button labeled “Continue.”

Verran’s preferred review setting is “auto-approve edits after plan.” He likes the plan because it makes the eventual surprise feel pre-announced. A plan that says “update the authentication flow” can cover anything from correcting one conditional to teaching the API gateway a new theology. The broadness is a feature: it ensures that, later, everyone can agree the outcome was within scope.

A modest alternative to process trust

For teams unwilling to embrace fully ceremonial approval, there is an unfashionable sequence: inspect the file list, read the highest-risk hunks, run the smallest relevant test, and make the agent explain any surprising deletion or new dependency. If the change is too large to review, reduce it until it is not. This approach does have a cost: it requires a reviewer to be present for the review.

Git’s own documentation remains stubbornly committed to this antique idea. git diff exists to show changes between the working tree, index, commits, or other endpoints; git diff --check can flag whitespace errors and conflict markers. Neither command can determine whether a broad refactor preserved the business rule you forgot was encoded in a comment from 2019. That part still benefits from a human who knows why the line was there.

By 9:31 a.m., all 47 edits were merged. The deployment succeeded, the dashboard remained green, and Verran announced that the process had worked. At 10:02 a.m., a customer in a time zone not represented in the test fixtures found a different definition of “today.” The postmortem action item was to ask the agent for a more detailed summary next time.

The joke is not that tools make many edits. Good tools often should. The true observation left standing is less glamorous: an approval is not a review, and no amount of confidence formatting changes that.