Your AI just changed 14 files. Now what?

Code review was designed around a unit of work that barely exists anymore: the pull request, assembled by one person, at human speed, small enough for another person to hold in their head.

The work doesn't arrive like that now. It arrives one prompt at a time. You describe a feature, an agent touches fourteen files, and the only human checkpoint between "the model finished" and "this is in the commit history" is you, squinting at a diff, deciding how carefully you feel like reading today.

That checkpoint is where quality now lives or dies, and almost no tooling exists for it.

The unit of review changed. The tooling didn't.

Everything in the review stack assumes the PR is where scrutiny happens. Linters check the file you have open. CI runs after you push. Human review happens after the branch is up, when the commit history is already written and the author has mentally moved on to the next ticket.

That stack made sense when the person writing the code was also the checkpoint - you understood each change as you typed it, so the PR was a second look rather than a first one.

An agent inverts that entirely. It writes the first draft of fourteen files, and your read of the diff is the first time any human has thought about that code at all. The PR review that happens two days later is the second look, performed by someone with even less context than you had when you were scrolling through it.

The review that matters most has quietly moved from the PR to the moment before you commit, and at that moment the tooling offers you exactly one instrument: git diff and your own eyes.

git diff is not a review tool

A diff shows you what changed without having any opinion about what's wrong, and the distance between those two jobs gets expensive at agent speed.

You know how this actually goes. The agent finishes. You scroll. The types line up, the names are sensible, the structure looks like code you'd write. Somewhere around file nine you've stopped reading and started pattern-matching, because attention doesn't scale with output volume and the output volume just went up 10x. We wrote about that failure mode in the slopification piece - plausible-looking code is precisely the kind that human scanning approves without friction.

But there's a sharper problem hiding in the mechanics that nobody talks about: git diff doesn't show untracked files.

Agents create files constantly - a new helper module, a config, a quick script. When the model needs somewhere to put a connection string, a brand-new file is exactly where it goes. And here's what that looks like from the perspective of the one tool you're relying on to review the changes:

$ git diff --stat
 src/routes/api/users.ts      | 24 +++++++++---
 src/middleware/auth.ts        | 11 +++--
 src/lib/query_builder.ts     |  8 ++--
 3 files changed, 31 insertions(+), 12 deletions(-)

$ git status
 modified:   src/routes/api/users.ts
 modified:   src/middleware/auth.ts
 modified:   src/lib/query_builder.ts

Untracked files:
  src/lib/db_config.ts
  src/scripts/seed_admin.ts

Your diff reviewed three files. Your working directory contains five. The two files the agent created - the ones most likely to contain hardcoded credentials, default admin passwords, or connection strings the model pulled from its training data - are the two files your diff never mentioned.

Here's what's sitting in one of them:

// src/lib/db_config.ts - created by the agent, never shown in your diff
export const DB_CONFIG = {
  host: 'db.internal.prod',
  port: 5432,
  user: 'admin',
  password: 'pg_7Hx2mKl9vQ4w',
  database: 'app_production',
}

And in the other:

// src/scripts/seed_admin.ts - also untracked, also invisible to git diff
import {DB_CONFIG} from '../lib/db_config'

async function seedAdmin() {
  await db.query(
    `INSERT INTO users (email, password_hash, role) 
     VALUES ('admin@company.com', '${DB_CONFIG.password}', 'superadmin')`,
  )
}

Two untracked files, two hardcoded secrets, and a SQL injection for good measure. None of it appeared in git diff. All of it would have landed in the commit the moment you ran git add ., which is typically the same keystroke session as the commit itself. The category of file that received the least human attention gets the least tooling visibility, right when it's about to become permanent.

And a secret that lands in even one commit is leaked, full stop. Deleting it in the next commit removes it from the tree but not from the history. What would have been a ten-second fix before committing becomes a history rewrite and a credential rotation after.

"Slow down and read every file" is not a system

The obvious answer is discipline: review all fourteen files properly, every time, the way you would a colleague's PR.

Count what that costs. A conscientious PR review runs maybe ten minutes per file for code you've never seen before. Fourteen files is over two hours of focused reading for one prompt's worth of output, from a tool you adopted specifically to move faster. Nobody does this, and nobody is going to do this, because the economics of the tool forbid it. Pretending otherwise is how teams end up with a review standard that exists in the wiki and nowhere else.

The other answer is "CI will catch it." CI is twenty minutes away, three pushes deep, and by the time it fails you've already built two more changes on top of the broken one. CI is a fine last line of defence, but as the only line it means your feedback loop for machine-generated code is slower than the generation loop by two orders of magnitude.

What's missing is a checkpoint that sits exactly where the decision actually gets made: after the agent writes, before you commit. Vigilance can't fill that gap because vigilance is a human resource with a half-life measured in minutes, and CI can't fill it because CI runs after the code is already in history.

What the missing checkpoint looks like

It doesn't need to be clever - it needs to be structural, something that runs on the changed set every time regardless of whether you're paying close attention that afternoon. Four properties matter:

Scoped to what changed. Not a whole-repo scan you'll skip because it's slow, but the staged files, the unstaged edits, and - critically - the untracked files your diff never showed you.

Ordered by severity, not by file. A hardcoded production password and a stray console.log are not peers. Blockers first, so the thing that must not ship is the first thing on screen instead of buried under style noise in file eleven.

Local and immediate. The loop only works if the check is faster than the temptation to skip it. Seconds, on your machine, with no code leaving it.

Anchored to lines. A finding you can click straight into is a fix you'll make in thirty seconds, while a finding buried in a report is a chore you'll get to later, which means never.

This is what Review My Changes in Iris Code does. Git reports local changes, a strip appears above the sidebar with the count, and one click runs the analysis on exactly those files - staged, unstaged, and untracked. The review opens with blockers at the top: secrets, security smells, then complexity and the rest, each pinned to the line it lives on. It runs entirely locally, it's free, and it's deliberately honest about scope - a change review checks your changes rather than pretending fourteen files can tell you the health of the whole repository.

The goal isn't to slow the agent down. The goal is that the checkpoint the PR used to provide has moved into your editor, and something should actually be standing there when the agent finishes and you're about to commit.

The PR was never the sacred part of code review - it was just where the checkpoint happened to sit when humans wrote everything by hand. The work moved, so the checkpoint has to move with it, to the ninety seconds after the agent says "done" and before you type git commit.

That's the review that matters now, and it might as well be one click.

Originally published on the Iris Code blog.

Iris Code scores your code for security smells, complexity, and secrets on every save - right in your editor, fully offline. Try it free.