Can LLMs discover quantum error correction codes?
IBM Research
IBM used LLMs to auto-generate quantum error correction codes instead of hand-deriving them. The AI found 465 new candidates, including one with 3x the logical qubits of the previous record.
Based on reporting by IBM Research — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Quantum computers have a fragile-data problem. Qubits flip and decohere so easily that without error correction, any serious computation falls apart before it finishes. The fix is redundancy — spreading one logical qubit's worth of information across many physical qubits so errors can be caught and fixed. The catch is that the space of possible error-correcting codes is enormous, and sifting through it by hand has historically been slow, mathematically brutal work.
IBM researchers just tried handing that search off to large language models. In a new arXiv paper, they describe a workflow built on OpenEvolve, an evolutionary framework descended from Google's AlphaEvolve and FunSearch, that gets an LLM to propose algebraic formulas for bivariate bicycle codes — the qLDPC code family IBM has bet on for its fault-tolerant roadmap. The model doesn't just guess randomly; it's fed known good examples and target properties, then writes Python scripts that generate candidate codes, which get scored and fed back so the next round of guesses is smarter.
The filtering pipeline is where the real engineering lives. Every code gets described in [[n,k,d]] shorthand — physical qubits, logical qubits, and error tolerance — and there's no way to max out all three at once, so the team built a three-stage funnel to find the worthwhile trade-offs. Cheap k-only screening tosses obvious duds first. A faster-but-imperfect decoding method called BP-OSD narrows things further. Only the strongest survivors get run through mixed-integer linear programming, an exact but computationally expensive check that confirms whether a code actually delivers on its promised distance.
The haul from this first pass was 465 previously unknown codes, some genuinely striking. One packs 50 logical qubits into a structure where the prior best in its family topped out at 16, though its error tolerance is too low for that to matter much in practice. Another needs just 72 physical qubits, which could appeal to hardware that struggles to scale qubit counts. More encouragingly, a handful of new codes — like [[288,16,12]] and [[360,12,≤24]] — land in a balanced enough spot that their predicted noise performance is in the same neighborhood as IBM's own [[144,12,12]] gross code, the one slated for its fault-tolerant machines.
None of this proves any of these codes will end up in real hardware; that verdict needs a lot more testing outside simulation. But the bigger takeaway is about method, not any single code: a framework that can churn through thousands of algebraic variations and flag the interesting ones changes how fast this kind of search can move. IBM is open-sourcing the whole pipeline on GitHub, essentially inviting other labs to point it at their own code families and see what falls out.
My take — AI-written commentary, not fact-checked reporting
This is the AI-for-science story I actually buy — not a chatbot claiming to reinvent physics, but a boring, well-instrumented search tool that turns months of algebra into an afternoon of compute, with hard verification steps that don't let the LLM cut corners. Open-sourcing it is the right call too, since the value here is clearly in the pipeline, not in IBM hoarding one clever qubit count as a headline.
Read more about this at: IBM Research