Ito - AI code review that runs your code
by•
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.
Replies
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.
Hi, I'm Barron Caster, Co-Founder of Ito AI.
The thing I love most about Ito: gives me confidence to ship fast as a non-engineer. I've fully taken over our marketing site and don't have to bother engineers to check my code.
Vibecoding our entire marketing site & infra (design, content, performance improvements, SEO, etc)
Knows entire context of our codebase so nothing gets left behind. Can request specific tests if I want them (e.g. focus on mobile usability of the blog)
Videos of everything working for every change (and feature demo videos coming soon)
Now the whole team is shipping faster.
Easy to try and see how Ito can help your team: app.ito.ai?ph
Averi
@barroncaster congrats on the launch! ito seems like the perfect partner product to the revolution of vibe coding for those of us who aren't engineers.
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.
ProductBridge
The runtime approach to code review is really interesting. Instead of just analyzing what the code looks like, Ito actually checks how the application behaves in real scenarios and backs the findings with evidence. The combination of agent swarms and isolated environments makes this especially relevant as AI-generated code keeps increasing.
@hareesh_vemasani Exactly! We strongly believe that this is the future of code review as it opens you up to find new classes of bugs that simple static code analysis misses. As it becomes increasingly easy to generate code, the need for this type of analysis will only continue to grow; and Ito will be there. 🚀
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.
It's a neat approach that is differentiated from and complimentary to the standard AI review tools. We use it and it has surfaced bugs other tools missed on multiple occasions.
The team moves fast too and is very responsive to feedback. They are a pleasure to work with.
@daniel_kokotov Thank you!
The "complementary, not competing" framing is exactly how we think about it too. Static review tools are great at reading code; we wanted something that would go run it. Hearing that it's surfaced bugs other tools missed, more than once, is the single best signal we could ask for.
And the feedback loop goes both ways — a lot of what's shipped recently came straight from users telling us what wasn't working. So please keep it coming. It's a pleasure working with you too.
I like the ephemeral env per PR idea - less guessing from a diff
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/
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!
Can I run it on my local machine?
@mohsen_bashirzadeh cloud only for the moment!
Ito
@mohsen_bashirzadeh Is the goal that you have control of the testing, because you can do that from the PR description which we already take into account :)
@grayson_cooper1 Because of security.