The Approval Button Isn’t a Code Review

Key takeaways

• A plan explains the intended change; the implementation still needs checking.
• A readable plan can leave out critical permissions and failure conditions.
• Useful plans define questions that guide both implementation and verification.
• Understanding a change means being able to explain its behavior, risks, and recovery options.

An AI coding agent proposes a sensible plan. You click Approve, and it gets to work—but how much of the eventual result have you actually understood? That gap determines whether plan mode helps you make better decisions or simply gives you another button to press.

A plan establishes intent

Plan mode gives an agent a chance to explain its approach before changing code. It is a useful place to catch a mismatch: you asked for a cleaner login screen, and the agent is preparing to redesign authentication. A small difference in enthusiasm.

Reviewing the plan also lets you challenge assumptions and spot things the agent has not checked.

What you have reviewed at that point is implementation intent. The actual code determines which data gets read, which rules get enforced, and what happens when something fails.

Consider a promise to “add error handling.” It sounds reasonable. It also leaves plenty unresolved. Which errors will be caught? What will users see? Can a failed operation safely be retried?

Agreeing with that sentence does not settle those decisions. Its readability can make the missing detail easy to overlook.

Five minutes of caching, one missing permissions check

Suppose an agent is adding caching to a service that searches internal team documents. Its plan says:

Cache results for the same search query for five minutes to improve response times.

Clear enough. Reusing a saved result avoids repeating work.

But whose result gets reused?

If different teams can access different documents, identical queries should return different results. A cache key, the identifier used to retrieve a saved result, must account for those access boundaries. Using only the query risks serving one team’s results to another.

Adding a team identifier might still be insufficient. Two people on the same team may have different document permissions.

Then there is revocation. Someone loses access to a document, but the cache still holds their earlier search results. A five-minute expiration does not, by itself, solve that problem. The system still needs a rule for what happens after access changes.

Understanding this plan means being able to explain whose results can safely be shown to whom. “Caching makes search faster” gets you only partway there.

Turn promises into questions you can test

A longer plan can spell out more conditions. Length alone cannot establish that the important ones are covered—or that the code will implement them correctly.

A more useful review turns each promise into a question with a checkable answer.

For the search cache:

• When users from different teams run the same query, does each receive only documents they can access?
• What happens to cached results when a user’s permissions change?
• Does search still work when the cache is unavailable?

Before implementation, these questions help define the requirements. After implementation, they guide code review and testing. The same questions connect the proposed behavior to evidence from the finished system.

The agent can write the tests, too. But if it missed a permissions requirement while planning, it may miss that requirement again while testing. A passing test suite tells you about the situations it actually exercises.

Reviewing test coverage of the requirements matters as much as seeing a green checkmark. In this example, you want evidence that access boundaries were tested, not just that a repeated query returns a cached response.

Read deeply where the consequences demand it

Reading every line of an agent’s work can eat into the benefit of delegating it. Reading only the plan leaves important questions unanswered.

A practical standard is whether you can explain the consequential behavior. What changed? Under which conditions could it fail? How would you undo the change if something went wrong?

If you get stuck explaining one of those points, that is where to inspect the code and verification results more closely.

The depth of review should follow the stakes. Changing a button label and changing document permissions deserve different amounts of scrutiny. Higher-impact changes need more explicit conditions and stronger evidence that those conditions hold.

Plan mode remains useful when it helps people connect an intended change to its actual behavior. Before approving, ask both whether the approach makes sense and what evidence would reveal that it went wrong. A good plan should help you answer the second question.