When AI Makes the Wrong Design Look Ready

Slower Implementation Would Have Made Me Ask Earlier

Before coding agents, I probably would have talked to the team that owned the timestamp well before writing the change. Understanding the repository well enough to find both candidate sources would have taken an hour or two. At that point, asking someone who knew the system about the timestamp would have been cheaper than continuing to dig.

With the agent, I had it make a plan, and then the implementation took minutes. I spent about half an hour reading the diff and making edits, then sent it to reviewers. I had checked what the code did, but I had not traced why the agent had made each choice.

The speed of agent-generated code changes how design decisions arrive. When writing code by hand, they tend to appear one at a time as the implementation runs into ambiguity. Each question creates a chance to stop and resolve it before continuing. An agent can choose a path through several ambiguities in minutes and return those answers implicitly inside one coherent diff.

The finished code gave me several choices to evaluate at once. I had to work backward from the code to find where the agent had encountered ambiguity, then decide whether the agent had enough information to choose. Some of those decision points were absent from its explanation because the agent had treated them as ordinary implementation details.

That is what happened with the timestamp source. The missing contract was already there, but the final code made one interpretation look settled before I had asked what the producer promised.

Plan mode seems like the obvious way to restore the missing pause. It helps by exposing the approach before implementation, but it surfaces only the choices the agent recognizes as choices. In my case, the plan the agent produced specified the filename and configuration fallback without asking whether either source was guaranteed.

Some choices become visible only after implementation produces more evidence. Types, tests, failure paths, and operating conditions can change what the next decision requires. Several decisions made before coding are therefore not equivalent to the same decisions made as that evidence emerges.

The plan also made that assumption feel more deliberate than it was. It presented the filename as an implementation step, so I read the choice as settled instead of as a question for the producing team.

A Diff Hides the Questions Behind the Choices

A diff records the choices that became code. It rarely records the questions that produced them.

Take a fallback added when an operation fails. In the diff, it may look like a one-line decision about what to return. Reviewing that line requires asking what else the fallback commits the system to. Should its use be logged? If repeated use indicates a degraded state, should the code emit a metric? Should that metric trigger an alarm? Who would own the response? Or should the operation fail instead?

The answers determine both failure behavior and operational responsibility. They depend on whether the fallback is normal behavior or a condition someone needs to notice. Yet the diff may show only a reasonable-looking fallback.

In my pull request, the diff showed why CI used the filename and local runs used configuration. It did not show whether the filename format was guaranteed. That answer required knowledge from another team.

Review then becomes an exercise in reconstruction. Someone must infer the decisions from the diff and decide whether the repository contains enough evidence to validate them. When it does not, the code needs a wider conversation.

Reviewers Inherit the Discovery Work

Code review has always done more than find defects. In a study of code review at Microsoft, Alberto Bacchelli and Christian Bird found that reviews were “less about defects than expected.” Developers described finding defects as the goal, but reviews also produced knowledge transfer, team awareness, and alternative solutions. The study also found that understanding the code and the change was central to review and that developers met that need mostly outside their tools.

AI changes when and how much of that work reaches reviewers. An author can arrive at review before working through each design question, so the unresolved questions appear together and without the context that would have accumulated while coding by hand.

The reviewer has to verify the behavior while checking assumptions (that may depend on contracts outside the repository). That is a heavier review even when the diff is small.

The reviewers' confusion signaled that a cross-team conversation had been skipped. By then, the pull request was open and they had spent time reconstructing a decision I should have resolved before review.

Authors Need More Than One Decision Checkpoint

Reviewers should validate design decisions without being responsible for discovering all of them. Before opening an AI-assisted pull request, the author needs to review what the agent decided as carefully as what it changed.

That requires checkpoints across the change. Before coding begins, I ask what is ambiguous and which external contracts the approach assumes. During implementation, I compare the code with the plan and ask what the agent learned or decided along the way. Before review, I separate the choices supported by evidence in the repository from those that need agreement from another person or team.

No set of prompts will expose every hidden assumption. The author still has to notice when a local-looking choice requires knowledge the code cannot supply. My reviewers noticed this one before I did.

So to finish the anecdote that I introduced in the beginning, the pull request never shipped. The reviewer's question was the most useful thing that came from it:

What does the producing system guarantee?

I should have asked it before I started coding.