Launched this week
Ito
AI code review that runs your code
879 followers
AI code review that runs your code
879 followers
Ito is an AI code review tool that runs your app before it reviews the code. For every pull request, Ito spins up an ephemeral environment, validates impacted flows, and returns runtime evidence so teams can catch bugs that static analysis and model-only reviewers miss. Instead of guessing from diffs, Ito shows what actually broke, where it happened, and why it matters before the PR reaches production.
Hey Product Hunt. I'm Evan, cofounder of Ito.
Coding agents produce more code than you can review. Existing code review tools only stare at the code, so you still have to review tons of code or build complex internal systems to verify it.
Ito is a runtime code review tool. On every pull request:
Creates test plan from code, PR description, ticket, your input
Builds your app in a single-use isolated container with the ability to use credentials, seed data to reach the state that matters, and use external services just as an engineer would on their local machine. Mocks data/code when it doesn’t have access.
Drives the app with a swarm of agents (click, navigate, API call, db verification)
Catches runtime issues: concurrency, failure handling, data migration, authentication, etc.
Posts results on PR with evidence: video, logs, screenshots
We built Ito with a team of 8 MIT engineers, and spent many cycles to arbitrarily build any application.
Ito gets better the more you use it:
Responds to feedback
Faster runtimes every run as Ito learns how to navigate your application and builds tools to manipulate your environment
Reviews focused on the areas you care about (sees what gets fixed vs ignored)
Test instruction per org, per repo, or per author
First 100 reviews free, no card. $40/mo after that. Free forever for open source (already supporting >100k stars): app.ito.ai?ph
You can also try out open source PRs without signing up here: https://www.ito.ai/review?ph
@evanmarshall Boom..congrats on the launch🙌 If a PR has broken build scripts does Ito fail fast and comment on the PR or does it attempt to self-heal the setup script?
@priya_kushwaha1 Ito builds the environment and self heals if possible. Generally the limiting factor is access for example if you have a private npm repository, you need to configure Ito (using the settings) to give it an access token.
@evanmarshall That’s really useful, self-healing the setup when possible sounds like a great feature, especially for complex projects. Thanks for clarifying!
@priya_kushwaha1 Maintaining the environments automatically is a huge benefit of Ito. As new migrations land or new services come into the codebase, Ito automatically repairs and updates the environment.
Move AI
@evanmarshall What made you want to build this? I know it must be personal.
@philsalesses Ito came from working in fintech and cryptography for 4 years. In that environment, if you make a mistake, it can cost tens of millions of dollars. We were a small company so we felt constant pressure to move quickly and break nothing. The thought that a single hack could destroy years of what I had been building kept me up at night. I met a few people it happened to. Verification and correctness were absolute requirements.
We started building our internal version of Ito in early 2025 and had to build a lot of infrastructure to support agentic QA. As the models got better (Opus 4.5) we realized we could generalize and automation the creation of infrastructure & workflows for everyone else. That's when we spun out Ito. Now with agents writing 100% of code, the need has never felt greater. Verification & alignment are new bottlenecks.
@philsalesses Another big reason we wanted to build this is we know how big of a pain it is to write and maintain Playwright-style End-to-End testing suites. We used to rely on these sorts of tests to protect our system from regressions because they can be very effective, but we found that between selectors breaking on every UI change, tests failing randomly with timing issues, and maintaining this every-growing secondary codebase, it brought more headaches the benefits to our team. Ito has alleviated this pain point immensely by allowing us to get rid of these tests while still trusting that bugs and regressions are getting caught each PR.
Running the app before reading the diff is the actual difference here, and it creates a question I have not seen a runtime reviewer answer well.
What does Ito post on the PR when the container itself never came up? Build failed, seed data unavailable, external service refused the credential. If that lands as "no runtime issues found", then a broken environment and a clean PR are the same result, and it fails silently in the direction that looks fine.
So: what does a run that could not run report as?
@rabnoor_s Ito adds an emoji to a PR when it starts to run and when it succeeds or fails to run for whatever reason.
@rabnoor_s If there is an issue with the build, then we report that there was an issue with the build so that the reviewer is not flying blind. We don't just blind pass, which would go against the purpose of Ito :)
If there is a complicated repo where we need code access, we work with those customers to get the necessary access and environment ready, so that there are no build problems on every PR
Startup - #13 Fake It Til You Make It
Congrats to you and the team, Evan! This is a huge problem, and I know it will remain one. Excited for you all to help eng teams solve it.
@jasondemant Thanks for the support!
@jasondemant thank you for the kind words! It is indeed a difficult and large problem that is only growing in scope as teams continue to leverage AI tools to ship faster.
The models nowadays are absolutely getting good enough that anyone can point an agent at a branch and get real testing help locally. This is a great practice we encourage and something our engineers do as well.
However, our bet with Ito is on the harness around the model: purpose-built cloud infrastructure that stands up a full environment for every PR and tests it deeply, in parallel, and without tying up resources on anyone's machine all while learning the testing preferences of the users and organization using it over time.
Install it once and the entire org gets runtime testing by default... nothing to remember to run, no setup per repo per engineer, and it's faster, cheaper, and more exhaustive than any of us would manage locally, even with an agent's help.
Like you said, it's a big problem, but we're doing our best to solve it in a way that individual contributors and organizations will love.
Execlave
Love the runtime angle. How do you handle PRs that touch external services — mock them in the ephemeral env, or spin up real instances?
@bhaumik_lathiya thank you for the question! Ito's preference is to test with the real service as that is the highest-fidelity way to test at runtime. Dependencies that can run locally (databases, caches, queues, even sibling services in multi-repo setups) are spun up for real inside the ephemeral environment. For true third-party APIs, customers can securely share the secrets and variables their app needs to connect to them. If Ito still can't reach a service, it leverages the fact that it's running in an isolated environment and uses clever techniques to mock that specific service so it stays unblocked and tests the core of the system in question. Every test result also discloses what was mocked, so you always know the provenance. Finally, if the repo needs something custom to get Ito truly running as smoothly as possible, our team works directly with you to tailor the environment to your stack so the testing is as high-fidelity and extensive as possible.
the "mocks data when it doesn't have access" line is the scary part to me, a mocked call that quietly diverges from the real service gives a false pass that looks more trustworthy than static analysis. do you flag which parts of the evidence pack came from a mock vs a live call?
@sabber_ahamed Great question! This failure mode is exactly what we designed the reporting around.
Yes, every test result says exactly what was mocked and what was real. Every result carries a mandatory "stub/mock context" field describing any mock, stub, or intercepted call that touched that specific test. When nothing did, it says so explicitly. A pass that leaned on a mock never looks the same as a pass against the live service.
That being said, your fear is very real and I just wanted to mention a few guardrails we have around this. The first is that mocks are the last resort, not the default. Ito stands up real dependencies first (real local databases and queues, real third-party calls when teams share test credentials), and it is only allowed to mock a narrow dependency call, never the system under test. The second is that every result also has to be backed by recorded evidence (screenshots, DOM snapshots, action logs) that a verification pass checks before the result counts. Finally, we have agents that judge each finding against the evidence, the codebase, and the diff, and actively try to argue against those findings so that they detect cases like this up front and prevent them from making it into the final report.
Trust is the product, so we are careful about what earns it.
Thanks again!
Really interesting approach to code review. The fact that Ito actually runs the app and returns runtime evidence makes this feel much more actionable than reviews based purely on diffs. Especially compelling for the edge cases static analysis can miss. Congrats on the launch! 🚀
@steve_tubeiq appreciate the kind words! It's not only edge cases, but also things that only occur when the code is actually running. This is a large class of specific errors that static tools miss.
DiffSense
Question: How do you compare with Greptiles Trex feature?
Ito
@conduit_design Ito's made execution the review.
We provision your complete application (backend, frontend, seeded database, external services, working auth, secrets injected at runtime) and then test the way a 100x engineer would. We find things that come from running the system, not from what a code reader suspected.
The way you phrased "a feature" means you probably already know this, but Greptile's bolted on a sandbox (easy) to validate static review's hypotheses. All real products have external dependencies and cannot take credentials, TREX is limited to mocks, UI clicks, and unit tests without anything. Real apps lean on S3, Stripe, auth providers, etc to
Execution as the foundation is our whole product.
DiffSense
@grayson_cooper1 What languages do you support? The reason Trex is limited is also the reason why it works. Trying to solve 4D Chess ...i mean ... true end to end auto testing is almost impossible. its sprawls into immense complexity fast. What areas do you focus on and which areas do you not focus on? I went to the website. but it has no. We support this. and we dont support this section. Which should be there, so it avoids turning down users that determine this is over promissing and exit fast etc. Do you know what I mean?
@grayson_cooper1 @conduit_design That's a very good point. Currently we don't support ios & osx so iphone apps and macosx. We focus on things that can run in a linux box. It's a pretty wide range of tools that extends beyond websites. For example, Dolthub uses us for database software QA: https://www.dolthub.com/blog/2026-07-20-ito-ai-qa-for-doltgresql/