ito.ai review (2026): the ai code reviewer that actually runs your code

tldr: ito.ai is the only ai reviewer i’ve used that actually runs the app instead of reading the diff. it builds your project in a throwaway sandbox on every pr, clicks through the flows your change touched, and posts video plus reproduction steps when something breaks. that catches a class of bug static reviewers structurally cannot see. the catches: github only, web and api only (no native mobile yet), reviews take minutes instead of seconds, and the $40/month pro plan caps at 20 reviews per seat before charging $3 each. rating: 7.5/10. best used alongside a fast static reviewer, not instead of one.

---

every developer has the same story. the pr got two approvals. ci was green. it merged on a friday, and by monday someone in support was asking why signups had dropped.

nobody was careless. the reviewers read the diff properly. the tests passed because the tests covered what the tests covered. the bug was that a middleware change quietly stopped passing a session cookie, and no human reading a fifteen file diff was ever going to notice that the login button had stopped doing anything.

that’s the gap ito.ai is aiming at. not “is this code good,” which is a question the current crop of ai reviewers already answers reasonably well. the question it’s asking is narrower and much harder: does the app still work after this change?

this review is part of my tools section, where i write about software i actually run. no sponsors, no affiliate links, no referral codes.

---

what ito.ai actually is

ito.ai is an execution-based code review tool. the distinction matters more than the marketing makes it sound, so here it is plainly.

static reviewers read text. coderabbit, greptile, qodo, bugbot. they ingest your diff, sometimes an index of the whole codebase, and reason about it with an llm. they’re fast, they’re cheap, and they’re genuinely good at spotting a null check you forgot or a query that will fall over at scale.

ito.ai runs the software. on every pull request it builds a single-use containerised copy of your app from source, boots it, and drives it with agents that navigate the ui like a person would. frontend and backend get exercised together as one system, because that’s how they fail.

when something breaks, you don’t get “this may cause an issue.” you get a video of the thing breaking, the logs from the moment it broke, reproduction steps, a severity rating, and the exact lines responsible, posted straight into the pr.

that’s the whole pitch, and it’s a real one. the company’s own framing is that 81% of the bugs it finds are runtime-specific, meaning no amount of reading the diff would have surfaced them. i’m always sceptical of vendor numbers, but the architecture makes the claim plausible in a way most ai tool claims aren’t.

---

how the runtime testing actually works

the flow is four steps, and understanding it tells you fairly quickly whether it’ll work on your codebase.

1. it reads the pr, not just the diff. ito builds what it calls a code-aware test plan using three inputs: your codebase, the changes in the pr, and the pr description. that last one is doing more work than you’d expect. if you write “fixes the checkout flow for logged out users,” it goes and tests the checkout flow for logged out users. teams that write one-line pr descriptions get noticeably worse results, which is an odd incentive but not a bad one.

2. it builds an ephemeral environment. a secure, single-use sandbox per pull request, torn down after. you do not need a staging environment, which is the part that will matter most to small teams. staging environments are where a lot of engineering time quietly goes to die.

3. agents drive the app. browser inference and computer-use agents click through the affected surface area. it handles authenticated flows, including multi-factor auth, and manages sessions itself. third party services get mocked, so payment processors, email, and analytics don’t fire for real during a test run. that mocking is not a small feature. it’s the difference between “we can test checkout” and “we can’t test anything behind a paywall.”

4. it reports with evidence and re-runs itself. push a fix and it tests again automatically. the report carries video replay and screenshots, which is the part that changes team behaviour. arguing with a review comment is easy. arguing with a thirty second clip of your feature not working is not.

---

setting it up

the setup genuinely is light. you connect a github repo over oauth, open a pr, and it starts. no test scripts to write, no config file to maintain, no selectors to keep updating. the site promises results inside 60 minutes of installation and that’s about right in practice.

now the honest part, because “zero-config” is doing some heavy lifting in that sentence.

zero-config means zero test config. it does not mean zero setup. ito has to be able to build and boot your application from source. if your app needs a hand-rolled env file that lives in someone’s password manager, a seeded database nobody has automated, or three services running in a particular order before the homepage renders, you will spend an afternoon on that before you see your first useful run. that’s not really ito’s fault. it’s a fair diagnostic of your project’s own health, and a slightly uncomfortable one.

so use the free 5 pull requests for exactly this. don’t judge the quality of the findings yet. just find out whether it can stand your app up at all. if it can, everything after that is easy. if it can’t, that’s the real cost of adoption and you’ve learned it for free.

---

what it catches that static review misses

this is the section that decides whether the tool is worth $40 to you, so let’s be specific about the bug classes.

auth and session regressions. a middleware refactor, a cookie flag change, a redirect that now fires one step too early. the code reads fine. the login is broken. a diff reader has no way to know this. an agent that tries to log in finds out immediately.

silent data loss in forms. the form submits. it shows a success toast. one field never reaches the database because a rename happened on one side of the boundary and not the other. tests pass, because the test asserts a 200. this is the single most expensive category of bug i know of, because it’s invisible until someone reports missing data weeks later.

cross-boundary breakage. frontend and backend both individually correct, contract between them changed. the classic. ito tests them as one running system rather than two static files, which is the only way this shows up before a user finds it.

flows behind a login or a paywall. because it handles credentials and mocks the payment layer, the parts of your product that are hardest to test manually are the parts it covers automatically. most teams’ e2e coverage falls off a cliff exactly at the login screen.

the second-order break. you changed the settings page. the thing that broke was onboarding, because both read the same config. this is where the “10x more coverage” claim comes from. it decides what to test from what your change touched, not from a test suite someone wrote eighteen months ago and hasn’t looked at since.

---

where it falls short

no tool review is worth reading if it doesn’t have this section.

it’s slower, by design. static reviewers comment before you’ve switched tabs. ito has to build, boot, and drive your app. that’s minutes. it doesn’t fit the rhythm of “push, glance, merge.” it fits “push, go do something else, come back.”

github only. no gitlab, no bitbucket, no azure devops. coderabbit natively covers all four. if you’re not on github this review ends here for you.

web apps and http apis only. native mobile is roadmap, not product. if you ship react native or swift, this isn’t for you yet.

the review cap bites faster than you’d think. 20 reviews per seat sounds generous until you count how many prs your team actually opens in a month.

there’s almost no independent signal on it. i went looking for other people’s experiences and found close to nothing. no hacker news pile-on, no reddit thread of complaints, no g2 reviews of substance. everything ranking is either ito’s own marketing or a roundup post that mentions them in one line. that’s not a knock on the product, it’s a young tool, but you should know you’re an early adopter rather than the thousandth person through the door.

and the category-wide caveat worth carrying in: agentic testing has a reputation problem. practitioners who’ve cleaned up after these tools report suites of a thousand generated tests decaying into five hundred flaky ones. ito’s ephemeral, per-pr, test-plan-from-the-diff model is a genuinely better answer to that than “generate and maintain a test suite forever,” but treat every agent like a competent junior. give it your p2s and p3s. keep a human on anything that can lose money.

---

pricing, honestly

plan	price	what you get
open source	free	runtime analysis on every pr, unlimited public repos, video and screenshots per run. qualified non-commercial mit or apache projects only
free trial	free	first 5 prs, no card, results in about 60 minutes
pro	$40/month	unlimited repos, 20 code reviews per seat, custom rules, team insights, unlimited read-only users. $3 per review after 20
enterprise	custom	pro plus security and compliance, dedicated support, custom dpa, higher limits. aimed at 25+ engineers

now the arithmetic that the pricing page doesn’t do for you.

a three person team shipping at a normal pace opens somewhere around 40 to 60 prs a month. on one pro seat that’s 20 included and 20 to 40 overage at $3 each, so $100 to $160 a month, not $40. you can buy more seats to raise the included pool, but you should model your actual pr volume before deciding this is a $40 tool. it is not a $40 tool for an active team.

whether that’s expensive depends entirely on what a regression costs you. ito’s own framing is 3 hours per engineer per week lost to manual testing and under 40% of post-merge bugs caught by hand. at indian contractor rates the maths is less dramatic than at bay area salaries, but one silent data-loss bug caught before it ships pays for a year of this.

the open source tier is genuinely good and unusually generous. if you maintain anything public on mit or apache, there is no reason not to turn it on.

---

ito.ai vs coderabbit vs greptile

these get lumped together and they shouldn’t be. they’re doing different jobs.

	ito.ai	coderabbit	greptile
method	builds and runs your app in a sandbox	reads the diff, plus 40+ linters and sast scanners	indexes the entire codebase, reasons across files
finds	behavioural and runtime regressions	style, security, diff-level logic errors	cross-file breakage in large monorepos
evidence	video, logs, repro steps, severity	inline comments, pr summary	inline comments with codebase context
speed	minutes	seconds	seconds to a minute
platforms	github only	github, gitlab, azure devops, bitbucket	github, gitlab
noise	low by construction, a failure is a failure	very low, one eval logged 2 false positives	higher, the same eval logged 11

the number worth sitting with: in an independent evaluation across 50 real prs from projects including sentry, cal.com and grafana, greptile caught 82% of real bugs but threw 11 false positives, against coderabbit’s 2. that’s the fundamental trade of static review. push the catch rate up and the noise comes with it, because you’re reasoning about code that might break rather than watching code that did.

ito sidesteps that trade rather than solving it. if the agent watched checkout fail, checkout failed. there’s no probability attached. the cost of that certainty is that it only sees what it thought to test, and it only tests what it can build.

there’s also an argument in the category that i think is correct: llms trained on similar data share failure modes. a room full of static reviewers all miss the same bug for the same reason. that’s the strongest case for having one reviewer in the room that isn’t reading at all.

the honest recommendation is not either/or. run a fast static reviewer for the style, security and diff-level pass, and run ito for the “does it still work” pass. they’re not competing for the same slot. they’re competing for different money, which is the actual objection.

---

who should use it

use it if: you’re on github, you ship a web app or http api with real user flows, you have auth and payments, your team’s expensive bugs are behavioural rather than stylistic, and you either have no staging environment or a staging environment nobody trusts.

skip it if: you’re on gitlab or bitbucket, you ship native mobile, you’re a solo dev on a static site or a content project (my own site would learn nothing from this), your app can’t be built from source without manual steps, or your review pain is really about code style, in which case a linter and coderabbit cost a tenth as much.

---

common questions

is ito.ai a code review tool or a qa tool? it’s sold as code review and behaves like qa. if you’re evaluating it against coderabbit you’ll be confused. evaluate it against your manual qa process or your playwright suite and it makes immediate sense.

does it replace my e2e tests? partly, and that’s the interesting bit. it generates the test plan per pr instead of asking you to maintain one forever. i wouldn’t delete a playwright suite that works, but i’d stop expanding one that’s already a maintenance tax.

is my code safe? soc 2 type ii, end to end encryption, zero data retention, code never stored, sandboxes are single-use and destroyed. that’s a stronger posture than most tools at this price.

what’s the actual first step? install the github app on one repo, open a pr, use the 5 free runs to find out if it can build your app. that single question decides everything else.

---

verdict

7.5 out of 10.

it loses points for being github only, for having no native mobile, for a pro tier whose real cost is two to four times its sticker price on an active team, and for having almost no independent track record to check against.

it earns the score because it’s doing something structurally different from everything else in the category, not just running a better model. every other ai reviewer is a very well-read colleague who has never opened the app. ito is the one that opens the app. that’s a genuinely different tool, and the bug it catches is the expensive one.

if you’re on github with a real web product, install it on one repo and spend the 5 free prs. you’ll know inside an afternoon.

prices and features checked august 2026, direct from ito.ai. this category moves fast and pricing in particular has been changing across every tool in it, so verify before you buy. no sponsors, no affiliate links.