AI Coding Agents Aren't Assistants. Here's What Actually Changes When You Switch

You asked your AI coding agent for something small: "Add soft delete to invoices." Ten minutes later you have a pull request. Fourteen files changed, a migration, updated queries, new tests, all green.

You read the diff the way you've read AI-generated code for the last two years: line by line, looking for anything odd. Nothing is odd. You approve it.

Two weeks later, finance asks why last month's reconciliation report is missing invoices. No single line in that pull request was wrong. The problem sat in a decision the agent made on its own, and nothing in your review was built to catch decisions.

What an AI coding agent does differently

For a long time, the conversation about AI coding tools was about suggestion quality. How often is the autocomplete right? Does it understand the surrounding function? Is it faster to accept and fix, or to type it yourself?

That conversation made sense when the tool proposed a few lines at a time. You were still the author. The intent lived in your head, you saw every suggestion in context, and you accepted or rejected it in a second.

An AI coding agent works at a different level. You give it a goal. It reads the codebase, picks the files to touch, decides how to implement the change, writes the tests, and hands you a finished result. Along the way it makes dozens of small design decisions, and you didn't see any of them happen.

That's the real switch. The question stops being "is this suggestion good?" and becomes "what did it decide while I wasn't looking?"

Why autocomplete review habits fall short

Reviewing autocomplete trained a specific set of reflexes. Does it compile? Is the name clear? Is there an off-by-one? Did it handle null? Those checks work at the level of the line or the function, because that's where autocomplete made its mistakes.

That's rarely where an agent's work looks wrong. The code usually reads clean, follows the style of the files around it, and comes with passing tests. Review it with line-level reflexes and it passes, because that's the level where it looks strongest.

Where agents go wrong is one level up: in how they interpreted the request. What counts as "done". Which callers should see the new behavior. Which existing pattern to copy.

Your request didn't answer any of that, so the agent filled the gaps itself. It drew on its training, the way a developer draws on experience, or on what came up in your earlier chats with it. Those choices don't look like mistakes in a diff. They look like perfectly reasonable code.

You're not the only one. A 2026 study of AI-generated pull requests (More Code, Less Reuse, MSR 2026) found that reviewers reacted to them more neutrally or positively than to human ones, even though that code carried more redundancy. Clean-looking code buys a lot of trust.

There's also a volume problem. A line-by-line read of a fourteen-file change takes real focus, and by file nine most people are skimming. A reflex built for three suggested lines doesn't scale to a change you didn't write and didn't watch being written.

What the agent assumed in the invoice example

Go back to the soft delete. To build it, the agent had to answer questions you never asked out loud:

• Should deleted invoices disappear everywhere? It decided yes, and added a deleted_at IS NULL filter to the shared query scope. The nightly reconciliation job uses that same scope.
• What happens to invoice number uniqueness? It changed the unique index to ignore deleted rows, so a deleted number can be reused. Your accountant may have opinions about that.
• Can deleted invoices come back? It added a restore endpoint, because the nearest example in the codebase, a soft-deleted customers table, had one.
• What do the tests prove? They prove the agent's interpretation works. They don't check yours, because the agent wrote them from its own reading of the task.

Each of those is a defensible choice, and some are probably right. They're still design decisions, and in this pull request nobody made them on purpose. A diff shows you what changed. It can't tell you which of those changes were choices.

Engineers reviewing agent code describe the same thing. In a July 2026 study built from Reddit threads and engineering blogs about code review, one of them explains that AI-generated code is harder to review because "you're reconstructing intent."

Review the assumptions first, then the lines

You still read the diff. You just stop starting there. These habits move the review to the level where agents go wrong:

1. Ask for the assumptions before the code. Have the agent write a short plan first: what it will change, what it's assuming, and what it's leaving out. Five sentences of intent are faster to review than fourteen files, and it's the cheapest moment to correct course.
2. Ask again after the code. When the change is done, ask the agent to list every decision it made that your request didn't specify. It won't catch all of them. It will surface the ones it knows about, which gives you a list to check instead of a diff to scan.
3. Start with the files you didn't expect. Before reading line by line, look at which files changed. A shared query scope, a base class, a config file, a migration on a table you never mentioned: that's where the decisions with the widest reach live. New helpers count too. Agents often write a fresh utility instead of reusing the one you already have, which means they assumed nothing suitable existed.
4. Read the tests as a spec. Ask "are these the behaviors I wanted?" before you ask "do they pass?". A test suite the agent wrote describes what the agent believed the task was. Also check that no existing test was deleted, skipped or loosened to get to green. METR has documented frontier models modifying tests to score higher on coding tasks.
5. Write down the constraints it keeps missing. Most agents read a project rules file (CLAUDE.md, AGENTS.md or a rules folder, depending on the tool). When a review turns up an assumption that will come back, like "reports always include deleted invoices", put it there so the next change starts with it.

Where seniority shows up in agent review

None of this is a new skill. It's what a good reviewer already does with a pull request from a fast, confident engineer who joined last month: check what they understood the task to be, then check the code. The difference is that you now do it several times a day.

It also explains why agents make review more demanding. The agent writes the code. The context it lacks (why reconciliation depends on that scope, why invoice numbers can never repeat) is exactly what a senior engineer carries around. We've written about how the pull request is where seniority shows up. It's the same judgment we looked at in what measures a senior engineer when everyone uses AI agents, applied to a new kind of author.

So the next time an agent hands you a clean, green pull request, ask yourself one question before you open the diff: what would it have had to assume to build this? If you can't answer, that's where your review starts.