Stab - Agent-native QEC simulation toolkit

Inspiration

I came to Stab through my research in visualization and human-computer interaction for quantum computing. One direction I care about is building better tools that help quantum-computing researchers understand and develop quantum error-correction.

When I spoke with QEC researchers about their tools, I kept hearing a similar answer: they use Stim as it is. Stim is the field’s fast, battle-tested simulator, and it supports the workflows researchers depend on today. But some researchers also want capabilities beyond its current scope, such as support for non-Clifford gates, and they do not know how to extend the simulator themselves.

I understood that hesitation. Stim is a highly optimized C++ project with specialized vectorized paths. It is safe and reliable to use, but modifying that kind of systems code requires expertise that many QEC researchers, including me, do not have. Coding agents can help navigate the code, but C++ still contains memory, aliasing, and architecture-specific footguns. A crash would be inconvenient; silent corruption that changes a scientific result would be much worse.

That led me to a question: what should QEC infrastructure look like when researchers increasingly work alongside AI coding agents?

What Stab Is

So, I developed Stab, an agent-native toolkit for quantum error-correction research, written in safe Rust and designed so that researchers and their agents can modify it with confidence.

Its first milestone is a drop-in replacement for Stim v1.16.0. Stab implements the same seven CLI commands, reads the same circuit and detector-error-model formats, and streams the same result formats. Its circuit generator produces byte-identical output to Stim for the same supported arguments, including comments.

Compatibility is the first step to trust, but my longer-term direction is a set of composable Rust components for QEC tooling, with room for capabilities such as non-Clifford gates.

How I Built It

I built Stab with OpenAI Codex and GPT-5.6, with GPT-5.5 used during earlier stages before GPT 5.6 got released. Codex implemented the product code. GPT-5.6 helped plan and build much of the test, benchmark, and audit.

The project execution is pretty much a loop. Each milestone began as an explicit plan describing the behavior to implement, the tests and benchmarks that should prove it, and the work that remained out of scope. Repository-level instructions in AGENTS.md constrained how agents handled compatibility, public formats, typed boundaries, hostile inputs, performance claims, and documentation. Goal files gave long autonomous sessions a concrete definition of completion.

Rust provided the initial code checking. Stab uses safe Rust with zero unsafe code, enforced by linting. Ownership, lifetimes, exhaustive matching, typed domain boundaries, and strict error handling turn many potential mistakes into compiler feedback before I need to review them.

The compiler cannot prove that a quantum simulator implements the correct behavior, so the next I asked GPT 5.6 to compare Stab against Stim v1.16.0 as reference, in terms of both correctness and performance.

Finally, I added two custom review skills. The full-code-review skill examines the repository across nine lanes, including code quality (including Rust Idioms and the use of legacy Rust APIs, etc.), Stim compatibility, CLI and file formats, SIMD and performance, security, architecture, tests, and documentation. The milestone-audit skill reviews the milestone itself, looking for ambiguous acceptance criteria or loopholes that could allow an agent to satisfy the text without delivering the intended result.

Challenges I Faced

The hardest challenge was controlling a large autonomous effort when I was not personally familiar with every computational trick and optimization used inside Stim.

Some agent sessions ran for days. At that scale, ordinary code review is not enough, despite that my previouse research has done some work in that area. I could not credibly validate every low-level algorithm and optimization by inspection, so I shifted the question from “Does this code look right?” to “What independent evidence would make an incorrect implementation fail?” That shift produced the oracle corpus, case-level evidence rules, digest-bound qualification reports, explicit performance prerequisites, and adversarial milestone audits. But in the end, it's ultimately about limited human oversight and AI alignment that is still being worked on, unfortunately.

Performance created another tension. I wanted the safety and readability of Rust without abandoning vectorization. Stab isolates portable std::simd kernels behind safe abstractions, which is great and one of the reasons I chose Rust. Some qualified kernels outperform Stim, while other paths still need more work.

What I Learned

Pretty much everything of AI harness that everyone else has learned:

• in agent loops, human experise is even more important, as we still need to judge the quality of the plan, the tests, and the milestone itself
• beside the plan, just let agents run

Beside, I just learned a lot about algorithms and tricks in QEC simulation.

What's Next

• Stim compatibility is basically done, but I still need to push agents to do more performance work, including proper performance benchmarks.
• after that, I will work with QEC experts to add more QEC features, like non-Clifford gates, and to turn Stab into a set of reusable Rust components for QEC tooling.
• and sometimes wait for Codex Credit Resets :)

Built With

• codex
• gpt5.5
• gpt5.6
• rust
• simd