In Quantum's Race to Fault Tolerance, Hardware and Software Rise Together

Dr. Kris Naudts, Zeynep Koruturk (Founding & Managing Partners) & Donald Harmitt (Associate) at Firgun Ventures.

Fault tolerance is the milestone the quantum industry is racing towards, the point at which a quantum computer corrects its own errors faster than they accumulate. It is usually framed as a hardware problem, a matter of building enough good qubits. Yet the unit that defines it, a logical qubit (qubit that is encoded using a collection of physical qubits to protect against errors) that compensate for the delicate physical parts beneath it, is barely hardware at all. It is a hybrid of the physical device, the code that organises it and the classical decoder that reads it, and most of that stack is software. When Google’s Willow and Quantinuum’s Helios crossed below the error-correction threshold in 2024 and 2025, respectively, hardware and software got there together, not because either pulled ahead.

The general framing misses that co-dependency, telling it as a race between ever-bigger hardware and a transformative payoff, with software a supporting act. The more accurate picture is a co-evolution, in which software is compressing the cost of useful computation faster than hardware is expanding raw capability, while hardware advances in the places that let those software gains land. Neither reaches fault tolerance alone, and who is winning depends entirely on what is being measured.

Software Is Shrinking The Problem Faster Than Hardware Is Growing It

A straight comparison between the quantum hardware and software is rigged from the start, because the sides do not report in the same currency. Hardware comes with clean, marketable metrics: qubit count, gate fidelity (measures the accuracy of operations), coherence time (duration a quantum system can maintain its delicate quantum state), and connectivity. Software’s contribution can come across as nearly invisible, because a better algorithm reduces the demands on the hardware rather than announcing itself directly. If the question posed is whether the machines are getting bigger, then hardware is clearly winning. IBM’s Starling roadmap targets 100 million operations on 200 logical qubits by 2029, with a billion-operation follow-on, Blue Jay system, with up to 2,000 logical qubits. Those numbers demonstrate the importance and scaling potential of the hardware aspect within quantum computing systems.

If the question is how much useful computation each qubit yields, then software is winning, and not narrowly. The clearest illustration is the most quoted benchmark within the industry, the cost of breaking RSA-2048, an industry standard public-key cryptographic algorithm used to protect a large proportion of our sensitive data. In 2019 Craig Gidney and Martin Ekerå estimated that factoring a 2,048-bit key would need 20 million noisy qubits running for about eight hours. By May 2025, Gidney had cut that to fewer than one million noisy qubits, and in February 2026 the Pinnacle Architecture pushed the figure below 100,000 physical qubits using quantum low-density parity-check codes. None of those reductions involved building a single new physical qubit; each came from better algorithms, codes and compilation.

The same pattern repeats across the stack, and the examples are not isolated. Across the quantum computing stack, researchers are finding large gains simply by making the software, algorithms, and machine design work together more intelligently. In quantum chemistry, a recent study revisited cytochrome P450, a complex enzyme used as a demanding benchmark, and found that smarter ways of representing the molecule and mapping the calculation onto a proposed quantum architecture could reduce estimated runtimes by roughly two orders of magnitude. The same idea appears in compilation, the process of translating a quantum algorithm into instructions a machine can actually run, where a 2025 Cambridge compilation study showed that relatively simple methods could cut the number of qubits needed by as much as 60%, with only a modest increase in execution time. Taken together, these examples suggest that the path to useful quantum computing depends as much on careful system and algorithmic design, as on headline qubit counts. 

These gains are more powerful than they first appear, and the reason is leverage. A better chip improves one generation of hardware, but a better algorithm, compiler, or error correction scheme can change the economics of many machines at once, including systems that have already been designed but not yet built. For anyone judging proximity to utility-scale fault tolerance that argues for weighting algorithmic and error-correction progress above qubit-count headlines, it is worth stating that these software advancements are resource estimates under stated assumptions, not yet proven demonstrations. Despite this, for anyone trying to assess how close the field is to practical utility, advances in algorithms, compilation, and error correction deserve at least as much attention as the headline scale of the hardware.

Error Correction Is The Bridge Between The Two Halves

This is where the dichotomy starts to disintegrate, because a logical qubit’s error rate is not set by either hardware or software quality alone, and emerges from the hardware quality, error-correcting code and the decoder. Much of the frontier error correction metric is inherently hybrid, which is why the hardware-versus-software framing breaks down on further inspection. The clearest example is the move beyond surface codes (arrangement of codes usually mapped into 2-D nearest neighbour layouts) to quantum low-density parity-check (qLDPC) codes (newer codes which overcome the strict geometric limits of traditional surface codes and reduces physical qubit overhead): IBM’s bivariate bicycle codes reach an error threshold close to 0.7%, comparable to the surface code, while encoding roughly an order of magnitude more logical qubits per physical qubit. That is a coding-theory advance, particularly coding and decoding architecture, pulling fault tolerance forward as much as raw qubit growth would.

Three less obvious shifts are emerging from the quantum software stack. Firstly, the fastest software gains sit low in the stack, in compilers, codes, decoders and calibration, not in end-user applications. Secondly, quantum software is also becoming more hardware-specific, not more portable, the reverse of classical software’s path, because the best results depend on a machine’s modality, connectivity and noise profile. A programme that works well on Quantinuum’s all to all trapped ion architecture will not make the same trade-offs as one targeting a superconducting chip with fixed connectivity, different pulse schedules, and a different noise profile. Last but not least, the classical computer is becoming part of the quantum machine rather than a remote helper, as NVIDIA’s NVQLink, used by Helios for real-time qLDPC decoding, makes GPU compute an online component of the processor. The field is still developing a shared trajectory for synchronising software readiness with hardware delivery, but that is also the opportunity. As quantum systems become more integrated, a subset of winners will be those that can make hardware, software, control electronics, and classical compute advance as one machine. 

The Software Mountain And The Physical Summit

Quantum software is shrinking the mountain faster than quantum hardware is climbing it, but the summit is still physical. Software improves faster, by reducing the resources useful computation requires. Hardware improves more slowly, but in the more decisive direction, by crossing the physical thresholds that no algorithm can wish away. The binding long-term constraint stays as hardware physics, because the algorithmic reductions will eventually run out and the remaining gap has to be closed by real qubits operating at scale. The realistic answer to who is winning out of quantum hardware or software, is that the question itself is poorly posed. The systems that will achieve scale will be the ones where software reductions and hardware reliability compound rather than compete.

Insights