So your team uses AI a lot. Maybe you’re feeling a bit overwhelmed by the amount of bad code, or just the volume of code, you’re having to review. I’ve been there too. While AI has gained popularity, I’ve worked with many teams in many industries. Here are some techniques and strategies I’ve adopted, as an AI skeptic, which have made reviewing AI generated code feel less taxing and more productive.
What’s the same?
Before digging into what’s different, I think it’s worth taking a moment to recognize what’s the same. These things are true whether your PR was written by a human or an AI.
- All of your regular PR review goals about code quality, maintainability, testability, etc still apply. You may be reviewing AI generated code, but you’re still interacting with a human on the other end. It’s nice to remember that.
- Even though you may see many things you want to comment on, it’s still good to pick your battles and be strategic about which issues you mention.
- It’s also good to be open to alternatives you haven’t considered before. Just because it’s not how you would have done it doesn’t make it bad.
What’s different?
- The big thing that always jumps out to me is how verbose modern AI coding agents are. They write so much code. As a code reviewer, it’s hard to keep up.
- The PR author might not completely understand every technical decision they made. They may have not even read portions of the PR. People have always been able to copy and paste code from the internet, but this is turbocharged with AI.
- AI agents are good at solving the problem at hand, but not always at considering how their solution fits into existing systems or architectures.
How you can adapt
- AI will always be able to write code faster than you can review it. Your time is valuable: Be strategic about what you spend time commenting on, and be prepared to let minor things go.
- The PR author is likely not as attached to the implementation as they would be if they wrote it by hand. Use this to your advantage. It’s okay to suggest more sweeping changes, since AI is probably going to do it all anyway.
- Look for opportunities to use existing code or dependencies. AI doesn’t always know about these and will often reimplement things you already have.
- Consider that the PR author might simply put your PR comment into an AI agent. Be specific about what you’d like changed (while remembering you’re first and foremost talking to a human).
- Look for seemingly unrelated changes. AI will often change other parts of the app to get something working. Maybe those things were done that way for a reason.
Pay specific attention to tests
Testing is software engineering, but is often viewed as less important by both humans and AI alike. The author may not have reviewed the tests as closely as the implementation. It’s well worth your time as a reviewer to make up that difference.
- Do the tests actually test the code? AI will do whatever it needs to do to get a test passing, including stubbing or mocking the implementation it’s supposed to be testing.
- Look for opportunities to use factories or other test helpers. AI will often build objects or records from scratch, specifying all attributes, when something like a factory would result in less code and more reusability.
- Consider edge cases and boundary values. Are those tested?
- AI often writes a lot of tests. Are they all necessary? Perhaps some of the tests cover logic which is tested elsewhere.
- Are tests located in the right part of the testing pyramid? Could some slower acceptance tests be written as unit tests instead?
- Watch for huge test files, especially with a lot of setup. If you were writing that by hand, the pain of so much setup or mocking would have been a signal that the implementation could be refactored. But with AI, that signal can be missed.
If you want to influence the outcome, you have to participate in the process
Something I try to keep in mind when reviewing AI-generated PRs, and honestly in life, is that perfect is the enemy of good. Not every comment will be resolved exactly how you’d prefer. Sometimes you’ll let things slide that you wish you hadn’t. But steady, incremental influence still matters. A review that nudges the codebase in the right direction is far better than disengaging and letting low-quality AI output accumulate unchecked. If you stay involved, ask questions, and keep the conversation open with your teammates and leadership, you retain the ability to shape the outcome.
Finally, it’s worth remembering that advice like this only gets you so far. If your team is consistently flooding the codebase with poor AI-generated code, that’s ultimately not a tooling problem, it’s a people and process problem. Technology tends to amplify whatever dynamics already exist. The real work is helping the team move toward better habits and shared expectations. No one is trying to write bad code; they’re doing the best they know how. Thoughtful guidance, clear standards, and collaborative review are how you help them know better—and do better.
