If your team has adopted coding agents, you've probably noticed that you don't enjoy code review the way you used to, and you might not have a clean explanation for why. Reviewing a 2,000-line pull request a model wrote in four minutes feels like a chore. The work looks identical from the outside. Something about it is different anyway.
I think the difference is that peer review was always doing two jobs at once, and we only ever talked about one of them. The job we talked about was catching mistakes before they reached production. The job we didn't talk about, because it was so woven into the first one that it never needed a name, was learning. Review was where juniors got better and seniors stayed honest. It was the disagreement that turned into a better design, the question in a comment thread that taught you something you've used a hundred times since, the design doc a staff engineer read line by line even though it wasn't their project.
When the author of the code is an agent, the first job survives and the second one quietly disappears. You can still catch the mistakes. But the agent doesn't get better from your feedback. It doesn't carry what you said about this pull request into the next one. It's exactly as good, and exactly as bad, tomorrow as it is today. You can write it better instructions, and that's real work worth doing, but it isn't the loop where two people both come out smarter. That loop is just gone, while we were busy being faster.
The part nobody has a good answer to
The part that actually worries me goes further than the agent not learning. The agent took over the exact activity where the humans used to.
Think about how a junior engineer actually got good. Not the courses or the docs. They got good by putting up work and having someone more experienced push back on it, and by reading more experienced people's work and seeing choices they wouldn't have made. The review queue was the classroom. It was disguised as quality control, but most of the teaching happened there: in the margins of a diff, in a "why did you do it this way and not that way", in the slightly uncomfortable thread where a senior disagreed and you ended up changing your mind.
Now the diff is written by an agent. The junior isn't authoring the thing that gets reviewed, and increasingly isn't the one reviewing it either, because auditing a machine's output is a worse classroom than being mentored by a person who cared whether you understood. So if review is no longer where juniors learn, where do they?
I don't think the industry has a real answer to that yet. I don't fully have one either, and I'd be suspicious of anyone who claims they've solved it. But I can tell you the closest thing we've found.
What's worked for us so far
We stopped reviewing the code the agent writes and started reviewing the plan we write before it. A human who knows the system reads the plan, pushes back on the approach, and catches the things the author didn't know they didn't know. The code still gets checked, but we hand that to an agent and don't pretend it's peer review.
The accident in this, the part I didn't expect, is that the plan review turned out to be a pretty good classroom. It looks a lot like the whiteboard sessions I learned the most from early in my career: you argue the shape of the thing before anyone's built it, when changing your mind is cheap and the senior person's experience can still change the outcome. A junior arguing a plan with a senior is doing the same thing they used to do defending a PR, except earlier, and about decisions instead of syntax. The teaching that used to hide in diff comments has somewhere to live again.
The clearest example I have is one where I was the junior in the room. A more senior engineer had written a plan for a change I won't go into, and on the face of it the approach looked reasonable. I almost said nothing, because I assumed the gap I thought I was seeing was just my own missing context. But the whole point of a plan review is that the dumb question is cheap to ask, so I asked it anyway: there was a situation I couldn't see how the plan handled, and I wanted to know what happened in it. It turned out to matter more than either of us had assumed, and we reworked the approach around it. I never wrote a line of the code that shipped, and I'd have had no hope of catching this in a diff. I caught it because the decision was still in words, on the table, where someone without deep knowledge of that part of the system could still push on it.
I want to be honest about the limits of this. Arguing a plan teaches you how to think about a problem. It doesn't teach you the thousand small things you used to absorb by writing the code yourself: why this pattern bites you in six months, what a race condition feels like before it's a postmortem, the muscle memory of a language. Some of that, I genuinely don't know how the next generation picks up if they're not the ones typing.
So where does that leave us
Review changed underneath us before we'd really decided to change it, one prompt at a time, and the half we lost was the learning, the half we never talked about because it never needed its own name. Moving review to the plan gets some of it back. The disagreement is there again, and the place to teach is there again, earlier than it used to be. The rest of it, the learning that only ever came from being the person who wrote the line, I'm still working out, and I suspect a lot of you are too.
If your juniors are still learning from agent diffs, I'd genuinely like to hear how that's going. And if you've found something better than what I've described, I'd like to hear that even more.
We wrote down what we think this all means for the craft a few weeks ago: AI is not your peer. This post is one of the questions that manifesto left open.