TL;DR: Traditional AI code review reads the diff (or the whole repo) and comments on style, bugs, and architecture — statically. It never opens the app, so it can't tell you whether the button works, whether the flow completes, or whether your change broke an unrelated screen. AI code review that actually uses the app runs the change in a real browser and reports what happened. screencli is the reviewer built for this: it opens your preview deployment on every pull request, clicks through the change like a user, and posts a pass/fail verdict with a recording — before your review even starts.
What is AI code review that actually uses the app?
AI code review that actually uses the app is behavioral review: instead of reading source code, the reviewer runs the built application, drives it in a real browser, and judges what happened. The distinction is reading versus running.
Static AI review — the dominant model in 2026 — sends your diff to a language model and gets back comments. Good tools also feed the model surrounding repo context. But every one of them shares a hard ceiling: they inspect code, they never execute it. A reviewer that only reads text cannot observe a runtime, so it cannot tell you whether the feature actually works when a user touches it.
Behavioral review closes that gap. It treats the PR the way a human QA reviewer would — open the preview URL, follow the change, watch what the app does.
Diff-only vs. codebase-aware vs. behavioral review
There are three tiers of AI code review, and the first two are both static:
| Approach | What it inspects | Catches | Misses |
|---|---|---|---|
| Diff-only review (e.g. Copilot PR review) | The changed lines, plus a small window | Style, obvious bugs, off-by-ones, type lies | Anything outside the diff; anything that only shows up at runtime |
| Codebase-aware review (e.g. CodeRabbit, Greptile) | The diff + indexed whole-repo context | Cross-file regressions, architectural drift, N+1 patterns | Whether the running app actually behaves correctly |
| Behavioral review (screencli) | The running app in a real browser on your preview deploy | Broken buttons, dead flows, runtime errors, regressions on unrelated screens | Deep internal logic a human still needs to reason about |
According to Sourcegraph's 2026 automated-code-review analysis, the dividing line most people focus on is context: "an AI reviewer that only sees the diff cannot tell you that the function you just changed has 14 callers in three other services." That's real — codebase-aware tools like CodeRabbit and Greptile earn their keep by indexing beyond the diff.
But there's a second dividing line almost no one names: reading versus running. Even a reviewer with perfect repo context is still reasoning about code that has never been executed.
What diff-only review can't see
Diff-only review can't see anything that only exists at runtime. Reading a diff answers "is this code plausibly correct?" It cannot answer the three questions that actually decide whether a PR is safe to merge:
- Does the button work? A handler can be wired to the wrong prop, a form can submit to a stale endpoint, an
onValueChangecan silently never fire — all while the diff looks perfectly reasonable. - Does the flow complete? Signup, checkout, and onboarding are multi-step. A change that reads fine in isolation can dead-end on step three, and no amount of static reading surfaces the dead end.
- Did the change break an unrelated screen? A tweak to a shared component, type, or global style is locally correct in every file and still breaks four screens that import it. The diff doesn't contain the breakage — the rendered app does.
As OpenHands' 2026 write-up on AI code analysis puts it, the hardest bug classes "live in the relationships between pieces of code" and in runtime topology — race conditions, scope-elevation bugs, performance regressions — "which is why line-by-line scanners don't reach them." A tool that never runs the code is structurally blind to this entire category.
Why behavioral review matters on every PR now
Behavioral review matters now because AI is generating far more code, and that code fails at runtime more often. The volume and the defect rate are both climbing at the same time.
The volume is staggering. AI agent pull requests on GitHub jumped from 4 million per month in September 2025 to 17 million per month by March 2026 — a 325% increase, according to an analysis by Danilchenko.dev. Faros AI's 2026 study of 22,000 developers across 4,000+ teams found teams merging 98% more pull requests while PR review time rose 91% — and, tellingly, 31% more PRs now merge with zero review because reviewers simply can't keep up.
The defect rate is worse for exactly the code flooding the queue. A CodeRabbit analysis of 470 pull requests (reported by ByteIota) found AI-generated code carries 1.75x more logic errors, 1.57x more security vulnerabilities, and 1.64x more maintainability issues than human-written code. Sonar's 2026 State of Code survey found AI now writes 42% of all committed code, yet 96% of developers say they don't fully trust it to be functionally correct and only 48% always verify it before committing.
And static gates aren't catching it. Lightrun's 2026 report found 43% of AI-generated code changes still require manual debugging in production even after passing QA and staging. CloudBees' State of Code Abundance 2026 report found 81% of organizations saw production issues increase linked to AI-generated code — despite 92% expressing confidence it was production-ready before it shipped.
Logic errors, broken flows, and runtime regressions are precisely the failures a diff can't reveal and an executed app can. When machines write the code, the review layer has to actually run it.
How screencli reviews your PRs by using the app
screencli is an AI reviewer that opens your preview deployment in a real browser on every pull request, clicks through the change like a human, and posts a verdict — before your review starts. You install the screencli GitHub App and pick which repos it watches. When a PR opens, screencli reads the diff, plans the browser checks that matter for that change, runs them against your preview deploy (Vercel, Netlify, Cloudflare Pages — it picks up the deployment URL from your GitHub deployments, and never touches production), and posts a pass/fail comment with a recording link.
You don't write test files. The AI decides what to exercise based on what changed, then shows you the evidence — a video of the flow actually completing, or the exact step where it broke. That turns "the diff looks fine" into "the change was used, and here's what happened."
Install the screencli GitHub App and your next pull request gets an AI-driven browser test on your preview deploy — automatically.
For the underlying pattern, see how we use Playwright and Claude Code to verify AI agent work and how preview environments plus visual verification fit into an agentic coding workflow.
Behavioral review vs. static review: do you need both?
Yes — they catch different failures, and they're complementary. Static review (diff-only or codebase-aware) is fast and cheap, and it's genuinely good at style, obvious bugs, and — for context-aware tools — cross-file reasoning. Keep it as a first-pass filter.
Behavioral review is the layer that answers the question static review can't: does it actually work when a user touches it? The strongest 2026 setups run static analysis for early, cheap feedback and behavioral review as the gate before merge — because that's the check that maps to what your users will experience. As PR volume climbs and more code is machine-written, the run-it layer is the one that stops broken flows from reaching production.
FAQ
What's the difference between AI code review and behavioral AI code review? Standard AI code review reads your code — the diff, and sometimes the whole repo — and comments on it statically. Behavioral AI code review runs the built application in a real browser, exercises the change, and reports what actually happened. Reading catches code-level issues; running catches broken buttons, dead flows, and runtime regressions.
Can diff-only AI review catch a broken button or a failed checkout flow? No. A broken button or a dead multi-step flow only exists at runtime — the diff can look completely correct while the running app fails. Detecting it requires executing the app and interacting with it, which is what behavioral review does.
Does screencli replace CodeRabbit, Greptile, or Copilot review? No — it complements them. Those tools read code and catch code-level issues. screencli runs your app and catches behavioral failures they can't see. Many teams run a static reviewer plus screencli's behavioral review as the pre-merge gate.
Does behavioral review run against production? No. screencli runs against your preview deployment — it picks up the preview URL from your GitHub deployments (Vercel, Netlify, Cloudflare Pages, etc.) and tests there, so production is never touched.
Do I have to write the tests? No. screencli's AI plans the browser checks based on what changed in the PR, runs them, and posts a pass/fail verdict with a recording. There are no test files to write or maintain.
Related reading: How to use Playwright and Claude Code to verify AI agent work · Preview environments + visual verification for agentic coding.