How IBM Used OpenEvolve to Discover Quantum Error Correction Codes

IBM Research used OpenEvolve to search for new quantum error correction codes, evolving Python programs that generate bivariate bicycle code candidates - the code family at the heart of IBM's fault-tolerant quantum computing roadmap. Across five evolution campaigns totalling roughly 1,650 iterations, about 200,000 screened candidates, 140 hours of compute and around US$400 in LLM inference, the pipeline discovered 465 distinct candidate codes, including a weight-8 [[288,50,8]] code that encodes 50 logical qubits at certified distance 8 (the previously published weight-6 record was k = 16) and a new [[288,16,12]] code whose distance was certified exactly. To the authors' knowledge, this may be the first full account in the published literature of LLM-guided program evolution applied to quantum code discovery.
Paper: arXiv:2606.02418 | IBM blog: AI for QEC | Code: qcode-discovery on GitHub

The Problem: A Vast, Gradient-Free Design Space

Quantum information is fragile. Error correction protects it by encoding k logical qubits into n physical qubits, with the code distance d measuring how many errors the code can tolerate - the whole game is finding good [[n, k, d]] trade-offs. Bivariate bicycle (BB) codes are the family IBM has built its fault-tolerant roadmap around: the [[144,12,12]] "gross code" achieves a pseudo-threshold of roughly 0.7% with a 10× reduction in qubit count versus the surface code.

But the landscape around the gross code was barely explored. Every pair of trinomials over the ring F₂[x, y]/(xℓ − 1, yᵐ − 1) defines a valid BB code - on the order of ℓ⁶m⁶ candidate pairs per lattice, with no gradient structure to exploit, and computing a code's true distance is NP-hard in general. Before this work, all published weight-6 BB codes had k ≤ 16, and whether higher encoding rates were achievable at practical block lengths - and at what cost to distance - had never been systematically investigated.

This is exactly the shape of problem OpenEvolve was built for: a rich combinatorial space, a well-defined evaluator, and no obvious hand-designed search strategy.

The Key Move: Evolve Programs, Not Codes

Rather than mutating individual codes, the IBM team used OpenEvolve to evolve a generator ansatz: a Python program that produces candidate polynomial pairs for any lattice dimensions. At each iteration, the LLM receives the current highest-fitness ansatz, domain knowledge about BB code algebra, and evaluation feedback, then proposes a targeted code diff.

The ansatz representation is what makes the approach powerful. A single mutation can express an algebraic pattern - "use x^(ℓ/3)", say - that generalizes across all lattice dimensions at once, biasing the search toward algebraically regular families instead of one-off lucky hits. One evolved ansatz can discover codes across multiple block lengths simultaneously.

The search used OpenEvolve's MAP-Elites archive with the population distributed across 4-6 islands, with migration every 12-25 iterations. The behavioral dimensions were chosen to reward both breadth (how many lattices yield codes with k ≥ 8) and depth (how many such codes in total), preventing collapse onto a single lattice-specific solution.

An Evaluation Cascade Built to Catch False Discoveries

Verifying a quantum code is expensive, so candidates flow through a staged pipeline where each stage is only paid for by survivors of the previous one:

1. k-only screening (~2 s): compute the number of logical qubits exactly via GF(2) rank on two small lattices. This is cheap, exact, and filters out roughly 30% of mutants immediately.
2. BP-OSD distance estimation (~30-60 s): belief propagation with ordered-statistics decoding gives a fast stochastic upper bound on distance for the top candidates across 8 lattices spanning n ∈ {144, 288, 360}.
3. MILP exact verification: mixed-integer linear programming certifies distance exactly (or returns a rigorous upper bound), applied in-loop for top candidates in the later campaigns.

After each campaign, every surviving code went through post-campaign verification: MILP distance computation on everything, BLISS Tanner-graph deduplication, decomposability analysis, and Clifford-equivalence checks. The staged design meant the system could evaluate ~200,000 candidates while running full MILP verification on only the ~400 codes that mattered.

Five Campaigns for US$400

*Campaign 2's discoveries all turned out to overlap with Campaign 3's output after deduplication. Counts are not additive across campaigns: discoveries overlap, and after cross-campaign deduplication the CSS campaigns net out to 97 distinct codes.

Campaigns 2-3 used an ensemble of Claude Opus 4.6 (Anthropic), GPT-5.2 (OpenAI) and Gemini 3 Pro Preview (Google) with equal selection weight; Campaign 4 updated the ensemble to Claude Opus 4.6, GPT-5.3-Codex and Gemini 3.1 Pro Preview with a higher sampling temperature to encourage more radical mutations in the larger polynomial space. The entire discovery effort - all five campaigns plus ablations and exploratory runs - cost about US$400 in LLM inference and ran on a single workstation and one 64-core server.

What the Search Found

At block length n ≤ 360, the workflow identified 465 distinct candidate codes: 97 CSS bivariate bicycle codes and 368 non-CSS perturbed variants (distinct up to Tanner-graph equivalence). The highlights:

Along the way the team introduced a genuinely new construction: perturbed bivariate bicycle (PBB) codes, a non-CSS ansatz that augments the standard BB stabilizers with two perturbation polynomials, creating stabilizers with mixed X and Z support. Of the 368 PBB codes discovered, 357 were verified to be inequivalent to any CSS code under all tested local-Clifford patterns.

Beyond individual codes, MILP verification across the full catalog mapped out an empirical rate-distance trade-off for the BB family: among weight-6 codes, the indecomposable d = 12 codes are limited to k ≤ 16, while every code with k > 24 has d ≤ 4. Higher-weight codes reach new (k, d) combinations but do not escape the envelope. In code-capacity simulations under the paper's decoder setup, the indecomposable d ≥ 12 discoveries achieve gross-code-level pseudo-thresholds while encoding up to 1.7× as many logical qubits - though the authors are candid that no discovered indecomposable code exceeds the prior best figure of merit at its own block length, and that circuit-level noise simulations are still needed to assess practical fault-tolerant performance.

The Verification Story Is Half the Result

Some of the paper's most valuable findings are about what happens when you don't verify exactly:

• BP-OSD systematically overestimates distance for high-rate codes - by up to 12×. Under a multi-decoder verification protocol, 147 of 154 trinomial code representations had their distance bounds tightened. Distance claims for high-k BB codes genuinely require exact methods.
• The A = B distance trap: every BB code whose two polynomials are equal has distance exactly 2, regardless of check weight - the paper proves it. The evolution initially converged on these codes, which achieve arbitrarily high k while providing no meaningful error correction. BP-OSD failed to detect the trap even at 1.5 million trials, reporting d ≤ 14 for a code whose true distance is 2; MILP catches it in under one second.
• A code that looked like a record wasn't: the apparent highest-k CSS code at d = 12, a [[288,24,12]], turned out under Tanner-graph analysis to be a direct sum of two gross codes - two independent known codes wearing a trench coat. The pipeline detected and excluded it.

This is the deeper lesson of the work: in domains where the fitness signal itself can lie, the pipeline architecture - screen on what you can compute exactly, defer expensive verification, and independently audit everything that survives - matters more than any single discovery.

Does the LLM Actually Matter?

The team ran the ablation everyone should run: the same search with a classical genetic algorithm on the same ansatz representation, plus uniform random search at matched budgets. The GA racked up a higher raw logical-qubit score - but exclusively by converging on the d ≤ 2 trap codes. Random search showed sharply diminishing returns, with a 10× budget increase buying only a 1.7× improvement.

The LLM's mutations were qualitatively different. Campaign 1's best ansatz emerged just five mutations from the seed, and its largest fitness gain came from the LLM independently inventing a "pure-axis" (univariate) generation strategy after observing that the highest-k code used separated variables - the kind of structural insight that syntax-level mutation operators cannot produce by construction. The highest-k codes the evolution found later turned out to be equivalent to hypergraph products of cyclic codes, a known construction the search converged on independently.

The paper is appropriately cautious about this ablation: the arms differ in evaluation budget (213,000 versus 14,000 evaluations), the GA arm received no distance feedback, and the LLM's own fitness signal in the early campaigns was inflated by BP-OSD overestimation - so the comparison is suggestive rather than definitive.

What This Means for OpenEvolve

This work extends OpenEvolve's track record into a new domain - after systems algorithms, GPU kernels and mathematical discovery, quantum error correction. A few patterns keep repeating:

• Evolving programs beats evolving artifacts. The generator-ansatz representation let single mutations express algebraic ideas that generalize across problem instances - the same lesson as evolving kernel-generation strategies rather than kernels.
• Cascade evaluation makes expensive domains tractable. Cheap exact screening first, stochastic estimation second, exact certification last. IBM's k-then-distance cascade mirrors the small-input-first cascades used for GPU kernels.
• MAP-Elites diversity pays off in rugged landscapes. Behavioral dimensions rewarding breadth across lattices kept the search from collapsing onto single-lattice solutions or trap families.
• The evaluator is the product. The discoveries here are inseparable from the verification pipeline around them; OpenEvolve provides the search engine, and domain teams win by investing in evaluators that cannot be gamed.

Everything is open source: the evolved programs, LLM prompts and diffs, MILP formulations, the verification pipeline, and complete code catalogs are available at qiskit-community/qcode-discovery, built on OpenEvolve. If you are exploring structured discovery problems with reliable evaluators - in quantum computing or anywhere else - this is a template worth copying.