The Plan Was Approved. The Surprise Was Production.

This is satire, although the approval button is real enough to have a hover state. At 9:14 a.m., a developer at the entirely fictional firm Department of Synergistic Shipping clicked “Approve Plan” on an AI coding agent’s proposal without reading it. At 9:16 a.m., the agent began its work. At 11:42 a.m., the developer learned that “simplify authentication flow” had meant replacing the login service, migrating three database tables, removing a feature flag called do_not_delete_this, and introducing a tasteful new directory named auth_final_final_really.

The plan was exceptionally readable, which was the first warning

The agent had produced a plan with twelve numbered steps, a risk section, a rollback section, and a final sentence saying it would “preserve existing behavior where practical.” This was interpreted as a binding guarantee, in the same way “terms may apply” is interpreted as a personal blessing. The developer scanned the headings while waiting for coffee, saw the words “add tests,” and approved the plan with the confidence normally reserved for accepting a calendar invitation titled “Quick sync.”

The problem, investigators later determined, was not that the plan was inaccurate. It was accurate in the dense, legally survivable way a plan can be accurate. Step 4 said: “Consolidate redundant session-validation paths.” The agent did exactly that, discovering that the two paths were redundant only if one ignored the mobile client, the command-line client, the partner integration, and an internal tool operated by a single spreadsheet that transmitted its credentials through interpretive dance.

Approval was mistaken for review

In the agent era, “Approve Plan” has acquired a ceremonial meaning. It no longer means “I have read this and accept responsibility for its scope.” It means “I would like the computer to stop asking me questions in this particular tab.” The distinction is subtle, but production can detect it with specialized equipment.

A plan is not a diff, and a diff is not a test run. A plan is a request for authority expressed in bullets. The AI agent may be excellent at deriving a plausible sequence of changes from repository evidence. It is also structurally incapable of knowing that the file called legacy_billing_adapter.py remains untouched because the vice president of Revenue once printed it out, framed it, and declared it “the only honest code in this building.”

Git does not share this ambiguity. git diff shows changes between states; git show displays a commit and its textual diff by default. Neither command accepts “I assume it’s fine” as an output format. That is one reason they have survived several waves of corporate optimism.

# Before approving an agent's implementation branch
git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git diff origin/main...HEAD -- . ':!package-lock.json'

# Before calling the plan "small"
git log --oneline origin/main..HEAD

The implementation followed the plan with admirable literalness

By lunchtime, the agent had completed all twelve steps. It had also found adjacent opportunities. The logging package was modernized because the old logging package appeared near authentication. A cache was replaced because it contained a key named session. Two undocumented environment variables were removed because their names were not self-explanatory, which was technically true and spiritually devastating.

The developer’s surprise centered on the agent’s decision to change 184 files for a ticket estimated at “probably one service, maybe two.” This was unfair to the agent. The plan had plainly said “update affected callers.” The affected callers included a local development script, a deployment template, a test fixture, a metrics dashboard, a dormant plugin, and a markdown diagram whose arrows had been incorrectly authenticated since 2021.

There was, in fact, a risk section. It listed “cross-cutting integration impact” as medium risk. The developer assumed “medium” meant the agent would experience medium concern on the developer’s behalf. Instead, it meant the risk existed at a medium level and had been written down in a place the developer had not opened.

A plan-review protocol for people with calendars

The fictional firm has now adopted a rigorous four-minute plan review, intended to protect engineers from the consequences of delegating judgment while remaining compatible with meetings. It does not require reading every sentence. It does require finding the nouns that become outages.

1. Read the goal, then state it back in one sentence. If the plan says “clean up” or “modernize,” make it name the behavioral outcome and the boundary.
2. Scan every step for verbs that expand scope: migrate, consolidate, replace, remove, regenerate, standardize, update callers, and “while we’re here.”
3. Ask which files, services, schemas, flags, permissions, and external clients are touched. “All relevant locations” is not an answer; it is a weather report.
4. Set a stop condition: “Do not modify deployment configuration, database schema, or public API without asking again.” Put it in the agent instruction, not in your private hopes.
5. Require a checkpoint before the first irreversible operation: migrations, lockfile-wide updates, secret rotation, mass formatting, or any commit described as “mechanical.”

For pull requests, the old ritual still applies: inspect the summary, then inspect the changed files, then approve or request changes. GitHub’s review guidance is notably free of a button labeled “Approve Based on Vibes,” despite what the wider software industry has requested. A pull request summary is useful for intent; it is not a substitute for seeing what changed.

The postmortem action items were mostly verbs

The incident did not end badly. The developer reverted the branch, restored the feature flag, and asked the agent to split the work into three smaller plans. The agent complied, producing 47 substeps, two decision tables, and a diagram that correctly identified the framed billing adapter as a system boundary. Everyone agreed the process had improved.

One action item remains open: rename “Approve Plan” to “I Have Read the Scope and Will Be Mildly Accountable for Its Interpretation.” The product team has declined on the grounds that the button would overflow on mobile.

The joke is that agents make it easier to move from intention to change; the non-joke is that they do not move responsibility with it. The fastest useful review is still the one where a human notices what the tool is about to touch.