As AI agents can write code much faster than any human developer ever could, and as we get hundreds if not thousands lines of code as a results of one prompt, the need for careful code review is greater than ever. This remains the primary mechanism for ensuring that code is following engineering guidelines, architectural principles and in the same time ensures long-term maintainability and extensibility.
In one of my previous posts about vibe coding traps and delusions I have shared my thoughts on why and how the cognitive load is shifted from the code generation to the code review and why I think this is the topic that should attract more and more attention from fellow developers. In this article, I describe how I see the approach to the code review after more than a year of actively working with coding agents.
Active Code Review By The Author
Before requesting a peer review, the author should perform an active review of the generated code as if they were reviewing someone else’s work. Before AI, developers usually understood every line because they had actively participated in writing the code. Today, developers often guide the implementation rather than author every detail of it. With that being said, making an explicit self-review becomes much more important in order to be sure that agent generated what is intended.
This can be understood as a logical step, but as agents are writing comprehensive implementations and the syntax of the generated code appears to be very persuasive, it is not hard to believe everything what comes as an output from the agent is correct and to not pay enough attention on details. First thing that needs to be checked is if the generated code aligns with the architecture principles in the product and if the code is solving the right problem or inventing new one.
Another step is to try to do the same functionality with less code as possible. As LLMs by default are generating more code, sometimes more complex as it should be, we need to check if all that code is needed. In most cases it can be simplified, and we should insist on it as much as possible. Of course, at the beginning you will be in situation that you need to prompt back and forth till the desired output is given, but this is also the process where you can learn how to steer your agent in the way that fit your needs.
In the process, you will discover some patterns what fit your workflow, so you can define skills for the agent. In that way you already have predefined input for the agent next time you need some repetitive task. Both skills and rules can be used to streamline the code generation process. However, neither skills nor rules eliminate the need for careful code review. In the end, the author remains responsible for every line that is submitted.
Automated Review
Once the developer is ready to open a pull request, another step is often executed automatically as part of the CI pipeline. Here, the AI agent is doing automated review on the posted code and can find some very interesting edge cases, potential security risks or missing null checks. In the same time it still lacks the full business and historical context of the project. It may recommend changes that are technically reasonable but inappropriate for the product or existing architecture.
Here, the developer again should pay full attention on the feedback from automated reviewer to check if the review makes sense and if it is worth to be implemented. Again, we can expect here lot of suggestions, depending on the size of the pull request. Large AI generated pull requests often trigger a significant number of automated review comments. This is another reason to keep changes as small and focused as possible, to be able to carefully review them.
Code Review By Peer
If all previous steps are done correctly, then this stage should not take too much time, because much of the confidence should already come from the author’s own review and the automated review. This stage then is basically similar as the old fashioned code review before AI. Deep insights into this can be found in one of my older posts about code review so if you haven’t checked it yet, maybe now is good time to do it.
But, if some of the previous steps are poorly done, especially the first one, then the code reviewer is not in a thankful position, because entire responsibility for code quality is now shifted towards him. First problem here is that the developer who raised the pull request probably does not understand the code he authored, and this later can produce more issues when it comes to unexpected exceptions or maintenance. The author’s name is attached to the commit, but they cannot confidently explain why parts of the implementation exist or how they work.
Looking at the entire AI movement in the past years, I see one alarming thing if this is not handled correctly. It goes in the direction where teams are producing code much faster then ever before, but in the same time, senior engineers increasingly spend their time reviewing and validating AI-generated changes rather than writing new implementations themselves. In that case, AI accelerates code generation without necessarily accelerating software delivery.
Takeaways and Conclusion
AI has definitely changed where engineering effort is spent. Writing the code is becoming increasingly automated, but understanding, validating, and maintaining that same code remain human responsibility. Teams that recognize this shift and adapt their review process accordingly can benefit far more from AI than those who focus solely on generating code faster. Over time, that code will become harder to maintain if not even impossible.
Most important lesson I have learned is to keep code amount per pull request as small as possible, because it is easier then for the developer to review it and also for the peer to take a look at it. Large pull requests help neither the author nor the reviewer. They just increase uncertainty and reduce the confidence in the delivered product.
Top comments (0)