The IDE that verifies its own work
There is a moment every developer who has used an AI coding tool knows: the model presents a confident wall of code, you paste it in, and it doesn't run. The demo was the generation. The debugging is yours.
We built OIOXO around a different contract: the IDE has to verify its own work before it shows it to you. Not "looks plausible" — actually executed, actually checked, on your own device.
What "verified" means here
When you describe a project and OIOXO builds it, the agent doesn't stop at writing files. Each step runs a loop:
- Plan the change.
- Write the code.
- Run it — in real runtimes that execute in your browser (Python via a full interpreter, JavaScript and TypeScript, live previews for web projects).
- Check the result against a real oracle.
- If it fails, read the actual error and repair. Then run again.
The oracle is the important word. An oracle is something outside the model that can say no: your test suite, the type checker, the runtime itself throwing an exception. If the project has tests, OIOXO detects the test runner and uses it. If it's TypeScript, the compiler gets a vote. "Done" is not a feeling the model has — it's a state the oracle confirms.
Guarding against the lazy shortcuts
Once you make tests the finish line, a small model will discover the obvious cheat: delete the failing test. So the loop explicitly rejects changes that make the oracle weaker — a "fix" that removes or guts tests is thrown out and the agent is told why. The same applies to regressions: if a candidate change makes previously-passing checks fail, it doesn't ship. The bar only ratchets one way.
When the agent gets genuinely stuck, it doesn't grind the same broken idea forever. It generates several diverse candidate fixes at different temperatures and lets the oracle — not the model's own opinion — pick the one that actually passes. A model grading its own homework is marketing; a test suite grading it is engineering.
And before the loop declares a build finished, a reviewer pass reads the result against what you asked for. Only then do you get the green.
The same contract, everywhere
This isn't a demo-page behavior. The terminal agent (oioxo code) reads your repo, makes the change, and runs your checks — your tests, your typecheck — on your machine before it even shows you the diff and asks to apply it. In the editor, every AI edit is followed by a verification of the touched file, and the toast that says the edit is verified means the check actually ran. Press Alt+Enter and Fix-next repairs the next problem, then confirms the file is clean and tells you so.
Why on-device makes this honest
Everything above runs on your device — the model, the runtimes, the tests. That has a privacy benefit we talk about a lot (your code never leaves your machine), but it has a verification benefit too: the environment that checks the code is the environment the code will live in. There's no "worked on our servers" gap. When OIOXO says your Python passed, it passed in a real interpreter that just executed it, in front of you.
None of this makes the model infallible. Small on-device models write wrong code all the time — that's precisely the point. A system built on "the model is probably right" fails quietly. A system built on "the model must convince the oracle" fails loudly, in private, during the loop — and what reaches you has already survived the thing that was trying to kill it.
That's the whole product philosophy in one sentence: don't trust the demo, trust the green.