We recently announced our roadmap for Libra: 256 logical qubits, a megaquop system planned for 2028, with a gigaquop system following in 2028/2029. Getting collaborators ready for that launch means building the software that will power Libra now, well before the hardware itself exists, so teams have enough time to prepare instead of starting cold on day one.

Why simulators are where readiness starts

You can't hand someone hardware that doesn't exist yet. What you can hand them is an accurate model of how it will behave, and let them start building against that. That's the practical role simulators play in a roadmap like this: they're how a research group, a software team, or an HPC center can start writing programs, testing assumptions, and finding the rough edges in their own workflows years before a fault-tolerant system is sitting in a data center.

That's also why we think of simulation as more than a testing convenience. Done well, it's a shared surface where QuEra and the organizations we work with can collaborate on what fault-tolerant neutral-atom computing will actually look like in practice, before the hardware itself is the bottleneck. The more faithfully a simulator reproduces the real machine, the more that early work translates directly to Libra when it ships.

What changes at fault-tolerant scale?

Most quantum simulators weren't built for a machine like this. They model the circuit and stop there: a fixed sequence of gates, applied in order. That's a reasonable model for near-term hardware, but this approach to software design breaks down for a fault-tolerant system.

Atom movement becomes part of the program. One of the advantages of neutral atoms is that we can physically move them mid-computation to create connections wherever they're needed. At fault-tolerant scale, some of those movement decisions can only be made in real time, based on measurements taken as the program runs. Movement can't stay hidden inside a compiler pass; the software has to reason about it while the machine is running.

The machine becomes asynchronous. Loading fresh atoms, decoding errors, detecting atom loss, and producing the magic states used for certain operations all run on their own timelines, each able to succeed, fail, wait, or get consumed by another part of the computation. It's the same complexity anyone who has written concurrent classical software will recognize, and the fix is the same one classical engineering has always relied on: build the ability to reason about timing, events, and failure directly into the languages, compilers, and runtime.

Scale itself is a new variable. Libra runs more than 10,000 physical qubits carrying 256 logical qubits, a size at which no fault-tolerant software stack, including ours, has yet operated. At that scale, programs stop looking like short, static circuits. They get wider, run longer, and expose far more parallelism, which means compiling and verifying them takes real co-design with the hardware architecture, not a compiler working in isolation.

These aren't three separate problems to solve one at a time — movement, asynchrony, and scale all show up in computation simultaneously. What we need is a digital twin: a single model that holds the quantum operations, the noise, the control logic, and the decoding together. That's the direction our software team has been building toward.

What is PPVM?

PPVM, the Pauli Propagation Virtual Machine, is the first public piece of that effort. It's a circuit-level simulator that emulates noisy quantum hardware alongside the classical logic controlling it.

Under the hood, PPVM is a combination of four different simulation methods, each suited to different kinds of circuits, all driven by the same instruction set. It models the error processes that are dominant in neutral-atom hardware, including several distinct forms of atom loss, gate noise, and more. We've also connected PPVM to a real quantum error correction decoder built by Microsoft, which lets us simulate adaptive, error-corrected programs end to end rather than idealized circuits in isolation.

Built differently: software written with an AI agent

As these simulation methods multiply and the space of possible implementations grows, hand-tuning performance the traditional way, months of manual profiling and rewriting, gets slower precisely as the software gets more complex. That's a natural place for an AI agent to help: exploring a large space of implementation choices quickly, provided there's a rigorous way to check that each change is actually correct.

That's how PPVM's performance work was done. Rather than manually optimizing every part of it, the team built an AI agent called autotune to search for faster implementations, working inside a harness with explicit goals and automated evaluation. The agent proposed changes, measured their effects, and kept the ones that worked. Separately, the team formalized core concepts like Pauli propagation and generalized tableuas, to catch bugs and protect the software as it evolves. The result was substantially faster than PPVM's original hand-written version, built in far less time than the traditional process would have taken.

We see this as an early example of a broader shift we're paying attention to: using AI agents not just to write code, but as a genuine part of how rigorous scientific software gets built and optimized.

Preparing for Libra, together

PPVM is useful today as a simulation tool on its own. It's also a foundation. Before a complete digital twin of a fault-tolerant quantum computer exists, one that faithfully reproduces quantum operations, noise, control logic, and decoding all at once, we need a working way to represent and run all of those pieces together. PPVM is our first version of that.

It's also, practically, one of the clearest ways for other organizations to start engaging with this roadmap now. A team can begin prototyping logical-scale programs, testing assumptions about noise and control, and building familiarity with the software stack years before Libra is physically available, so that readiness isn't something to figure out on Day One.

But building that software stack, realistic emulation, compilation, verification, isn't something any one company can work out alone. That's part of why we're co-organizing the first Workshop on Compilation, Emulation and Verification of Neutral Atom Computing (CEVNAC 2026), held alongside IEEE Quantum Week in Toronto, to bring hardware researchers, compiler and language developers, verification experts, and application scientists together around exactly these challenges.

For the full technical picture, we've published two deeper posts on the Bloqade blog:

• Introducing PPVM: A Step Toward a Quantum Digital Twin, covering how PPVM's four simulation methods work, its noise modeling, and the benchmarks behind the autotune agent.
• Building the Software Stack for Fault-Tolerant Neutral Atom Computers, covering the full stack vision, atom movement trade-offs, and the lane architecture data from our Gemini-class testbed.