How to Use AI Agents to Streamline Code Reviews

By Rodolphe Gabriel and Julia Baucher

November 3, 2026

Even a thorough code review can miss something important. A feature may appear ready for release, yet an important test is incomplete, a requirement hasn’t been fully addressed, or an implementation doesn’t quite match the original design. Finding these gaps means examining code alongside specifications, tickets, and test results, often under tight development schedules. 

With this in mind, my goal was to see whether AI agents could help make that process more effective; not by replacing the engineer conducting the review, but by examining the available evidence, identifying potential issues, and presenting findings in a form that makes them easier to evaluate.

To find out, I tested an AI-assisted review workflow on several feature implementations at Arteris. The results were encouraging, particularly when I deliberately gave the agents unfinished work to examine.

Bringing the Review Evidence Together

The workflow starts with the engineering artifacts already available in the repository, including design information, specifications, tickets, and implementation details. Rather than asking a single AI agent for a general opinion on the code, I used multiple agents to examine the relevant material and generate intermediate reports that identify potential risks and findings.

After reviewing the intermediate reports individually, I used a standardized prompt and a review consolidator agent to bring the findings together into a single, comprehensive assessment. The resulting report included an executive summary, overall metrics, categorized findings, and a recommendation. This gave me a clearer picture of implementation readiness and helped me focus on potential risks or issues that warranted closer investigation.

In one example, I ran the workflow against a feature that had already been merged. The consolidated report identified no blocking issues and recommended approval. That was reassuring, but the real value was not just the positive recommendation, but having a structured assessment that I could examine and challenge, rather than having to assemble all the review evidence myself.

Of course, a positive report does not prove that the implementation is free of defects. It is still up to the engineer to determine whether the analysis is sound.

What Happens when the Feature isn’t Ready?

To put the workflow to a more meaningful test, I ran it on an unfinished feature to see whether the agents could identify problems that might prevent its release. This time, the consolidated report flagged critical blockers, including missing functional testing and a design gap, and recommended that the feature not be released to production.

That was exactly the kind of result I wanted to investigate. The agents had identified issues that could have been raised during a merge request review, allowing the engineer to address them before the feature progressed further.

This suggests a useful role for AI-assisted review, where, instead of relying entirely on an engineer to discover every potential gap while moving among specifications, tickets, code, and test results, agents can help systematically examine those materials and draw attention to areas that warrant investigation. The findings still need to be verified, but the engineer has a more focused starting point.

Turning Findings into Engineering Actions

Identifying potential problems is only part of an effective code review. Engineers also need to determine which findings require action and how best to address them. To explore how AI could help with this next step, I used a review skill on another ticket to examine the findings and turn them into a checklist of follow-up actions. The skill provided the agent with code-review-specific instructions, while additional prompts allowed me to question individual findings, clarify their significance, and determine what needed further attention.

This approach was particularly useful because not every finding in a code review warrants the same response, and an AI-generated recommendation doesn’t necessarily mean a code change is required. In this case, the review identified four major findings, three of which I decided to address directly. I agreed that the fourth was a valid concern but felt it would be better handled in another way, so I documented my reasoning rather than making the suggested change as part of the current work.

That distinction matters. An AI agent can identify a potential issue and recommend an action, but it does not necessarily understand every engineering constraint or the broader reasoning behind a design decision. The engineer needs to assess the finding in context and determine the appropriate response. For me, the value of the checklist was that it helped organize the work without turning the agent’s recommendations into instructions that had to be followed. 

Could This Become Part of the Development Workflow?

I ran these experiments manually, but there is no reason the same process could not be explored as part of a more automated development workflow. For example, Jenkins or a custom script could potentially invoke named agents with standardized prompts, generate the intermediate reports, and consolidate the results. That could make AI-assisted review a repeatable activity associated with a merge request rather than a separate experiment initiated by an engineer.

There are practical considerations to evaluate before taking that step, however, including the usefulness of the findings, the effort required to review them, and the resources consumed by the agents. In my initial experiments using AI, the test reports generated that morning consumed around 100 tokens, which seemed reasonable. It would be interesting to compare that consumption with other models or tools, such as Sonar or Office, to understand the relative costs of AI-assisted review better.

The important question is whether automation would make the review process more effective. Generating additional reports has little value if they create more work than they save, or if engineers cannot trust the findings enough to act on them.

Keeping Engineering Judgment at the Center

What I found most useful about this experiment was not that AI could produce a code review report, but that several agents could examine different aspects of an implementation, bring the evidence together, and help me focus on issues that might otherwise take longer to discover.

The unfinished feature test was a particularly useful example because the workflow identified genuine areas of concern, rather than simply producing a reassuring summary. The follow-up checklist showed another benefit: it turned review findings into something an engineer could assess, prioritize, and act on.

At Arteris, this kind of experimentation reflects a practical approach to applying AI in engineering. The goal is to understand where AI can make established development activities more effective, while retaining the technical rigor and human judgment that complex semiconductor design demands.

Explore Arteris IP:

• FlexNoC Interconnect IP
• CodaCache Last-Level Cache IP
• FlexGen Smart Network-on-Chip (NoC) IP
• FlexWay Interconnect IP