An Oral History of the Fourteen Minutes You Spent Reviewing 900 Lines of Generated Code

This is satire, and therefore a more accurate incident report than the pull request description. At 10:02 a.m., a developer opened a 900-line generated-code diff. At 10:16 a.m., the diff was approved. Between those events occurred the complete modern code-review lifecycle: triage, reverence for the machine, a brief encounter with a suspicious helper called normalizeNormalizedInput, and the ceremonial transfer of risk to production.

10:02 — The Diff Is Observed

Mara Vellum, staff engineer at the fictional Bureau of Responsible Merge Buttons, remembers the first moment. “I saw 900 lines and immediately knew this was no longer a code review. It was an archaeological survey.”

The pull request was titled feat: improve invoice thing, which was technically true in the way that a weather report reading “outside continues” is true. Its generated summary reported that it added validation, improved error handling, updated tests, reorganized imports, removed dead code, and “made several quality improvements.” The summary did not identify the invoice thing, the error being handled, the tests, the imports, the dead code, or the quality.

Mara began with the command every experienced reviewer uses to establish that the situation is too large to be fixed by vibes:

git diff --shortstat origin/main...HEAD
# 31 files changed, 900 insertions(+), 117 deletions(-)

Git documents --shortstat as the final summary line from --stat: a compact accounting of modified files and added and deleted lines. It does not indicate whether those lines are correct, necessary, duplicate, reachable, licensed, safe, or about invoices. This restraint is one of Git’s more mature design decisions.

10:04 — Context Is Requested, Then Replaced by a Summary

At this point, the team’s agent supplied a second summary. It explained that the change “implements robust invoice workflow support.” Everyone appreciated the word “robust,” because it meant no one would need to ask what the workflow was until an invoice encountered it.

Galen Plork, principal workflow custodian at the invented firm Latchkey Systems, describes the review convention: “We ask the agent for a summary, read the summary, and then treat the diff as corroborating scenery.”

The platform’s review UI recommended looking at changed files one at a time and marking them viewed. This is sound advice for a human-scale change. For generated code, “Viewed” becomes a legally recognized state of consciousness: the file was rendered on a monitor while a reviewer’s eyes were pointed approximately toward it.

10:06 — The First Suspicious Line Is Found

The line was in src/billing/invoice_orchestration_adapter.ts, a filename containing three separate promises that architecture had happened. It read:

const normalizedNormalizedInput = normalizeInput(normalizedInput);

Mara highlighted the line, waited 4.7 seconds, and wrote: “Can we avoid normalizing this twice?” This comment achieved the essential purposes of code review: it demonstrated sentience, created a notification, and gave the authoring agent a task it could complete without asking what the code was for.

Twenty-three seconds later, a new commit appeared. The variable became preparedInput. The call to normalizeInput remained. The agent’s reply began, “Great catch!” No human had caught anything, but the phrase helped restore morale.

10:09 — Tests Are Consulted for Spiritual Reassurance

The PR contained 246 lines of tests, mostly arranged as a dignified procession of mocked functions returning objects with names like mockValidInvoiceWithOptionalMetadataAndPotentiallyAbsentLocale. The tests passed. This established, with the confidence appropriate to a green checkmark, that the generated implementation and the generated expectations had reached an agreement.

Someone opened the CI log. It said 1,842 tests had passed in 2 minutes and 11 seconds. This was excellent news, because no one had time to determine whether the test suite contained an assertion about the business rule that had motivated the change. The organization’s newly minted review policy was clear: automated tests are most valuable when they allow a reviewer to stop reading.

A dependency-review panel noted no dependency changes. This was reassuring, though it had no opinion on the 900 lines of locally generated policy machinery now deciding whether a tax identifier was “provided enough.”

10:12 — Scope Is Carefully Managed

A reviewer noticed that the PR also renamed a utility used by five unrelated modules, altered an error message consumed by a support dashboard, and added a fallback branch that swallowed an exception after logging the phrase unexpected but recoverable. The team correctly classified these as out of scope for the invoice thing.

This was not negligence. It was prioritization. A pull request has a stated purpose, and anything outside that purpose is either harmless refactoring or a separate concern that can be discovered later by the person on call. The reviewer added a final note: “Could we split the cleanup into a follow-up?” The answer was yes, in the same PR, because the cleanup had already been generated and separating it would require thought.

10:15 — Approval Is Prepared

Before pressing Approve, Mara reviewed the generated summary one last time. It now said the PR “improves reliability and maintainability across invoice processing.” This differed from the first summary only by becoming harder to falsify.

She checked the changed-files counter. Thirty-one files. She had deeply reviewed two, skimmed six, collapsed nineteen, and developed a meaningful relationship with the remaining four through the file tree. GitHub’s interface supports comments, suggestions, approvals, and requests for changes; it does not offer the more honest decision state: “I believe this diff has become someone else’s problem.”

10:16 — The Button Is Pressed

The approval comment read: “Looks good overall — left one small note.” It was the closest available encoding of the actual review result: “The system is green, the generated explanation is fluent, I have located one redundant normalization, and I cannot responsibly claim more than that.”

At 10:17, the PR merged. At 10:18, the team celebrated reclaiming 46 minutes that a pre-agent era might have wasted on understanding the code. At 10:19, an engineer opened a follow-up issue titled Investigate invoice edge case. The issue had no reproduction steps, but it did include a screenshot of an invoice.

The joke is not that generated code must be reviewed more slowly than handwritten code. The joke is that volume lets us confuse an approval with comprehension. A review is still useful when it makes one person ask, plainly, what this change does and what happens when it fails.