An overnight loop that searches for magic-state recipes
The [[4,2,2]] code is the smallest interesting thing in fault-tolerant quantum computing — two logical qubits, four physical qubits, distance two, just barely enough redundancy to detect single-qubit errors. It is to error correction what a one-stage rocket is to spaceflight: not useful on its own, but the only honest place to learn what works.
For non-Clifford operations you need magic states. Preparing them well — high fidelity, low overhead — is the rate-limiting step for every interesting algorithm beyond Clifford-only circuits. There's a sprawling literature of distillation protocols, injection circuits, post-selected preparations. Each paper proposes one. Almost nobody runs them all side by side.
autoresearch-quantum is what happens when you take Karpathy's "autoresearch ratchet" pattern — propose, evaluate, compare, learn, repeat, no human in the loop — and point it at this question. The engine generates candidate preparation circuits for encoded magic states on [[4,2,2]], runs them under the Aer simulator (no IBM account, no API key, nothing to throttle you), measures fidelity against the target state, ranks, learns from the deltas, and proposes the next batch. Overnight. Days at a time. The interesting state of the project is "what did the loop discover while I was asleep."
The second layer is the teaching one, and this is the part I'm proud of for a different reason. Twelve Jupyter notebooks, organized into four pedagogical plans:
- Plan A — sequential, the textbook spine
- Plan B — spiral, the same concepts revisited at increasing depth
- Plan C — parallel tracks, theory and implementation interleaved
- Plan D — hypothesis-driven, the student proposes, the notebook tests
Each plan teaches the same core material: stabilizer formalism, the [[4,2,2]] code, magic-state injection, post-selection, T-count overhead. The interactive widgets track per-student progress and align to Bloom's taxonomy. It's the same physics, repeated through four different lenses, on the bet that one of them clicks for any given reader.
The whole thing runs locally. No cloud, no API keys, no rate limits. The research engine and the pedagogy are two sides of the same belief: the way you understand a piece of physics is to make a machine try every plausible variant of it and report back. The way you teach the same physics is to make four different machines try four different ways of explaining it. Both are sampling problems. Both can be automated, if you're careful about what the metric is.
Worked on this from early April through late April 2026. Seventeen commits. Most of the time went into the evaluation harness — not the circuits, the discipline of judging them.