Generative AI for Quantum Circuits and Quantum Code: A Technical Review and Taxonomy

This paper presents a technical review and taxonomy of thirteen generative AI systems and five datasets for quantum circuit and code generation, revealing that while current methods address syntactic and semantic correctness, they lack essential end-to-end evaluation on actual quantum hardware, creating a critical gap between generated artifacts and practical deployment.

The Gist

Imagine you are trying to teach a robot to build a complex, invisible machine called a Quantum Computer. This machine doesn't use gears or wires; it uses the weird rules of quantum physics (like particles being in two places at once) to solve problems that would take normal computers millions of years.

The paper you're asking about is a review of the "teachers" currently trying to teach robots how to build these machines. These teachers are Generative AI models (like advanced chatbots) that write the instructions (code) for the quantum computer.

Here is the story of the paper, broken down into simple concepts and analogies.

1. The Goal: Teaching the Robot to Write the Manual

The researchers looked at 13 different AI systems and 5 sets of training data that were created between 2024 and early 2026. Their job is to generate "Quantum Code."

Think of this code in three different languages:

• Qiskit: Like writing a recipe in Python (a common programming language) that tells a computer how to mix ingredients.
• OpenQASM: Like writing the recipe in a very strict, ancient language that the quantum machine actually understands.
• Circuit Graphs: Like drawing a blueprint of the machine's wiring.

2. The Three-Step Test (The "Quality Control" Checklist)

The authors realized that just because an AI writes code doesn't mean it works. They created a 3-Layer Test to grade these AIs, like a video game with three levels:

• Level 1: Syntax (Did you write in the right language?)

  • Analogy: Did the robot write the recipe using English words and correct grammar? If it writes "Mix flour 1000" instead of "Mix 1000g flour," the computer crashes.
  • Result: All 13 AI systems passed this. They can write grammatically correct code.

• Level 2: Semantics (Does the recipe actually make the cake?)

  • Analogy: Even if the grammar is perfect, does the recipe actually bake a cake, or does it just look like a recipe? The AI needs to ensure the quantum machine actually performs the math task it was asked to do.
  • Result: Most AIs passed this. They use clever tricks (like simulators) to check if the math works out.

• Level 3: Hardware Executability (Can you actually bake it in a real kitchen?)

  • Analogy: This is the big gap. The AI might write a perfect recipe, but what if your real kitchen doesn't have an oven that hot? Or what if the recipe requires 50 ingredients but your fridge only holds 10?
  • The Problem: None of the 13 systems passed this level. They haven't tested their code on real quantum computers yet. They only tested it on simulations (fake computers).

3. The Different "Teachers" (Taxonomy)

The paper sorts these AI teachers into different families based on how they learn:

• The "Code Assistants" (Qiskit Assistants): These are like general-purpose coding tutors (similar to how GitHub Copilot helps humans). They are great at writing standard code but might struggle with the weird physics of quantum mechanics.
• The "Specialist Small Models": These are tiny, focused robots trained only on specific quantum tasks. They are small but very good at their one job.
• The "Verifier-in-the-Loop" (The Strict Coach): These AIs write a draft, run a simulation, get a "score," and then rewrite it to get a better score. It's like a student taking a practice test, seeing their mistakes, and studying until they get an A.
• The "Diffusion Generators" (The Artist): Imagine an artist who starts with a blurry, noisy picture and slowly cleans it up until a perfect quantum circuit appears. These models "paint" the circuit structure.
• The "Agents" (The Project Managers): These are teams of AI bots working together. One writes the code, another checks it, and a third fixes errors. They talk to each other to solve complex problems.

4. The Big Problem: The "Real World" Gap

The most important finding of the paper is the Hardware Gap.

Imagine an AI that designs a bridge. It passes the math test (Level 2) and the grammar test (Level 1). But the researchers realized no one has actually built the bridge and driven a truck over it yet.

• Why is this hard? Real quantum computers are fragile. They have "noise" (static), limited connections between parts, and they break easily.
• The Missing Step: The AI needs to know the specific limitations of the real machine while it is writing the code. Currently, the AIs write code as if the machine is perfect, and then humans have to try to "translate" it to fit the real machine. Often, the translation fails or makes the machine too slow.

5. Why Can't We Just Test Them? (The Verification Wall)

You might ask, "Why don't they just test it on a real quantum computer?"

• The Simulation Wall: To check if the AI's code is right, you usually need to simulate it on a normal computer first. But simulating a quantum computer is incredibly expensive.
• The Math: If you add just a few more "qubits" (quantum bits), the memory needed to simulate them doubles and doubles. Simulating a 50-qubit machine would require more memory than exists on Earth.
• The Result: Because we can't easily simulate big quantum machines to check the AI's work, we can't train the AI to be perfect for big machines yet.

Summary: What's Next?

The paper concludes that while we have made great progress in teaching AIs to write the language of quantum computers, we are still stuck in the "theory" phase.

The future roadmap involves:

1. Standardized Tests: Agreeing on how to grade these AIs so we can compare them fairly.
2. Real-World Testing: Finally running the AI-generated code on actual quantum hardware to see if it works.
3. Hardware-Aware AI: Teaching the AIs to write code that respects the physical limits of real quantum machines (like limited connections and noise) from the very beginning.

In short: The robots can write the instructions, but we haven't yet taught them to build the machine in the real world.

Technical Summary

1. Problem Statement

The field of generative AI for quantum software has fragmented into various technical families (LLMs, diffusion models, RL agents) with inconsistent evaluation standards. While systems can generate quantum artifacts (Qiskit code, OpenQASM, circuit graphs), there is a critical lack of:

• Standardized Evaluation: Different systems use incompatible metrics (unit tests vs. process fidelity vs. distribution alignment), making cross-system comparison impossible.
• Hardware Realism: No reviewed system validates its output on actual quantum hardware. There is a significant gap between "syntactically valid" generation and "hardware executable" deployment.
• Semantic Verification: Verifying that a generated circuit implements the correct unitary is computationally expensive ($O(2^n)$ or $O(4^n)$), creating a bottleneck for training and evaluation at scale.
• Scope Definition: The field lacks a unified taxonomy distinguishing between code generation, circuit synthesis, and dataset augmentation.

2. Methodology

The author conducted a structured scoping review following PRISMA-ScR guidelines, covering literature and artifacts from January to February 2026.

• Data Sources: Hugging Face (model cards), arXiv (papers), and provenance tracing (GitHub, citations).
• Screening Process:
  • Initial pool: 228 candidates (35 model cards + 193 papers).
  • Exclusion: Removed 190 candidates (mostly quantum-enhanced RL that does not generate circuits) and 16 for insufficient technical disclosure.
  • Final Corpus: 13 generative systems and 5 supporting datasets.
• Inclusion Criteria: Systems must disclose at least two of: (i) architecture/parameters, (ii) training data source/scale, or (iii) quantitative evaluation metrics.
• Terminology: The review distinguishes between Syntactic Validity (compiles/parses), Semantic Correctness (implements intended logic), and Hardware Executability (runs on real devices with constraints).

3. Key Contributions

A. A New Taxonomy

The paper organizes the field along two axes: Artifact Type (Qiskit code, OpenQASM, Circuit Graphs) and Training Regime. This yields six distinct families:

1. Qiskit Code Assistants: General LLMs fine-tuned on Qiskit APIs (e.g., Granite-3.2-8b, Qwen2.5-14B). Evaluated via unit tests.
2. OpenQASM Generators (Static SFT): Models trained on text-to-QASM pairs (e.g., Agent-Q).
3. Specialist Small LMs: Small models (~100M params) for specific tasks (e.g., QuantumGPT-124M).
4. Verifier-in-the-Loop Alignment: RL systems using simulator-based rewards (e.g., QUASAR) with hierarchical reward functions (syntax, distribution, expectation value).
5. Graph and Diffusion Generators: Models operating on circuit DAGs or discrete gate tokens (e.g., genQC, AltGraph, UDiTQC).
6. Agentic Systems: Multi-agent workflows using tools (simulators, compilers) for iterative improvement (e.g., QAgent).

B. A Three-Layer Evaluation Framework

The author proposes a rigorous framework to categorize evaluation depth:

• Layer 1 (Syntax): Parsing success, compilation, or structural well-formedness (valid DAG).
• Layer 2 (Semantics): Correctness of the generated artifact. Methods vary by task:
  • Code: Unit tests (pass@k).
  • Compilation: Process fidelity or density-matrix distance.
  • Optimization: Expectation-value alignment.
  • Augmentation: Real-vs-random classification.
• Layer 3 (Hardware/Resources):
  • 3a (Compilability): Transpilation success, SWAP overhead, and depth reduction on target hardware constraints.
  • 3b (Empirical Execution): Running the circuit on a real QPU and comparing output distributions to ideal simulation.

C. Analysis of OpenQASM Versions

The review highlights the divergence between OpenQASM 2.0 (straight-line gate sequences) and 3.0 (classical control flow, typed variables). Systems targeting 3.0 face higher syntactic complexity and path-dependent semantic verification challenges, which current evaluators struggle to handle.

4. Key Results & Findings

• The "Hardware Gap": The most significant finding is that none of the 13 reviewed systems reports end-to-end evaluation on quantum hardware (Layer 3b). While some systems (like AltGraph) report post-transpilation metrics (Layer 3a), no system closes the loop to actual device execution.
• Evaluation Incompatibility: There is no unified metric. A system optimized for unit tests (Qiskit) cannot be directly compared to one optimized for process fidelity (Diffusion models) or distribution alignment (RL).
• Performance Trends:
  • Qiskit Assistants perform well on syntax and unit tests but lack semantic depth beyond the test suite.
  • Diffusion Models (genQC, UDiTQC) show promise in generating structurally valid circuits and optimizing entanglement but often lack transparency in model size and evaluation depth.
  • Agentic/RL Systems (QUASAR, QAgent) introduce sophisticated reward structures but remain confined to simulation environments.
• Scaling Limitations: Verification costs (statevector simulation $O(2^n)$) prevent verifier-in-the-loop training from scaling beyond ~30–50 qubits, limiting the "small-qubit" regime of current models.

5. Significance and Future Directions

• Bridging the Gap: The paper argues that the field must move beyond "simulation-only" evaluation. Future systems must incorporate transpilation-aware generation (conditioning on device connectivity and native gate sets) during the training phase, not just as a post-processing step.
• Standardization: The author calls for standardized evaluation protocols that separate syntax, semantics, and hardware realism. This includes reporting post-transpilation metrics (SWAP overhead, depth blow-up) as a minimum baseline.
• OpenQASM 3.0 Challenges: As the field moves to OpenQASM 3.0, new evaluation strategies (bounded-path execution, trace-based testing, symbolic execution) are required to handle classical control flow, which current systems largely ignore.
• Reproducibility: The review highlights issues with data provenance, schema mismatches between QASM versions, and the lack of transparency in industrial/closed-source systems.

Conclusion:
While generative AI has diversified quantum circuit synthesis, the field is currently stuck in a "simulation bubble." The central bottleneck is not just model architecture, but the lack of hardware-realistic evaluation and the computational cost of semantic verification. Future progress depends on standardized benchmarks, transpilation-aware training, and the eventual integration of real quantum hardware into the evaluation loop.