Quantum · 7 min read

The Cascade Filter: How IBM's OpenEvolve Turns LLM Guesses Into 465 Verified Quantum Error-Correction Codes

IBM Research paired large language models with a staged verification pipeline to discover 465 new bivariate bicycle quantum error-correction codes — and exposed how fast decoders can lie about distance.

By Classy AI News · July 27, 2026

The Cascade Filter: How IBM's OpenEvolve Turns LLM Guesses Into 465 Verified Quantum Error-Correction Codes

Quantum error correction is not short on ambition. It is short on time.

Every serious fault-tolerant roadmap eventually runs into the same bottleneck: the algebraic design space for quantum low-density parity-check (qLDPC) codes is combinatorially enormous, and the codes that matter for hardware — those with favorable trade-offs among physical qubit count, logical qubit count, and error distance — are scattered through that space like ore in a riverbed. Human mathematicians can pan by hand. Supercomputers can sift faster. Neither scales comfortably to the full landscape IBM needs to explore as it pushes toward utility-scale machines built around bivariate bicycle (BB) codes.

In June 2026, IBM Research published a different kind of sieve. In a paper on arXiv and an accompanying open-source release, a team led by Juan Cruz-Benito, Andrew W. Cross, David Kremer, and Ismael Faro described OpenEvolve: an LLM-guided evolutionary workflow that mutates Python programs generating BB and perturbed bivariate bicycle (PBB) code ansätze, then subjects the output to a multi-stage verification cascade before anything earns a place in the catalog. The headline result is quantitative and verifiable: 465 distinct candidate codes at block lengths up to 360 physical qubits, discovered across five evolution campaigns for roughly $400 in LLM inference cost and ~140 hours of compute.

The work is not a claim that fault tolerance is solved. It is a claim that classical AI has become a practical instrument for structured scientific search — and that the instrument only works when independent verification sits downstream of the model's creativity.

Two colleagues reviewing documents together at a standing desk

Why the search space resists brute force

Quantum error correction codes are expressed in the familiar [[n, k, d]] notation: n physical qubits, k logical qubits protected, d the minimum distance (a proxy for how many errors the code can tolerate before logical information is lost). The ideal code uses few physical qubits, encodes many logical qubits, and tolerates many errors. In practice, improving one parameter usually degrades another.

Bivariate bicycle codes — a CSS subclass of qLDPC codes that IBM has placed at the center of its fault-tolerant roadmap — are defined by algebraic polynomials over finite rings. Every trinomial pair over the quotient ring defines a candidate. Symmetries reduce the space, but not enough. Prior systematic searches had catalogued weight-6 BB codes with encoding dimension k ≤ 16 at practical block lengths. Whether higher rates were achievable, and at what distance cost, remained largely unexplored.

That is the gap OpenEvolve targets. Rather than optimizing individual codes at fixed (n, k), the framework evolves programs that generate polynomial pairs across lattice dimensions. A single LLM mutation — "use x^(ℓ/3)" — can express an algebraic pattern that generalizes across block sizes. The search bias shifts from random combinatorics toward algebraically regular families.

Panning for gold: the verification cascade

IBM's blog frames the pipeline as panning for gold, and the metaphor is apt because the LLM's role is deliberately upstream of trust.

The workflow begins with language models acting as mutation operators inside an evolutionary loop built on OpenEvolve, an open-source implementation of techniques pioneered by Google's FunSearch and AlphaEvolve projects. Prompts include the code family, optimization targets, and examples of known good codes. The model outputs Python scripts that generate candidate polynomial pairs.

What follows is not optional polish. It is the scientific core:

  1. Quick screening — GF(2) rank checks and k-only filters discard invalid or uninteresting candidates.
  2. BP-OSD distance estimation — belief propagation with ordered statistics decoding provides fast but imperfect distance bounds.
  3. MILP certification — mixed-integer linear programming supplies exact distance values where optimality is proven, or rigorous upper bounds otherwise.
  4. Structural deduplication — BLISS Tanner-graph analysis, decomposability checks, and local-Clifford equivalence tests remove duplicates and composite codes masquerading as single constructions.

Outcomes from later stages feed back into the LLM prompts, refining the model's guesses over successive evolutionary rounds. Across five campaigns employing six LLMs from three model families, the system performed approximately 1,650 evolutionary iterations and screened on the order of 200,000 candidate codes.

Colorful sticky notes arranged on a planning board for project tracking

What 465 codes actually means

The haul breaks down into 97 CSS bivariate-bicycle codes and 368 non-CSS perturbed variants. Several results are immediately legible to hardware planners; others are cautionary tales about decoder optimism.

Higher logical capacity. The CSS search recovered known high performers and found new finite-length representatives, including an indecomposable [[288, 16, 12]] code with all cyclic shifts within three hops — a balanced trade-off profile IBM notes may compare with the well-studied [[144, 12, 12]] "gross code" planned for its fault-tolerant architecture. The search also reached encoding dimensions as high as k = 54 for CSS codes (prior published weight-6 maximum: k = 16), though MILP analysis shows those high-k families sit on a steep rate–distance tradeoff: indecomposable distance-12 codes appear limited to k ≤ 16, and weight-6 codes with k > 24 imply d ≤ 4.

Hardware-efficient candidates. A code requiring only 72 physical qubits surfaced among the verified set — potentially easier to implement on constrained hardware than larger alternatives, depending on connectivity and noise profile.

Non-CSS perturbations. Campaign 5 explored perturbed bivariate bicycle codes that mix X- and Z-type stabilizer support through additional polynomials. A [[144, 12, 12]] PBB code matches the gross code's figure of merit (FOM = kd²/n = 12.0) with a structurally non-CSS stabilizer pattern. A [[360, 12, ≤24]] candidate reports the highest trusted PBB figure-of-merit upper bound in the catalog (FOM ≤ 19.2), though distance is certified as an upper bound rather than a proven exact value.

The decomposition trap. Tanner graph analysis revealed that a headline [[288, 24, 12]] code is a direct sum of two independent [[144, 12, 12]] gross codes — no error-correction advantage over running two copies side by side. The pipeline's ability to detect and exclude such composites is part of why raw candidate counts overstate practical novelty.

When the fast decoder lies

Perhaps the paper's most operationally important finding is methodological rather than algebraic.

BP-OSD is the workhorse heuristic for bounding qLDPC distances, but IBM's MILP ground truth across the full 465-code catalog shows it can overestimate distance by up to 12× for high-rate codes (k/n > 0.1). One illustrative case: a [[360, 40, 2]] code yielded d_BP ≤ 24 at 150,000 trials while MILP proved d = 2.

The team also identifies a structural "distance trap": all BB codes with A = B have d = 2 exactly — a theorem proved in the paper's appendix — yet BP-OSD failed to detect this even at 1.5 million trials. MILP identifies the trap in under one second.

For non-CSS codes, standard random syndrome sampling fails because achievable logical cosets form a strict subspace; the researchers introduce achievable-syndrome sampling to restore decoder functionality. The takeaway for the broader field is blunt: high-k BB distance claims require exact verification, not a single decoder run with modest trial counts.

Industrial wind turbines at sunset representing scalable infrastructure

AI as instrument, not oracle

IBM positions OpenEvolve as the first full published account of LLM-guided program evolution applied to quantum code discovery — distinct from contemporaneous heuristic searches referenced in the literature but not yet fully documented when the paper was written.

The economics are worth noting. Five campaigns totaling ~140 hours and ~$400 in inference cost produced a catalog that would have been impractical to enumerate by hand. Campaign 3 alone — an ensemble of Claude Opus 4.6, GPT-5.2/5.3, and Gemini 3 Pro/3.1 Pro — discovered 145 CSS codes in 21 hours for roughly $50. That is not trivial money, but it is trivial compared to the human-years implicit in exhaustive algebraic search.

Yet the paper is explicit about limits. Discovering a code is not implementing it. IBM stresses that further work is required to evaluate how these candidates perform on real hardware with realistic noise, connectivity, and decoding latency. Some high-k discoveries converge independently on known hypergraph-product constructions — the evolution rediscovered familiar algebra, which validates the search but does not expand the frontier.

The open-source release on GitHub under the qiskit-community/qcode-discovery repository — including the OpenEvolve integration, verification scripts, and the full verified catalog — invites external replication. That transparency matters: in a field where decoder overestimation can inflate apparent progress by an order of magnitude, reproducible verification pipelines are as valuable as the codes themselves.

The two-way street

Google's July 2026 Nature paper on reinforcement learning for quantum error correction on the Willow processor showed AI steering control parameters while computation runs. IBM's June 2026 work shows AI proposing algebraic constructions while human-designed verification filters decide what survives.

Both directions point to the same conclusion: the path to fault-tolerant quantum computing is increasingly a collaboration between quantum hardware and classical learning systems. The quantum machine generates error syndromes; the classical stack — whether RL agents or LLM mutators — helps navigate spaces too large for either side alone.

OpenEvolve does not replace the mathematician or the experimentalist. It gives them a faster way to ask "what if?" across thousands of polynomial forms — and a cascade filter honest enough to report when the answer is fool's gold.

Close-up of a computer screen showing source code syntax highlighting

Newsletter

Get the dispatch

One field. One email when we publish. Privacy.