A pull request got approved in under two minutes a few weeks back. Late afternoon, the kind of PR that shows up in a Slack notification while you're already thinking about the next thing. Fourteen files, a retry wrapper around an HTTP client, a small refactor to an error handler, one new dependency. Clean diff, clear commit message, thumbs up, done.

Nobody in that exchange could have told you why the backoff strategy was shaped the way it was, or why that particular dependency won out over three others that do roughly the same job. The code was AI-generated, lightly prompted, quickly accepted. It looked like every other PR that reviewer had approved that week. Nothing about it said: ask more questions here.

That's the part I think gets underweighted in most of the AI-assisted-development conversation. It's not that the model writes bad code. Most of the time it doesn't. The problem is that reasonable-looking code is exactly what code review was never built to catch.

What the diff actually looked like

It's worth seeing this concretely instead of taking my word for it, so here's a version of that retry wrapper, close enough to the real thing to make the point without being the real thing.

python

def fetch_with_retry(url, max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return http_client.get(url, timeout=5)
        except TransientError:
            if attempt == max_attempts - 1:
                raise
            time.sleep(2 ** attempt + random.uniform(0, 1))

Read it top to bottom and it looks like exactly what it claims to be. Exponential backoff, a little jitter so retries from a fleet of clients don't all land in the same instant, a sane cap on attempts. A reviewer glancing at this has every reason to approve it. It's a textbook implementation of a well-known pattern.

Here's what the diff doesn't tell you. Why three attempts and not five. Why a five-second timeout instead of the two-second timeout used everywhere else in that same service. Whether TransientError actually covers the failure mode this endpoint tends to produce in practice, or whether it's the exception class the model reached for because it sounded right. None of that is wrong, exactly. It's just unknown, to the reviewer and often to the developer who accepted the suggestion, and the code gives no sign that it's unknown. A hand-written version of the same function, from a developer who'd been paged at 2 a.m. for this exact endpoint timing out, would probably look almost identical and mean something completely different.

That gap, between code that's correct and code that's understood, doesn't show up as a diff. It shows up eight months later, when the retry logic behaves strangely under a load pattern nobody tested for, and the person debugging it goes looking for the reasoning behind the five-second timeout and finds nothing, because there wasn't any reasoning to find. There was a plausible-sounding number.

What an approval used to mean

Code review isn't really a syntax check, that's what linters are for. It exists to catch the stuff a machine can't evaluate: is this the right approach, does the person who wrote it actually understand the tradeoff they just made. The whole thing rests on there being an author who could answer "why this way" with a real reason, and a reviewer whose approval means something like I looked closely enough to vouch for this.

On the platform security side, this was so basic nobody ever wrote it down. Of course there was an author. Of course a name was attached to the review, and that name meant something if the change caused a problem later.

AI-assisted development doesn't delete the author field. It just empties out what used to sit behind it. The name's still there. The understanding behind it isn't, not unless somebody went out of their way to capture it, which mostly nobody does.

The part a diff can't show you

A developer accepts a suggestion, doesn't trace all the way through why it works, ships it as their own change, because that's the workflow. There's no box on a pull request for "I skimmed this one." The diff reads identically whether the author read every line three times or clicked accept once and moved on to the next tab.

A reviewer approving that PR isn't doing anything wrong. They had three other tabs open, a stand-up in twenty minutes, and a diff that read cleanly top to bottom. They looked at what was in front of them and it held up. But the approval means something quieter than it used to. It used to say a person who understood this vouches for it. More and more it says a person looked at model output and it seemed plausible. Those aren't the same claim, and the pull request format has no way to tell you which one you're getting, because it was never designed to distinguish between them.

Two things that would actually help

More review isn't the fix. A tired reviewer approving faster doesn't get more careful because you bolted on a second required sign-off, and piling process onto a mechanism that's already blind to what changed just slows everyone down without closing anything.

What would help is making the artifact carry information it currently drops on the floor.

First, provenance at the moment code is generated. When something comes from an AI assistant, that fact, plus what was asked for and what context the model had, should travel with the change instead of vanishing the second the developer hits accept. Not to shame anyone. Just useful metadata. Six months from now, when something breaks, "what was this actually asked to do" is exactly the question an investigation wants answered, and right now there's no record of it anywhere.

Second, a review record that says what was actually reviewed. An approval on a fourteen-file PR currently means the same thing whether the reviewer read every line or skimmed the summary and trusted the tests. It shouldn't have to. Even a rough distinction, "traced through the backoff logic and understand it" versus "tests passed, nothing jumped out", gives a future reader something to work with instead of one flat checkmark standing in for both.

Neither is a huge lift next to what teams already build for CI. The harder part is admitting, out loud, that a lot of current review already looks more like the second kind of approval than the first, and that pretending otherwise doesn't make the risk smaller.

Where this actually sits right now

Most teams using AI coding assistants today haven't done either of these two things. The pull requests moving through their pipelines look exactly as trustworthy as they did a year ago, because the format hasn't changed, even though what's sitting behind it has.

That gap keeps closing quietly, one clean diff at a time. Somebody's going to notice it eventually, either because a team decides to change what a review record actually claims, or because an incident makes the decision for them. I know which one I'd rather write about next.