Why AI Code Review Needs to Read Your Code *and* Run It

Teams are shipping more code than ever. Not because anyone suddenly got faster at typing, but because AI can generate code faster than any individual engineer can.

That speed creates a new constraint: every AI-generated code change still needs to be reviewed, tested, and trusted before it reaches main. For many teams, the practical choice has become either merging on faith, or accepting a major pre-merge bottleneck.

AI code review helps break that bottleneck:

• Reviewing and testing every change by hand takes more time than most teams have.
• Code review is tedious and easy to defer, so it is a natural task to offload to a system that does not get tired or frustrated.
• AI can review far faster than a human and catch issues before they become production bugs.

Yet, deciding you're going to have AI help review all the code you're generated is just the first step. You need to decide what kind of AI code review you want to use. The two main approaches are called static analysis and runtime analysis.

Let's take a look at where each fits and why the strongest reviews use both together.

The two main approaches to AI code review

AI code review generally falls into one of two categories:

• Static code analysis reads your source code without running it. It identifies bugs, quality issues, and risky patterns by examining your code’s structure, known failure patterns, and underlying logic.
• Runtime analysis runs your application and evaluates how it behaves in real scenarios. Instead of inferring what the code will do, it validates your user flows by using your product as a customer would.

These two approaches test different layers of the same problem, which is why they are at their best when they work together.

TL;DR: Static code analysis vs runtime code analysis

If you only have a minute, here is how the two approaches compare:

Note: Static analysis is where most teams start, and many AI-forward companies already have covered. Runtime analysis is usually the gap. If getting that side right is what you are after, we built Ito specifically to help you.

An overview of static code analysis for AI code reviews

Let's start with the more familiar approach: static analysis.

What is static code analysis?

AI-powered static code analysis examines source code without executing it, using AI models alongside code-aware techniques to identify likely bugs, security risks, and quality problems.

Now, you might be wondering how this is different than a linter. The key is intent.

A linter enforces a defined set of style and code-quality rules, such as unused variables, missing semicolons, or improper formatting. Syntax errors are usually caught earlier by the parser or compiler.

Traditional static analysis scanners go deeper, tracing known bug patterns and security flaws through your code.

AI-enhanced static analysis can use the surrounding code and repository context to infer likely intent and follow how logic flows through a change. That lets it surface subtler issues that no fixed rule would catch; these issues are the kind you would only notice on a very careful read.

The goal is to expose hidden risk early, while the code is still a diff in a PR.

By analyzing structure, dependencies, and patterns before anything runs, static analysis helps you fix problems early in your review process, often before the first human reviewer takes a look at your PR. Speed is a key benefit here, because they can often identify issues within a few minutes of putting up your PR for review.

How it works

AI static reviewers typically start with your pull request diff, then use available context on your repository to assess the change against the surrounding code. That can help identify how a local edit may affect other parts of your codebase.

Depending on the tool, that analysis may also incorporate traditional static-analysis techniques such as abstract syntax tree parsing, dependency graphs, and control-flow tracing, alongside AI-based reasoning.

That broader context helps the tool look beyond individual lines and flag issues such as risky coupling across files, dependency problems, and deviations from established patterns. Instead of a raw warning, it can provide a plain-English explanation and, in some cases, a suggested fix.

A quick example: a PR adds a function that pulls a user's orders for a dashboard. It compiles, the types line up, and nothing looks wrong.

An AI static reviewer reads the diff against the rest of your repo and notices the function queries the database inside a loop, once per order, instead of batching a single query; no linter rule was broken. It flagged the pattern as a performance risk and suggested a batched query.

That is the kind of catch static analysis is good at.

When to apply it

Static analysis should be used in large codebases, where manual review stops scaling. When lots of pull requests are open at once, AI static analysis spreads reviewer-level expertise across all of them in parallel.

It also shines when fast feedback matters.

You can identify and fix issues within minutes of pushing, long before you request a review from a peer or open the merge. In rapid development cycles, where multiple contributors are pushing changes constantly, that early pass can surface likely problems before your PR reaches the main branch, keeping your review queue more manageable.

Biggest limitations

Static analysis is genuinely useful, but it has real limits, and most of them come from the fact that it never runs your code.

The first is consistency. AI reasoning quality can vary, so the same tool might produce conflicting or overly cautious feedback depending on how it interpreted a given change.

The second is scope.

A static reviewer is limited to the code and context it can access. It may not know the product decision behind a change, an architectural direction that has not yet been captured in the repository, or the tradeoffs your team has agreed to make. That is a big part of why human review still matters.

The rest of the limitations show up the moment code stops being analyzed and starts executing in a real environment:

• Hidden integration failures, where services that appear correct in isolation fail when they interact through a distributed system or API.
• Asynchronous issues, where timing, race conditions, or event ordering create behavior that looks fine in the code but fails under real execution.
• User-flow inconsistencies, where the system technically runs but does not produce the end-to-end behavior users expect.
• Performance and load gaps, because spotting a risky pattern in the code, like the query-in-a-loop from earlier, is not the same as measuring latency, throughput, or how the system holds up under pressure. Static analysis can flag the risk, but measuring the impact requires running the app under real conditions.

None of these are failures of static analysis so much as things it was never designed to see.

To catch these issues, you need to run the app under real conditions, with all of your integrations, inputs, timing, and load.

That's where runtime analysis comes in.

Understanding AI runtime code analysis

Static analysis is strong at what it does, but it has key blind spots. It can inspect code, but it cannot observe what happens when that code runs in a real environment.

What is AI-powered runtime analysis?

AI-powered runtime analysis is execution-based evaluation of your code. Rather than inferring behavior from the source, it observes and tests what the system does while it actually runs.

It exercises the parts of your codebase affected by your PR, including the frontend, backend, databases, and external-service calls, then uses AI to generate test scenarios around the user flows and execution paths that matter.

How runtime code analysis works in AI code review

Runtime analysis starts in the same place static does: with the pull request.

AI agents read the PR diff and its surrounding context, then generate a targeted test plan focused only on the user flows and system areas the change affects.

One of the quieter advantages here is context. That context determines what gets run.

Runtime analysis is a broad idea. When you start running the code, you could run tests in a variety of ways including using Playwright and Cypress suites, creating integration tests, load tests, and perform manual QA.

The biggest difference between these options is how much you have to build and maintain by hand, and how much the tool can do on its own.

Ito sits at the far end of that range. Ito runs tests by looking at the diff and the PR description as the starting point for determining what to test. You can also give the agent plain-English instructions about which flows matter, applied across every run, or scoped to specific repositories and authors. That context shapes which user flows get built, exercised, and validated, so the review lines up with what you were trying to ship, not just the lines that moved.

From there, instead of scripts you write and keep green, Ito builds and runs a full instance of your application from source in a controlled, single-use sandbox, spun up fresh for that pull request and thrown away afterward. Then it explores that instance the way a real user would: clicking through the UI, firing API requests, and triggering backend workflows to test end-to-end behavior across your stack.

When should you use runtime analysis?

Runtime analysis belongs in pre-merge validation, where it tests whether a change has broken critical, user-facing flows before you merge your code. It is most valuable for teams shipping at AI speed with complex apps, where manual verification cannot keep up, and end-to-end suites are too cumbersome to maintain.

With this approach, you can catch problems early, so you neither burn customers with production bugs, nor burn out your engineers having them do too much manual testing themselves.

The biggest limitations

Runtime analysis comes with trade-offs worth knowing up front.

The hardest part is the setup. You can wire this up yourself with Playwright or Cypress, but those suites are yours to maintain. Then, as your product changes, keeping them green can become a significant engineering cost.

If you want something more sophisticated and custom to your company, you may end up building your own system. However, building and running your app in a clean, reliable environment takes real engineering time. Most teams would rather stay focused on building their product for customers, not maintaining an internal tool like this.

Coverage is another issue. The results are only as good as the paths your runtime analysis chooses to test. To save time, you can focus on your most important flows, but that means you may miss key edge cases.

Yet, even if you built the perfect system for yourself, and had limited maintenance demands, your work is not done. You still need to gather the evidence and make sense of any issues you do find. That means you need to develop clear severity ratings and quality evidence packages to help you and your AI code gen of choice figure out what needs to be fixed.

Ito's approach to AI code review through runtime analysis

Ito is an AI-powered code review tool built to perform runtime analysis on your PRs. Instead of only reading your source code, it executes your application and validates the user flows each pull request affects.

For a concrete example, see what happened when DoltHub ran Ito on 43 pull requests.

We built Ito to take the manual review work off your plate. When your team ships code faster than you can check it, you end up with a backlog no matter what you do; either new features and functionality are delayed actually reaching customers while you wait for more review, or you ship it without sufficient checks, and now you have to deal with a wave of new bug reports and customer issues to fix.

That's why having AI runtime analysis in addition to a static analysis tool is so helpful; it gives you more validation and confidence before shipping, without overburdening your software engineers, nor your QA team.

Best of all, Ito handles many of the runtime limitations we covered above:

• It sets up the test environment for you, so you skip the setup that makes in-house systems so painful to create and maintain.
• It takes plain-English instructions, so you tell it which flows matter most instead of leaving it to guess.
• It ranks issues by severity, so you get a clear list of what to fix first instead of a wall of noise.
• It writes evidence-rich reports with video, logs, screenshots, steps to reproduce, and the exact files and lines behind each failure, so you have what you need to fix it fast.
• It goes past the happy path on purpose, into the edge cases and adversarial flows that are easy to miss.

The result is similar to having a QA engineer on every pull request, running your app, trying to break it, and handing your team a report they can act on right away. The difference is Ito is tireless, can test many PRs in parallel, and delivers results in a clear, actionable way. You can literally copy and paste a prompt for your agent to let it validate it's a real bug and propose a fix.

Want to see for yourself? Start a free Ito trial and experience AI-powered runtime code review firsthand with 10 free code reviews of your PRs.

Static code analysis + runtime code analysis: final thoughts

The two approaches answer two different questions:

• Static analysis asks whether the code looks correct before it runs.
• Runtime analysis asks whether the application behaves correctly when it does.

Because they address different layers of code quality, they are complementary rather than rivals.

Static analysis finds likely risks at a low cost and high speed. You can often get results in minutes. Runtime analysis tests the changed behavior and produces evidence about failures that only appear in execution. You may have to wait longer for it, but you'll end up catching results you'd otherwise only find in production after they've burned a customer.

Together, they combine to give you the best possible coverage of your code changes, without taxing your team and making them spend all their time testing.