To know what the code does, you have to run it.

Reading code tells you what it says. Running it tells you what it does.

A diff can look completely reasonable and still break the moment real data moves through the system. The logic error that causes a token refresh to run after a redirect instead of before it is not visible in any single file. An off-by-one in date handling that only surfaces in a specific timezone needs a real session and real routing to appear. A drag-and-drop reorder that writes to local state and never calls the API looks correct in every static view of the code.

None of these is a careless diff. Each one depends on timing, state, or an integration path that reading cannot observe. Static analysis and code review are useful for what they do: surface likely problems in the code as written. The failure class they cannot cover is the one that only appears when the application runs.

Code that passes review and breaks in production is not a code quality problem. It is a visibility problem. That is the gap Ito is built for: running your application on every PR so the behavior is observable before the merge.

What only appears when you run it

The bugs that reach production share a shape. They read cleanly in the diff, pass static checks, and survive code review. They break the moment a real user reaches them because the failure lives in behavior, not in code structure. These are the cases Ito is built to catch:

Auth and session flows. A returning user opens the app to finish a purchase. An expired session drops them into a login loop because the token refresh check runs after the redirect instead of before it. The test against the refresh helper is green. The loop only appears with a stale token and real routing.

Data persistence. A drag-and-drop reorder looks correct in the UI, then reverts after the user navigates away and returns, because the reorder writes to local state and never calls the API. Every static view of the code looks fine. The failure lives in the round trip.

Third-party integration paths. A mocked dependency passes. The real one returns something the code did not expect, and the payment never clears or the confirmation never goes out. These flows only surface when the live path runs.

Race conditions. Two actions hit the same shared resource at the same moment. The outcome depends on timing that no diff review can reproduce.

Permission boundaries. A change that looks UI-only turns out to affect what a lower-privilege user can reach. The access control holds in isolation and breaks in the flow.