The question is not whether to review
This is a widely discussed and somewhat controversial topic: how do you maintain product quality when AI development agents can produce code faster than developers can review it? Should developers review everything, nothing, or something in between?
(Some even argue that the code is now a redundant artifact.)
The answer is the most boring one: it depends. That was true before AI development agents, and it remains true today. In short, peer reviews should not be a mandatory gate by default. Instead, they should be proportional to your product, the risks associated with it, the part of the product being changed, and the quality and maturity of your SDLC.
Review quality starts before the pull request
As mentioned, the quality and maturity of your SDLC are key factors. Here are some questions to help you assess it:
- Do you have a robust CI/CD pipeline with reliable checks, deployment safeguards, fast feedback loops, and a safe rollback strategy?
- How much confidence does your existing test suite give you? Does it cover the most critical parts of your application? How often does it miss regressions?
- Can you enforce your coding conventions, code style, and secure coding practices via static analysis checks?
- Do you have proper observability systems in place?
The practices and tools covered by these questions are not new in SDLC tooling, but they have become even more critical when working with AI development agents.
Agree on what requires human review
Once you've concluded (with your team) that your SDLC stack is mature enough to rely more on automated code reviews, the next step is to define what warrants a human review, if anything, and what can be left for the agent to review. Some discussion points are:
- Which parts involve business-critical behaviour, such as handling money and the most important customer-facing journeys?
- Which parts are not well covered by your test suite?
- Which parts deal with regulated data, security, or privacy?
If starting with what needs human review feels too difficult, try defining what does not need human review. Some common lower-risk examples are:
- Throwaway experiments, prototypes and other short-lived code
- Internal support tools
- Operational tooling and helper scripts
If your team is working with a system such as Kanban or a framework such as Scrum, it may be practical to add a lightweight triage step to your workflow. This step can classify changes by risk and determine the required level of review before any code is produced. The levels could be, for example:
- AI review only
- AI plus human review
- AI plus mandatory specialist review
What about AI review?
Whether or not your SDLC tooling is mature enough to allow AI-only review in some cases, AI review should be the baseline. It can improve the quality of human review by catching first-pass issues, such as missed edge cases, immediate defects, and inconsistent patterns. In turn, it gives reviewers the opportunity to focus more on intent and system-level impact.
Closing reflection
Importantly, the goal should not be to remove humans from software delivery, but to apply their judgment and effort where they have the greatest value. Human-review time is limited and should be focused where it best protects customers and the business.
To emphasize, AI-assisted review has the potential to be one of the best use cases for AI, with an immediate positive effect on a team's delivery speed and confidence, as long as it is well instructed and tuned to the codebase's conventions, architecture, and risk profile.
Do you need help taking the most out of AI in your software delivery, without hurting quality? Get in touch.