Skip to content
Quantum.world

Research

Perspective on AI and quantum open-source software

Overview Research area: Quantum open-source software (QOSS), AI-assisted software development, and research verification. Technical level: Intermediate. The paper is a Perspective (not a technical res

arXiv
2610.38049
Published
2026-10-27
Authors
Changhao Li, Bradley A. Chase, Veena Vijayakumar, Mathys Rennela, Alessandro Cosentino, Naixu Guo, Sebastian Hassinger, Farrokh Labib, Seun Omonije, Patrick Rebentrost, Vincent Russo, Nathan Shammah, William J. Zeng, Ben Castanon

AI summary

Overview

Research area: Quantum open-source software (QOSS), AI-assisted software development, and research verification.

Technical level: Intermediate. The paper is a Perspective (not a technical result paper), so it requires no mathematics, but it assumes familiarity with what quantum SDKs, transpilers, simulators, and error-correcting codes do.

Scope (one sentence): A community-grounded Perspective arguing that verification, not generation, is the binding constraint on AI-assisted quantum software development and AI-driven quantum research, supported by repository measurements, five years of hackathon records, and a survey of more than 1600 respondents.

What This Paper Is About

Quantum computing runs on open-source software, and AI tools (including large language models) are now writing, migrating, and debugging that software. The problem is that nobody can cheaply check whether AI-generated quantum code is correct: exact classical simulation becomes impractical beyond a few tens of qubits, hardware runs are noisy and costly, and small unit tests miss bugs that only appear at larger circuit sizes. The paper's goal is to show, with data from real repositories and real contributors, where verification breaks down, how that breakage lands as extra review work on maintainers, and what contribution standards and tooling could make AI-assisted quantum development and AI-driven research reliably checkable.

Key Contributions

  1. A seven-category map of AI in the quantum software stack — writing code, control and calibration, compiling and optimizing, discovering error-correcting codes, decoding errors, circuit design and experiments, and maintenance and debugging — each paired with the verification methods available and their limits.

  2. A quantitative characterization of QOSS constraints using public repository data collected on 6 October 2026: code availability, API/interface stability, deprecation rates, and the circuit sizes actually used in test suites.

  3. Empirical evidence on AI disclosure and review burden from 11 quantum and 8 mainstream scientific Python projects, unitaryHACK records spanning 2022–2026, and the Quantum Open Source Software Survey snapshot of 26 October 2026 (1,691 respondents, of whom 917 answered the AI-use question).

  4. A candidate benchmark corpus and a set of proposals — 417 candidate maintenance tasks extracted from 812 unitaryHACK bounty listings across 110 repositories, plus verification practices, contribution standards requiring reproducible evidence, draft agent harness designs, a verifier catalog, and an open-source companion repository for reproducing the analyses.

Main Findings

  • Scale gap, but not a stability gap: Quantum libraries appear in a median of 6,864 public repository files versus 1,609,728 for comparison libraries, with median monthly PyPI downloads of 97,269 versus 191,385,592 — factors of 235 and 1,968. Yet 34.4–71.7% of the 2021 public API remains importable for quantum projects versus 46.4–85.7% for the others, so the ranges overlap.

  • Deprecation rates differ sharply: Qiskit and PennyLane announce 56.8 and 24.1 deprecations per year, compared with 11.0 for NumPy and 6.8 for SciPy. Cirq retains more of its interface than NumPy; SciPy retains the largest share overall.

  • Tests are tiny: Across 13,109 extracted qubit-count entries from the Qiskit, PennyLane, and Cirq test suites, the median is two qubits and 98.9% are twenty or fewer. The 99th percentile reaches 120 qubits for simulation and quantum-state operations and 41 for algorithms, but stays at 11 for circuit construction and 10 for data import/export; 96.9% of simulation-test entries are 20 or fewer.

  • Small tests hide real bugs: A bug in Qiskit Aer's stabilizer and matrix product state methods returned correct samples at 64 qubits and incorrect ones at 65 qubits without raising an error.

  • No single verifier generalizes: On unstructured random Clifford circuits, QCEC (decision diagrams), PyZX (ZX-calculus), and Giallar (certified compilation) all failed to complete 50-qubit instances in the configurations tried, and a 100-qubit QCEC run that exceeded one hour on a 96-core machine was projected to take well over 24 hours. Diagram and ZX verifiers scale well on structurally close compilation pairs, and Clifford circuits admit efficient tableau-based equivalence checking.

  • Test styles diverge by project: Random circuit generators account for 75% of matched calls in Cirq and 57% in Qiskit, but only 5% in PennyLane, which tests gradients on named states such as GHZ, Bell, and W. Transferring compiler-style fuzzing to variational algorithms or QEC decoding probes none of the relevant invariants.

  • AI disclosure is rare and policy-dependent: Median commit disclosure is 0.57% (quantum) versus 1.54% (other); median pull-request disclosure is 0.43% versus 4.56%. Only 3 of 11 quantum projects ask about AI use in their PR templates, versus 8 of 8 mainstream projects — so recorded rates are a lower bound on actual use.

  • Disclosure can be one person: In one project, 50% of 2026 commits carry a disclosure, and 1,107 of its 1,145 disclosing commits come from a single maintainer. The largest contributor share reaches up to 75% in quantum projects and up to 97% in comparison projects.

  • Maintenance is fragile and review burden is rising: Maintenance rests on a single contributor in 81.7% of surveyed public quantum repositories. In 2026, 5 of 10 responding maintainers reported more work than anticipated, versus 0 of 8 in 2023, 2 of 7 in 2024, and 4 of 14 in 2025. Maintainers describe time spent explaining rejections and establishing how AI was used.

  • Contributors use AI widely but verify by hand: Of 917 respondents answering the AI-use question, 715 reported using AI for quantum tasks, with 71–89% of those performing each of six workflow tasks reporting AI assistance. Among 621 respondents on verification, 79% reported manual review, 60% automated tests, 17% formal verification, and 5% no verification.

  • Confidence exceeds measured accuracy: 83% agreed AI assistants improved their efficiency and effectiveness (n = 601), versus 59% who agreed generated code was accurate (n = 597). The paper cites a controlled study in which experienced developers took longer with AI assistance while believing they were faster.

  • Hackathon data yields a benchmark corpus: The 417 candidate tasks come from 812 bounty listings (42% retention in 2022, 65% in 2026); 275 of the 417 reference pull requests modify test files. Feature and method extensions account for 225 tasks (54.0%), documentation and examples 74 (17.7%).

  • Free-text priorities: Maintainers most often raised human oversight (4 of 9) and review burden (3 of 9); contributors raised review burden (6 of 16) and understanding of their own changes (6 of 16), while 5 said AI helped. Only one respondent in each group raised disclosure.

  • Shared community pressure: The curl project ended its monetary bug bounty in January 2026 after the share of valid vulnerability reports fell from above 15% to below 5%; since 2019 it had paid over US$100,000 for 87 confirmed vulnerabilities.

Methodology in Plain English

The authors combine four kinds of evidence rather than running a single experiment.

First, they mine public code: they count repository files that import nine quantum libraries and eight comparison scientific Python libraries, pull download statistics from PyPI, test whether symbols from each project's 2021 API still import in the 2026 release, and count deprecations in release notes (collected August 2026 for that panel). They also scan the test suites of Qiskit, PennyLane, and Cirq for qubit counts written as literal integers between 1 and 200, deliberately ignoring counts defined through variables or fixtures.

Second, they scan commit messages and pull-request text across 11 quantum and 8 mainstream projects for AI attribution lines, stripping repeated template text first so that a request to declare AI use is not miscounted as a declaration. Disclosure is counted through 30 September 2026.

Third, they use their own hackathon, unitaryHACK, as a longitudinal dataset: bounty lists and post-event surveys from 2022 to 2026, with 7 to 14 maintainers and 16 to 33 contributors responding each year, plus written records of the 2026 maintainer meeting attended by 27 maintainers. They pair each issue description of at least 120 characters with its selected merged pull request to build the 417-task corpus.

Fourth, they analyze the annual Quantum Open Source Software Survey run by Unitary Foundation, using a 26 October 2026 snapshot of 1,691 respondents collected while the survey was still open, and they group free-text answers by topic. Limitations are stated openly: path-based classification left 3,526 of the 13,109 test entries uncategorized, only five entries fell under error correction (large-scale QEC testing often happens in specialized packages like Stim), and reported disclosure misses unreported AI use.

Why This Matters

The paper reframes the AI-in-quantum conversation: generation is getting cheap, and verification is not. It connects a technical fact (exact state-vector simulation is impractical beyond a few tens of qubits) to a social one (maintainers absorb the difference) and shows that the community's current verification habits — mostly manual review — sit exactly where the gap is widest.

Real-world applications the paper points to:

  • Compiler and transpiler changes: equivalence checking with decision diagrams or ZX-calculus to confirm that gate-count and Toffoli-count reductions preserve the intended computation, rather than relying on unit tests at two qubits.

  • Error-correcting code discovery and decoding: automated pipelines such as the QEC Challenge that check code structure and bound the distance by searching for low-weight logical operators, alongside simulator-based comparison of decoder logical error rates under specified noise models.

  • Hardware calibration and control: agents that generate pulse ansätze or native control code for superconducting and trapped-ion platforms, with hardware-imposed safety limits and measured performance as direct feedback.

  • Scientific experiment design: agents that translate objectives into executable photonic or circuit experiments, where the paper stresses that successful execution must be distinguished from scientifically valid interpretation.

Industry relevance: The recommendations — pinned dependencies, dependency-contract tests that assert cross-SDK conversions preserve non-unitary instructions such as barriers, isolated agent environments, maintainer approval before dependency or workflow changes, and hardware spending and retry limits enforced outside the agent's control — map directly onto how quantum hardware vendors, SDK maintainers, and cloud quantum platforms govern automated contributors. The 417-task corpus is framed as material for benchmarking coding agents on real maintenance work.

Future Directions

  • Benchmarks built from real maintenance records: the authors propose turning the 417 candidate tasks into evaluations of coding agents, including interface understanding, dependency handling, and behavior on existing code — capabilities that existing code-generation benchmarks do not cover.

  • Verification that scales past full-state simulation: extending decision-diagram, ZX-calculus, and certified-compilation approaches to the circuit families and structured tests where they currently fail, and matching each verifier to the circuit structure it handles well.

  • Verification as a publication format: treating open-source research harnesses, with executable evaluators and independent verification, as a way to publish quantum research results alongside or instead of papers, so that others can assess and extend agent-discovered findings.

  • Whether the contributor pipeline survives: open questions about whether newcomers still learn through introductory issues and hackathons when agents can complete that work, whether participants return and become maintainers, and whether disclosure policies in PR templates actually change behavior — the paper notes that systematic evidence on these points remains limited.

Target Audience

Quantum software maintainers and open-source project leads who must review AI-generated pull requests; researchers building AI agents for quantum code generation, compilation, or QEC discovery who need credible evaluation tasks; funding agencies and community organizers interested in the health of the QOSS contributor pipeline; and benchmark designers looking for realistic, verification-grounded quantum coding tasks. Readers wanting hands-on material should go to the companion repository, which holds the data, scripts, verifier catalog, contribution templates, and draft agent harness designs. Note that the provided text ends partway through Section 5.1, so the paper's later recommendations and future-directions sections are only partially represented here.

Authors’ abstract

Quantum open-source software provides essential infrastructure for quantum science, and artificial intelligence (AI) is reshaping its capabilities and transforming its development. However, verifying quantum software at scale remains difficult, and AI-generated contributions can increase the workload of maintainers. In this Perspective, we examine verification as a central requirement for reliable AI-assisted quantum software development and research. We analyze public repositories, records covering 110 repositories from five annual quantum open-source hackathons that we organize, and responses from more than 1600 participants in a community survey. Our analysis connects limitations in automated verification with the review burden on quantum software maintainers. We propose verification practices and contribution standards that require contributors to support their changes with reproducible evidence for maintainer review. We also examine how quantum open-source software can provide infrastructure for AI-driven research whose results the community can independently verify and build upon. We maintain an open-source companion repository to support reproducibility and help projects adopt and refine these proposals. Together, these contributions help the quantum open-source software community translate advances in AI into reliable quantum research through reproducible verification.

Read the original paper