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
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.
Metla
congrats!
Ito
@levon377 Thank you! We're excited 🚀
Hi, I'm Geoff, a software engineer on the Ito team. 👋
The thing I love most about Ito: it actually runs the code. 🚀 Every PR I open comes back with a test plan that was
executed, not just read.
⚡ Automates the manual testing I used to do by hand — click through the flow, check the edge cases, confirm nothing else broke. That's hours back every week.
🐛 Catches bugs I would have missed. Real runtime failures that linters and static analysis structurally can't see,
because they never execute anything.
🤖 Makes agentic loops genuinely feasible. When an agent writes the code, something has to verify it actually works
Ito is that step, so I can let the loop run longer and trust what comes out the other end.
Getting to build this as an engineer who also uses it every day has been the most fun I've had on a product. 🎉
Easy to try and see how Ito can help your team: app.ito.ai
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
Ito
Grayson here, one of Ito's cofounders.
I love that the hard part of Ito is often overlooked: generalizing the ability to run code is the difficult problem. Everyone assumes it's a "deciding what to test" problem (which is definitely hard too!). But the challenge of standing up an actual application is insanely hard. Get that wrong and the smartest agent in the world clicks around a broken login page.
Internal teams at DoorDash or Ramp have spent quarters of engineering time trying to build this internally because they know it's important. Most teams cannot, and shouldn't have to.
That is why runtime review didn't exist until now. Nobody wanted to build the unglamorous layer, and you cannot fake it by bolting a sandbox onto a static reviewer.
That layer is where most of our engineering was spent prior to launch, and it's the reason the reviews surface verifiable bugs instead of suspicions. Just wait to see what else we do :)
Move AI
@grayson_cooper1 What else are you going to do? I hope reply to this so you get an engagement bump. :)
Ito
@philsalesses Reliably getting an app built allows us to explore: smoke testing, demos for your how to guides & support articles, issue reproduction (datadog, posthog, etc), coding agents, design / ux feedback, performance testing, security testing, etc
The world is our oyster, but the customers will guide us
Earth.fm
The combination of isolated environments + agent-driven testing + runtime evidence is what really stands out here. Curious to see how well Ito handles complex state, flaky external services, and large monorepos.
Ito
@1mirul We're up for any challenge 💪 For larger enterprises, we do implementations to ensure success in complexity as often there are coordinations among teams that can be required (although less than you think!).
CheckYa
Really interesting approach! How does Ito handle cases where the app environment can't be fully reproduced because of private services, credentials, or production-only dependencies?
Ito
@monir_ If teams are unable or unwilling to provide those details, Ito will stub / mock things it doesn't have and provide that evidence back to users. Here's an example
@monir_ @grayson_cooper1 To add to this, you can configure the app environment with access to credentials & private services through the settings.