An AI invented 465 new ways to protect a quantum computer. None has run on one yet.

The most interesting thing IBM did this month was not build a faster quantum computer. It did not build a quantum computer at all. It pointed a language model at one of the oldest and most stubborn problems in the field — how to keep a quantum computer from forgetting what it is doing — and let the model search a space too large for any person to walk through by hand. The model came back with 465 new error-correction codes, several of them better, on paper, than the ones the textbooks recommend. One of them stores fifty units of protected information where the best previous design in its family managed sixteen.

That is a genuinely remarkable result, and it is worth saying so plainly before saying anything else, because the rest of this piece is going to be about the word "on paper." The wonder is real. A search guided by a large language model found structures in a vast algebraic space that human researchers had not found, and some of those structures look like meaningful improvements on the state of the art. If you care about quantum computing arriving at all, this is encouraging news. It is also, on the timescale that matters, a very early step — and the gap between the two readings is the entire story.

Why a quantum computer needs babysitting

Start with the problem the codes are meant to solve, because it is the reason quantum computing has been ten years away for longer than I have been writing about it. A quantum bit — a qubit — is not a tidy little switch. It is a fragile physical system, an atom or a circuit or a trapped ion, holding a state that is exquisitely sensitive to the world around it. Heat, stray magnetic fields, the faint vibration of the building: any of it can nudge a qubit off its value. The technical word is decoherence, and the honest translation is that a qubit forgets. Today's best chips hold their state for a few hundred microseconds — IBM's Heron processors sit around 250 microseconds, and even isolated laboratory qubits reach only a couple of milliseconds before the information is gone.

A useful quantum computation needs to run far longer than that, and to perform millions of operations without the errors swamping the answer. The way out, understood in theory since the 1990s, is error correction: you spread the information of one well-behaved "logical" qubit across many noisy "physical" ones, in a pattern clever enough that you can detect and fix errors on the physical qubits without ever measuring — and thereby destroying — the logical state they encode. It is one of the deepest ideas in the field. It is also brutally expensive, and the expense is the whole fight.

The standard approach, the surface code, is robust and well understood and demands something like a thousand physical qubits to protect a single logical one. Build a machine that needs a few hundred logical qubits to do something useful, multiply by a thousand, and you arrive at a number — hundreds of thousands to millions of physical qubits — that explains why fault-tolerant quantum computing has stayed a horizon rather than a product. The overhead is the bottleneck. Almost everything serious in quantum computing right now is an attempt to bring that ratio down.

The codes IBM is betting on

IBM's bet is a family called quantum low-density parity-check codes — qLDPC — and a specific subclass with the unlovely name of bivariate bicycle codes. The appeal is straightforward arithmetic: qLDPC codes promise to protect a logical qubit with roughly a tenth of the physical qubits a surface code would need, cutting the overhead by about ninety percent. They get there by allowing qubits to talk to partners that are not their immediate neighbors — long-range couplers reaching across the chip rather than the strictly local handshakes the surface code relies on. That non-locality is hard to build, which is why IBM's roadmap reads like a sequence of engineering dares: the Loon processor to test the long-range couplers, Kookaburra to combine memory and logic, Cockatoo to link two modules, and then Starling, the machine IBM says will hold 200 logical qubits and run 100 million operations, targeted for 2028 and meant to reach customers in 2029. Beyond that sits Blue Jay, a 2,000-logical-qubit design with no date attached except "beyond."

Designing a good bivariate bicycle code is, underneath, a search problem in a forbidding mathematical space. You are looking for sets of algebraic expressions that produce a code with the right properties: many logical qubits, strong protection against errors, and — crucially — a structure that real hardware could actually be wired to implement. The space of candidate expressions is astronomically large, the rules for what makes a valid code are intricate, and human researchers have historically found good codes the way you would expect, slowly and by insight. This is the door IBM's new work tries to kick open.

What OpenEvolve actually did

The system is called OpenEvolve, and IBM has released it openly. It is an evolutionary search dressed in a language model: the LLM proposes algebraic expressions that might define valid codes — informed guesses, hypotheses — and an evolutionary loop keeps the promising ones, mutates and recombines them, discards the failures, and feeds the survivors back for another round. The model is not "understanding" quantum mechanics in any meaningful sense. It is generating well-shaped candidates fast enough, and in sufficiently clever directions, that the search reaches parts of the space brute force never would. Over a campaign of these rounds, OpenEvolve surfaced 465 new codes spanning a range of trade-offs between how many logical qubits they hold, how strongly they protect, and how heavy they are to build.

A few are worth naming because they show the shape of the achievement. One code, written in the field's bracket notation as [[288, 50, 8]], packs fifty logical qubits into 288 physical ones — IBM's own description says it drastically shatters the previous record of sixteen logical qubits within that code family. Another, [[72, 4, 8]], is deliberately small and frugal, the sort of thing that might fit on near-term hardware rather than a machine that does not exist yet. Others land in between, competitive with the [[144, 12, 12]] code IBM had previously studied as a leading candidate. Taken together they are not one breakthrough but a catalogue of options, which is arguably more useful: a designer choosing how to build the next processor now has more points to choose from, and some of those points sit in territory no one had mapped.

A code that protects fifty logical qubits in simulation and a chip that keeps fifty logical qubits alive are separated by most of the actual problem, and nearly all of the actual cost.

The sentence IBM put in its own announcement

Here is the line that decides how to read all of this, and to IBM's credit the company wrote it down itself: further research is required to evaluate how these AI-generated codes perform in real-world physical architectures. Translate that and it says the codes have been found and characterized mathematically, not run on hardware. They exist as designs. Whether a given code can be laid out on a real chip, with real couplers of finite reach, real qubits that decohere in 250 microseconds, real gates that are themselves slightly wrong every time they fire — that is the part "further research" is carrying, and it is not a footnote. It is most of the journey.

This is the distinction I find myself making in almost every story about long-horizon science, because it is almost always where the meaning lives: demonstrated versus announced. A code that protects fifty logical qubits in a simulation has demonstrated a mathematical property. A chip that keeps fifty logical qubits coherent through a million operations has demonstrated a machine. Between them lies the engineering — fabrication yield, wiring complexity, the error rates of the physical qubits, which IBM itself acknowledges must still fall by an order of magnitude before any of this works at scale. A better code lowers the bar you have to clear. It does not clear it for you. The overhead problem OpenEvolve attacks is real and the attack is clever, but a more efficient code that you cannot yet build is a promissory note, not a power source.

On what timescale

So ask the question the excitement tends to skip: on what timescale does a result like this matter? The honest answer has two halves, and you have to hold both. In the near term — the next year or two — the value is in the search tool itself. IBM open-sourced OpenEvolve precisely so that the wider community can point it at other code families and other problems, and a method that reliably finds good candidates in a huge space is the kind of quiet infrastructure that compounds. That is genuine, and it arrives soon, and it is also undramatic, which is usually the tell that something is real.

In the longer term — the term where this becomes a working fault-tolerant computer — the timescale is still IBM's roadmap timescale, which is to say 2028 and 2029 for Starling at the earliest, and "beyond" for anything larger. The new codes might improve those machines. They do not move the dates, because the dates were never gated on a shortage of codes. They are gated on couplers that have not been built at scale, on error rates that have not fallen far enough, on modular integration that IBM's own engineers describe as very complicated. A clever code does not fabricate a chip. I keep a private archive of every "quantum computing by [year]" claim alongside the year it was actually made, and the lesson of that archive is consistent: the bottleneck is almost never the part that just got solved on a slide. It is the part still labeled "further research."

None of which is a reason to be sour about the work. The opposite, really. The most credible thing about IBM's announcement is that it did not oversell — it reported a striking computational result and, in the same breath, named the gap to hardware. That is what the field should sound like. Quantum error correction is one of the hardest problems in applied physics, and turning a large language model into a tireless explorer of its design space is a legitimately good idea that produced legitimately new objects. Fifty logical qubits where there were sixteen is the kind of number that deserves attention. It deserves it as a blueprint that beat the old blueprints — and not, yet, as a machine that beat anything at all. The codes are real. The computer that runs them is still, on the honest timescale, a few years and several engineering miracles away. Both of those sentences are true, and the work is more impressive, not less, when you let them both stand.