Local Engineer Insists Plan Mode Is for People Who Lack Confidence

This is satire, although the incident report it resembles has been printed on responsibly weighted paper. At 9:02 a.m., local engineer Darius Rook announced in the #delivery channel that Plan Mode was “for people who lack confidence.” At 9:03, he opened an AI coding agent, pasted “make auth more scalable,” and selected Act Mode with the calm expression of a man authorizing a bridge demolition from a rental car.

Rook works at the fictional software concern Stonecrop Ledgerworks, where every ticket begins as a sentence written by someone who was interrupted halfway through another sentence. The ticket in question read: “Support enterprise session stuff, should be easy.” It had no acceptance criteria, no linked design, and a comment from four months earlier saying “waiting on product” beneath a GIF of a pelican collecting a sandwich.

Plan Mode, Rook explained, creates an unacceptable pause between impulse and file mutation. “If I need to read the repository before changing it,” he said to nobody in particular, “then the repository has already won.” He clicked Allow on the agent’s request to inspect the authentication package, the billing package, the deployment manifests, and a directory named old_old_do_not_use that had been created in 2021 by an engineer who meant it.

The confidence workflow

Rook’s workflow is admirably simple. It has three stages: ask the agent to solve the vague problem, approve the commands while scrolling at a speed that conveys governance, and interpret any failing test as evidence that the test has become emotionally attached to the past.

# Step 1: establish intent
agent "make auth more scalable"

# Step 2: preserve momentum
Yes
Yes
Yes
Yes

# Step 3: discover architecture
git diff --stat HEAD
git diff HEAD -- services/auth packages/billing infra/

The final two commands are known internally as the Archaeology Phase. Git’s documentation confirms that git diff HEAD compares the working tree against the current commit; at Stonecrop, this is most useful after the working tree has become an unsolicited proposal for a new organization chart. The --stat output gives Rook the managerial overview he declined to obtain before the agent edited 47 files.

By 9:11, the agent had replaced a cookie-session adapter with a token abstraction, extracted a provider interface, added a cache, removed a cache after encountering a type error, added environment variables to two deployment files, and edited a fixture whose only job was to make a 2019 regression test look older than it felt. The proposed pull request title was: “Improve auth scalability and fix related issues.” This was technically accurate in the way a weather alert is technically accurate when it says “conditions may occur.”

The plan he did not need

A Plan Mode user, according to Rook, would have wasted perhaps 90 seconds asking questions such as: Which session behavior is actually failing? Is the enterprise requirement concurrency, auditability, longer expiry, SSO, or a sales slide? Which callers depend on the current cookie shape? Does “scalable” mean database load, operational support, or the ability to say “horizontal” during a roadmap meeting?

These questions are dangerous because they can produce answers. Answers create constraints. Constraints reduce the available surface area for the kind of implementation that changes enough files to feel proportional to the seriousness of the request.

1. Read the ticket and linked issue, if either contains nouns.
2. Ask the agent for a plan naming files, assumptions, risks, and validation commands.
3. Reject any plan that calls the requirement ambiguous; ambiguity is an insult to confidence.
4. Run the plan anyway, but refer to it as “pre-execution alignment” so nobody mistakes you for a planner.
5. When the change reaches 1,200 lines, announce that the original task had hidden complexity.

Rook’s objection is not entirely irrational. Plans can be bad. An agent can write a polished five-part plan that identifies every directory except the one containing the actual bug. It can propose a migration because it has detected a database somewhere in the repository. It can spend longer enumerating risks than the fix requires. For a typo, a one-line null guard, or a tightly scoped test repair, planning can be overhead disguised as ceremony.

But Rook applies this insight to changes involving authentication, shared data contracts, payments, deployment settings, and the phrase “while you’re in there.” This is like noticing that a seatbelt delays exiting a parked car and concluding that seatbelts are mainly for people with low self-esteem.

The deployment of confidence

At 10:04, CI failed for reasons unrelated to the ticket but strongly related to the changes. At 10:17, a reviewer asked why the pull request modified billing. At 10:19, Rook explained that the billing change was necessary because the new auth abstraction was “cleaner.” At 10:26, someone located a feature flag that already solved most of the enterprise requirement. It had been off because nobody had confirmed the customer’s tenant configuration.

The final patch changed two lines: one configuration value and one test expectation. The original 47-file diff was closed with the reassuring label “superseded.” Rook described the outcome as validation of his iterative method. This was accepted because the meeting had reached minute 43 and everyone wanted lunch.

Plan Mode is not courage. It does not make an agent understand your system, rescue a bad requirement, or prevent a tool from confidently rearranging a subsystem it only encountered 14 seconds ago. It is merely a cheap moment in which assumptions become visible before they become diff hunks. The true observation, stubbornly surviving the satire, is that confidence is useful after you know what you are changing.