A developer asks Claude Code to implement a feature. Thirty minutes later, there's a pull request with 800 lines of code, tests, documentation, and a working demo. The code compiles, tests pass, and it ships. A human reviews it and signs off because, well, it's clearly working.
That's the new normal, and it's breaking the code review process that worked fine when humans wrote code in hundred-line chunks and code review was about catching bugs.
How the old process fails with agent output
Traditional code review looks for bugs, style issues, and architectural problems. With human-written code, a 200-line PR takes 30 minutes to review, and you catch about 70% of the real issues.
With agent-generated code, the PR is 800 lines, it compiles, tests pass, and the functionality works. A human review of the same PR finds it hard to justify spending three hours reading code that clearly works, so they skim it and approve.
But the problems are different now:
- The agent included a library you didn't want to add (architectural bloat)
- The agent solved the problem in a way that's incompatible with your infrastructure (uses the wrong database schema, the wrong authentication pattern, the wrong async approach)
- The agent included security-sensitive code that follows best practices in the abstract but doesn't match your company's security model
- The performance is acceptable in the test cases but will degrade unpredictably at scale
None of those are bugs that make the code "not work." They're architectural decisions that a human would have discussed with the team before writing 800 lines. An agent doesn't know to have that discussion.
What actually needs to change
Stop reviewing code, start reviewing architecture.
Before the agent writes anything, someone human should document the constraints: the database schema it must use, the authentication method, the deployment target, performance requirements, and any libraries that are forbidden or required. Those aren't code review decisions, they're architecture decisions, and they should happen before the PR exists.
Then, when the agent's PR shows up, the review is focused: does the code respect the constraints? Is it using the right database schema, the right authentication, the right performance characteristics? That's a 15-minute review instead of a three-hour one, and it catches the actual problems.
Invest in automated checks that matter.
Add linters and checkers that your team cares about: "no new dependencies without approval," "async code must use this pattern," "performance regressions trigger failure," "security checklist must pass." These checks should be in the CI/CD pipeline, not in a human's head.
An agent will follow automated constraints better than a human will. If your linter says "no new dependencies," the agent mostly won't add them (or will fail and ask why it's not allowed). This is worth documenting in code.
Make the agent's context rich enough that it doesn't need review for obvious things.
If the agent has access to your architecture documentation, your code patterns, and examples of how you do things, the code it produces will be closer to what you'd want. The better the prompt and the better the context, the less review overhead later.
Introduce a new role: architectural review for agent output.
The person reviewing agent code should be a senior engineer or staff engineer, not a mid-level engineer who reads code line by line. They should be checking "does this make the right architectural choices?" and "does this respect the team's patterns?" not "is this the way I would have written it?"
What's still worth human review
Security-sensitive code. Any code that touches authentication, authorization, encryption, or data handling. An agent can write secure code, but a human should spot-check it.
Performance-critical code. Any code that's in a hot path, handles high volume, or has latency requirements. An agent will write code that works, but not always optimally.
Novel approaches. Any code that uses a pattern that's new to your team or unfamiliar to most reviewers. Novel doesn't mean bad, but it means human judgment is warranted.
Anything with real business impact. If the code is wrong, does it affect customer data, billing, or compliance? That needs human eyes.
The staffing implication
The shift from "developers write code and reviewers catch bugs" to "agents write code and reviewers check architecture" changes who should be reviewing code. It changes from "any senior engineer" to "someone who understands your architecture deeply." It's a smaller group, and they're busier (they're now reviewing both the architecture *and* the code that implements it), but the review is more valuable.
If you're shipping code written by AI agents and you haven't updated your code review process to match, you're probably shipping code that's technically correct but architecturally misaligned with where you want to go. We cover this in our guide to building with agentic AI engineering practices.
