Looks right is the most expensive phrase in an AI code review

A staff engineer at an insurance company noticed a pattern in his team’s reviews after they started using an agent heavily. The comments got shorter. Where reviewers used to leave a dozen questions on a nontrivial change, they were leaving two, and often the two were style nits. The code was not simpler. If anything it was denser. What had changed was the tone of it. The agent’s output read like it had been written by a careful senior engineer, and that confidence was doing something to the reviewers. They kept typing “looks right” and moving on.

Fluency is not correctness, and the brain confuses them

Humans use surface signals to judge trustworthiness, and code is no exception. Clear names, consistent structure, a tidy shape on the page, all of it reads as competence, and we extend competence the benefit of the doubt. When a junior engineer wrote clumsy code, the mess itself was a signal to look closer. The clumsiness kept reviewers honest.

Agent-generated code removes that signal. It is fluent by default. The names are sensible, the formatting is clean, the structure follows familiar patterns. A reviewer’s guard drops precisely because the code looks like the work of someone who knew what they were doing. But fluency and correctness are different things. A model can produce a beautifully organized function that handles the wrong edge case, calls an API with a subtle mistake, or solves a slightly different problem than the ticket asked for. The prose is perfect. The logic is off. And the polish is actively working against the reviewer, because it whispers that there is nothing to find here.

This is worse than sloppy code, in one specific way. Sloppy code announces that it needs scrutiny. Fluent wrong code hides that it needs any. The reviewer who would have grilled a messy pull request waves through a clean one, and the clean one had the bug.

Raise your guard when the code looks its best

The lesson is uncomfortable because it runs against instinct. The cleaner an AI-generated change looks, the more deliberately you have to check its logic, because the appearance is telling you nothing about whether it is correct. Reviewers have to learn to distrust their own sense of “this looks fine.”

Habits that keep reviewers skeptical of fluent code.

Review against the requirement, not the appearance, and confirm the change does what the ticket asked, not just that it reads well.
Trace the logic on the parts that matter, especially edge cases, error handling, and boundary conditions, where fluent code hides its mistakes.
Treat clean structure as neutral information, not as evidence of correctness, and spend your attention on behavior.
Ask what the change does when the input is wrong, empty, or hostile, because agents optimize for the happy path they were shown.
Keep review depth constant regardless of how confident the code looks, so polish stops buying a lighter review.

The point is to stop letting the surface set the depth of the review. The depth should come from what the code does, and the code does not get easier to check because it got easier to read.

How we think about it at Density Labs

The teams that get burned by AI-assisted code are rarely burned by obviously bad output. They are burned by output that looked right, passed review because it looked right, and turned out to be wrong in a way the polish concealed. The tool got better at looking competent faster than the review process adapted to distrust the look.

When we help a team build an AI-assisted workflow, we spend real time on what review means now that the code arrives pre-polished. The reviewer’s job shifted. It used to include catching the mess. Now it is almost entirely about catching the confident mistake, which is harder, because the code is no longer wearing its problems on the surface.

Clean code used to be a reason to relax. With an agent in the loop, it is a reason to look harder.