Code review used to teach you about the system while you checked it. AI has stopped that from happening, and the damage compounds quietly.
An engineer in one of our internal AI tech talks described something everyone in the room recognized. "If you used AI and you generated 5,000 lines of code in the last two hours, no one is going to spend two days reviewing that."
Nobody argued. The interesting part is what people assume that means. It sounds like a volume problem, and volume problems invite volume answers. Review faster. Review a sample. Point another AI at it. Teams are trying all three right now.
None of them work perfectly, and the reason is that code review was more than just about reading code.
What review was actually doing
Think about what a good reviewer brings to a change. They know why a function is shaped the way it is. They know that the odd-looking retry logic exists because of an outage two years ago. They know which conventions in the codebase are deliberate and which are accidents nobody has cleaned up yet.
That knowledge is the review. The reading is only how it gets applied.
Now think about where they got it. They got it by writing code in that repository. By reading other people's changes. By having the debate in the comments and remembering how it ended. One engineer in the session put the underlying problem plainly: “people who have worked on a project for a while know things that aren't in any documentation and aren't in the code either. It's not good practice, but it's the reality of every long-running project.”
So review created a loop. You spent context to judge a change, and you earned context by reading it. The two halves make each other better. Nobody designed that, and nobody wrote it down. It came free with the fact that the same people wrote and read the same code.
That loop is what AI breaks, and it breaks it at both ends.
The input end goes first
AI-generated code arrives without the context that made code reviewable. There's no memory of the decision behind it, because there was no decision, only a prompt and a result.
Most review still happens in a browser, looking at a diff between two branches. One engineer made the point that a browser review starts from zero every time. A human can fill the gap from memory, badly but also usefully. An agent looking at that same diff cannot fill it in at all. It sees what changed, and nothing about why anything is the way it is in the first place.
This is how review bots turn into noise. Not because the models are weak, since they catch real defects and deviations from standards. It's because an AI reviewer can't tell deliberate from accidental and will flag both with equal confidence.
The danger doesn't start with the comment you ignore. It's the comment that's confidently wrong. As one engineer described it, the agent insists you can't do something, and you know perfectly well that you can, and after that happens a few times, you stop checking its findings at all.
That's a claim about people, not AI models. A reviewer that's wrong some of the time doesn't just fail to help. It teaches you to dismiss it, and the dismissal habit isn't selective. It covers the correct findings too.
A silent reviewer catches nothing. A noisy one trains you to catch nothing.
The output end goes quietly
The second half of the loop breaks without anyone noticing, because nothing fails.
If you only ever review AI-generated code, at some point you no longer know what the project is. You aren't making the changes, so you never build the understanding that reviewing used to give you. It stops being your code.
Knowledge used to move between people through this. You learned the system by reading your colleagues' work, and they learned it by reading yours. Now a lot of that learning goes through the agent instead. That has real advantages, and our engineers were fair about them. The agent is available at midnight; it never minds being asked, and you don't have to interrupt anyone. But as someone pointed out, it's easy to ask an agent how and forget to ask why. And whatever you learn that way stays with you. It doesn't accumulate in the team.
Why this compounds
Take both ends together, and you get a cycle that runs downhill.
Less context arrives with each change, so judgment gets harder. Harder judgment means more reliance on the agent to tell you whether the code is fine. More reliance means less close reading, which means less context earned. Next sprint, the same thing, slightly worse.
At no point does anything break. The bot still comments. The pull requests still merge. The tests still pass. The only visible symptom arrives late, when someone asks why a component works the way it does, and nobody on the team can answer.
The undocumented knowledge problem was always there. It was survivable because the loop carried it forward, person to person, one review at a time. Remove the loop and that knowledge doesn't move anywhere. It just ages out.
Rebuilding the input end
The good news is that this half is mostly mechanical. If the problem is that context can't reach the reviewer, then make it reachable.
Move the review to where context lives. One argument for reviewing in the IDE rather than the browser is exactly this. The agent gets the repository, the project's context files, and a conversation that stays alive while you work. You can ask what an unfamiliar function does instead of guessing.
Attach the intent to the change. Feed in the ticket, assuming it's any good. One engineer does this on nearly every task and says it takes seconds and clearly pays off. The more demanding version is writing the merge request so it can actually be reviewed: what problem this solves, what the solution is, what judgment calls were made, and what the tests showed. One engineer's process produces exactly that, and his point was that it makes a good merge request for a human too. Both audiences want the same thing, which is the context that isn't in the diff.
Ask for evidence instead of verdicts. This was the sharpest idea in the session. "There's no 100% confirmed way to force the AI to be correct," one engineer said. "I mean, it doesn't exist." So he stopped asking for correct answers. Every significant claim has to come with proof, written down and pointing at real code. When a bot flags something, he has his local session verify that specific finding and show its working. Then, as he put it, "I actually compare the proof rather than the point that was made."
A verdict from a model is something you have to trust. Evidence is something you can check in a minute. And checking is the only step in this loop that's genuinely reliable.
Use separate contexts on purpose. Asking the agent that wrote the code to review the code doesn't get you much. Open a fresh session, say you don't like this code, and the feedback improves. Several people in the room had found this independently, which usually means it's real. As one of them summarized it, context isn't only about adding more. Sometimes it's about removing.
Rebuilding the output end
This half is harder, because it isn't a tooling problem.
Part of it can be automated. One engineer has a standing rule that whenever he corrects the agent, the correction goes into a lessons file, which he later folds into the project's context files. That turns a one-off fix into durable context. Another floated a more ambitious version: harvest the comments from real merge requests, analyze them, and have an agent propose updates to the documentation. He was clear that it's still only a concept.
Both of these do something important. They move context out of heads and into files, which is the only place it survives when the review loop stops.
The rest is a discipline problem, and there's no clever answer. You have to keep reading the code even when nothing forces you to. Not line by line, and not for defects, but enough to keep the shape of the system in your head. One piece of advice was to go through everything the agent generated at least at a high level. The moment that stops, the clock starts on getting lost with a project.
Where this is still unsolved
Two things came up that nobody in the room resolved.
The first is that all of this is easier on well-structured code. One engineer argued for modular, loosely coupled components with clean interfaces, because then the danger of an unmaintainable mess is much smaller. Another pushed back at once. It's never like that. On projects where the client changes direction week to week, there's often no specification to review against at all. You should have one. You don't.
The second is that engineers guide their agents differently. Everyone has their own local setup and their own context files, and none of it is shared. So the output varies by author in ways only a human reviewer notices, and the context you carefully built for yourself doesn't help your colleague.
Not everything needs the loop
The last thing worth saying is that this isn't uniform, and treating it as uniform is what makes it unaffordable.
For code going to production, a person reviews it. That was never in question, and one engineer put the reason well: you own what you ship, whether you typed it or prompted it. If it breaks, it's yours. Ownership requires understanding, which means the loop has to run.
For throwaway tooling, it doesn't. One engineer's team commits the spec alongside the code for internal utilities and reviews the spec rather than the implementation. They know what they want the tool to do, and if they get it wrong, they rewrite it. Nobody needs to understand that code in a year, because it won't exist in a year.
The most useful frame came from an engineer who once led a team of fifteen mostly junior developers from the other side of the world. He built the core and the framework himself, and gave them the leaves, the end functionality that could be replaced later without disturbing anything important. He treats AI the same way now. Keep the parts that hold the system together, where understanding compounds. Delegate the parts you could delete.
That's the decision this all comes down to. Not how to review 5,000 lines in an afternoon, which you can't. It's choosing which code your team still needs to understand, and then actually paying the cost of understanding it.
Because the risk isn't that AI writes bad code. It's that in a year, nobody can tell you why any of it is the way it is.
