Perspective on AI and quantum open-source software

Introduction

Quantum information science has developed rapidly in recent years with applications across computation [1], simulation [2], sensing [3], and communication [4]. Progress in each of these directions depends on software, and in quantum computing that software is largely open source, from circuit construction [5–8] and compilation [9, 10] to hardware control [11–14] and error correction [15–17]. Artificial intelligence (AI), including large language models (LLMs), is driving substantial advances in the capabilities of quantum open-source software (QOSS) [18, 19, 20] and playing an increasingly important role in its development and maintenance [21, 22, 23, 24]. These tools can accelerate the discovery of new quantum methods and improve the accuracy and efficiency of existing ones. For the QOSS community, they can broaden participation in software development by lowering technical barriers for new contributors and reducing routine implementation effort. Their output, however, becomes part of software on which the research community depends, raising questions about its continued reliability and maintainability as AI use expands. Progress in AI-assisted quantum research therefore requires advances in verification alongside advances in generation.

QOSS also provides infrastructure for AI-driven research, where verification plays a direct role in the discovery process. Open-source libraries allow agents to construct and evaluate candidate solutions, while executable verification procedures provide feedback for further exploration. In these auto-research workflows, the choice of objective and the design of the evaluator shape what agents discover [25, 26]. However, success under an evaluator does not by itself establish a scientific result. Independent verification is needed to determine whether the finding supports the claimed conclusion beyond the conditions explored during the search. QOSS can make this verification available alongside the implementation, allowing other researchers to assess and extend the work. It could therefore also offer a publication format for advances in quantum research, alongside emerging paper-to-agent approaches [27].

For quantum software, verification is particularly demanding because computing reference results may itself be prohibitively expensive. For example, exact classical simulation of general quantum circuits becomes impractical beyond a few tens of qubits [28, 29], while verification on quantum hardware is constrained by noise, calibration drift, and limited device access [30]. A further limitation is that models may have incomplete or outdated knowledge of the quantum framework being used, making their outputs harder to trust without verification. Reliable AI-assisted development and auto-research therefore require explicit verification criteria and a clear statement of the scope and limitations of the supporting evidence.

What automated verification leaves unresolved falls to project maintainers, who must judge whether a contribution addresses the problem and is adequately supported. Organizers of community events report that unverified AIgenerated contributions have already shifted maintainer time from mentoring toward reviewing [31], and a similar shift has been documented across open-source software [32, 33, 34]. This change may also affect the training of future maintainers, who develop their skills through introductory issues, code review, and hackathons. Task completion alone does not demonstrate a contributor’s understanding of the changes, and subjective assessments of productivity may not reflect actual performance. In a controlled study, experienced developers took longer to complete tasks with AI assistance, despite believing that it had made them faster [35]. For quantum software, systematic evidence on how AI-assisted development affects maintainer workload and the training of future maintainers remains limited.

In this Perspective, we examine how verification can support reliable AI-assisted development and research across QOSS. We first survey AI applications across the quantum software stack and characterize technical constraints through analyses of public code availability, interface stability, and test circuit sizes. We then analyze repository disclosures alongside records and participant surveys from five quantum open-source hackathon events that we organize [36], complemented by a broader QOSS community survey with more than 1600 respondents [37]. Together, these sources provide evidence on verification practices and the review effort associated with AI-assisted contributions. Drawing from the hackathon events that we organize, we also assemble a collection of 417 candidate maintenance tasks from 110 repositories and characterize their verification requirements to inform future benchmarks of coding agents. Based on these analyses, we propose verification practices and contribution standards that combine automated verification with maintainer review. We further discuss how open-source research harnesses can guide agent-driven exploration toward scientifically meaningful results supported by independent verification. An open-source companion repository provides data and scripts for reproducing our analyses, alongside templates for implementing and refining these proposals [38].

The Perspective is organized as follows. § 0.2 reviews AI applications across the QOSS stack. § 0.3 examines technical and community constraints and discusses practices for addressing them. § 0.4 presents evidence from public repositories, community events, and surveys. § 0.5 presents recommendations for verification, open-source infrastructure for AI-driven research, and benchmark development alongside standards for AI-assisted contributions. § 0.6 discusses future directions for AI and quantum open-source software.

AI across the quantum software stack

We organize current AI applications in QOSS into seven categories according to their functions and cover both task-specific machine-learning methods and LLM-based assistants. These applications reflect two complementary roles: AI helps develop and improve quantum software, while QOSS provides tools for AI-driven research. We use auto-research to describe workflows in which agents propose and evaluate candidate solutions, then use the results to choose subsequent steps toward a human-defined research goal. For each category, we describe the available verification methods and discuss how they support or limit practical use.

Writing code. Assistants trained on a single framework are the most mature category. Training and retrieval provide complementary ways to adapt LLMs to quantum programming. For example, the Qiskit Code Assistant uses a code model further trained on Qiskit code and tutorials [21]. The PennyLane study follows the second approach by providing models with relevant PennyLane code examples and descriptions from a curated dataset alongside the user’s request [22]. Agentic workflows also combine code generation with tools for executing and refining quantum programs. Examples include Pasqal’s workflow connecting Pulser to emulation and hardware execution [39], and qBraid’s codeq agent for writing, running, and debugging quantum code [40]. We note that existing evaluations cover quantum code generation, problem solving, and debugging [41, 42, 43, 44, 45, 46]. These tasks provide evidence about specific programming capabilities, while repository maintenance also requires understanding existing interfaces, dependencies, and behavior. We discuss how community maintenance records could support evaluations of these capabilities in § 0.5.

Control and calibration. AI-assisted control now includes LLM-based pulse design and agents that coordinate calibration experiments. Reinforcement learning has been applied to pulse optimization and gate calibration [47, 48, 49, 50], while earlier automation organized calibration procedures as dependency graphs [30]. More recently, LLMs have been used to propose analytic control-pulse ansätze whose parameters are refined through numerical optimization [51]. LLM agents have coordinated superconducting-qubit calibration using laboratory knowledge and reusable experimental procedures [52, 53]. On trapped-ion platforms, agents have generated native ARTIQ control code for calibration experiments, with hardware operations screened against prescribed safety limits [54]. Vision-language models have also been evaluated for interpreting calibration plots [55]. For agents operating on hardware, measured performance provides direct feedback and verification, although repeated trials consume device time. These agent workflows can use open-source control and simulation libraries to optimize pulses and evaluate proposed control settings [11–14].

Compiling and optimizing. Reinforcement learning has been applied to qubit routing and circuit optimization [56, 57, 58], and IBM distributes learned synthesis and routing methods as an add-on to the Qiskit transpiler [59]. Learned search has also reduced CNOT counts [60] and T counts [20]. More recently, LLMs have been adapted to synthesize Clifford+T circuits from unitary operators with gate constraints specified in natural language [61]. Other efforts use LLMs to generate and refine trapped-ion shuttling compilers [62] and apply LLM-guided evolutionary search to compiler routines and runtime policies [63]. Efficient classical verification also enables LLM-guided search for quantum circuits with lower Toffoli and qubit counts [25, 64]. The Stabilizer Rank Challenge supports agent-assisted searches for magic-state decompositions verified by exact arithmetic [65]. For transformations of existing circuits, equivalence checking can verify that resource reductions preserve the intended computation. § 0.5 discusses the scope and practical limits of these verification approaches.

Discovering error-correcting codes. Reinforcement learning has been used to discover quantum error-correcting codes and their encoding circuits for specified hardware constraints and noise models [66, 67], and to reduce stabilizer weights [68]. More recently, LLM-based workflows have been used to discover code constructions and assess their correctness and error-correction performance [69, 70, 71, 72]. Inspired by ECDSA.fail [73], the QEC Challenge supports agent-assisted code discovery with automated verification [26, 74]. Its verification pipeline checks the code structure and searches for low-weight logical operators to place upper bounds on the code distance. Establishing the exact distance and evaluating logical error rates require further computation. We return to the QEC Challenge in § 0.5 to discuss its role in AI-driven research.

Decoding errors. AI contributes to error decoding through both learned decoders and tools for developing their algorithms and implementations. Early neural-network decoders [75, 76] have been followed by AlphaQubit, a recurrent transformer that reduces logical error rates relative to matching-based decoders on Sycamore surface-code data [19]. LLM-guided search has also been explored for tuning matching-decoder edge weights [77] and optimizing belief-propagation decoder implementations using high-level synthesis feedback [78]. In these workflows, LLMs assist decoder development while the resulting algorithms process syndromes during execution. During development, open-source simulation and decoding packages allow candidate decoders to be compared by their logical error rates under specified noise models without requiring quantum hardware [15–17]. Practical deployment requires sufficient decoding throughput and low-latency integration with quantum control hardware [19, 79].

Circuit design and experiments. LLM-based workflows have been used to propose and refine variational circuit architectures using simulator feedback [80, 81, 82]. Hardware-aware designs, such as LLM-generated ansätze for quantum circuit Born machines [83], have also been evaluated on quantum processors. LLMs have further generated Python programs that describe families of photonic experiments and quantum circuits [84]. Agents also translate scientific objectives into executable experiments and analyze the resulting measurements across several quantum hardware platforms [39, 85, 86]. Simulation-guided design remains limited by the circuit sizes that can be evaluated and by the assumptions of the simulator [28, 29]. For hardware experiments, successful execution must be distinguished from scientifically valid interpretation of the results [39, 86]. Independent evaluation of physical performance is therefore essential [87], as discussed in § 0.5.

Maintenance and debugging. Maintenance is one of the newest of these functions and the closest in shape to ordinary software work. Migration of code across breaking framework releases has been evaluated for Qiskit [88], and it is the task to which the analysis of § 0.3.1 applies most directly. AI-assisted maintenance also includes debugging quantum programs. For example, QBugLM evaluates agents on detecting and repairing quantum software bugs [45], and KQFuzz uses codebase knowledge to guide LLM-based fuzzing of quantum libraries [89]. These efforts build on earlier studies that cataloged real bugs in quantum frameworks and programs [90, 91] and developed automated detection tools using differential testing, metamorphic testing, and static analysis [92, 93, 94]. Beyond these technical evaluations, maintenance also involves submitting code changes as pull requests for human review. This process gives the QOSS community direct experience with AI-assisted contributions and the work required to assess them. We examine this community evidence in § 0.4.

Constraints in quantum open-source software

QOSS projects share concerns about credit, licensing, training, and access costs with other research software communities [95]. Review burden is a further shared concern, and the clearest recent example comes from curl, which in January 2026 ended its monetary bug bounty after the proportion of valid vulnerability reports fell from above 15% to below 5%. Since 2019, the program had paid over US$100,000 for 87 confirmed vulnerabilities, and its maintainer attributed the decline to AI-generated reports and lower-quality human submissions [96]. We return to this point in § 0.5.4 when discussing contribution requirements.

Beyond these shared concerns, QOSS projects can face additional constraints from limited public code and changing software interfaces. Coding models have fewer framework-specific examples to learn from, and generated code may depend on interfaces that are no longer available. Quantum software also requires verification of physical correctness at scales beyond the reach of exact classical simulation. This verification must establish, for example, that compiler transformations preserve the intended computation and that noise models are implemented correctly. Agents with access to project systems or paid quantum hardware introduce further security and cost risks.

Our analysis also reveals substantial variation between projects, since quantum and other scientific Python projects overlap in interface stability while quantum frameworks differ in their test sizes and use of randomly generated circuits. These differences limit the usefulness of uniform recommendations for QOSS. Sections 3.1–3.4 therefore examine these constraints individually, each concluding with a Practice paragraph offering recommendations that projects can adapt to their own needs. Table I summarizes the metrics used in this analysis and the conclusions each can support, along with their limitations.

Metric	Result	Notes
	Quantum	Non-Quantum
Code availability and API stability (Figure 1)
Public files importing a library	6,864	1,609,728	9 quantum and 8 comparison libraries; medians
Monthly PyPI downloads, median	97,269	191,385,592	Includes repeated downloads from continuous integration
2021 API still importable	34.4–71.7%	46.4–85.7%	Overlapping ranges between groups
Deprecation notices per year	24.1–56.8	6.8–11.0	Four projects; collected in August 2026
Verification and disclosure (Figure 2)
Test qubit counts $\le20$	98.9%	–	Three quantum frameworks; median 2 qubits
Commit AI disclosure, median	0.57%	1.54%	Attribution lines only; prose disclosures excluded
PR AI disclosure, median	0.43%	4.56%	Larger variation within groups than between
PR templates requesting AI disclosure	3 of 11	8 of 8
Largest contributor share	up to 75%	up to 97%	Among projects with at least 5 disclosed commits
Candidate tasks and community surveys (Figure 3)
Candidate maintenance tasks	417 of 812		Distinct issues linked to selected merged PRs
Tasks with test-file changes	275 of 417		Paths identified as tests within the first 100 listed files of each reference PR
Repositories represented	110		Largest repository: 5.0% of tasks; top five: 17.7%
Disclosure in free-text responses	1 of 9 maintainers; 1 of 16 contributors		unitaryHACK responses grouped by topic
AI use for quantum tasks	715 of 917		Self-reported
Verifying AI-generated code	79% manual review; 60% automated test/verification		621 respondents; multiple responses allowed

Public code availability and interface stability

We compare quantum frameworks with other scientific Python libraries using counts of public repository files that import each library and package downloads recorded by PyPI. Quantum frameworks have substantially less public code and fewer downloads, with median differences of factors of 235 and 1,968, respectively (Figure 1a and Table I). These measurements characterize differences in ecosystem scale.

By contrast, we find substantial overlap in interface stability between the two groups. Across the projects surveyed, 34 to 86 percent of the 2021 public interface remains importable in the current release (Figure 1b). Cirq retains more of its interface than NumPy, while SciPy retains the largest share. We also count deprecations announced in release notes: Qiskit and PennyLane report 56.8 and 24.1 per year, compared with 11.0 for NumPy and 6.8 for SciPy (Figure 1c). These counts reflect documentation practices as well as API changes. Compatibility risks therefore need to be assessed for individual frameworks and versions. As an example, metriq-gym [97], an older Braket SDK dropped circuit barriers during conversion from Qiskit, inflating benchmark scores and requiring a stricter minimum dependency version [98].

Coding agents can also retrieve documentation, inspect source code, and revise their output using execution feedback, reducing their dependence on knowledge acquired during training. Version-specific retrieval has also been used to assist Qiskit code migration [88]. The relevance of public code availability and interface changes to agent performance therefore depends on access to current project information and opportunities to check the generated code.

Practice. As in general open-source development, pin dependency versions and provide coding agents with matching documentation and runnable examples. Verify migrated code using the project’s test suite in the target environment [88]. To guard against silent physical or semantic regressions across the quantum stack, write explicit dependency-contract tests that report failures explicitly after an upgrade whenever external assumptions change, for example, asserting that cross-SDK circuit conversions preserve non-unitary instructions such as barriers for benchmarking and error mitigation [98], verifying qubit ordering and relative phases on asymmetric entangled states, and checking expected noise-channel fidelities.

Verification confined to small circuits

Circuit simulation provides reference results for verifying the correctness of quantum programs. However, the memory required for exact state-vector simulation grows exponentially with circuit width, limiting its use for general circuits at large scales [28, 29]. Specialized simulators can handle larger structured circuits, but their implementations still require testing at the scales they support. For example, a bug in the stabilizer and matrix product state methods of Qiskit Aer produced correct measurement samples at 64 qubits but incorrect samples at 65 qubits without raising an error [99]. Such failures can remain undetected by tests confined to smaller circuits.

To examine the circuit sizes used in repository tests, we extracted the qubit counts written as literal integers (from 1 to 200) in qubit and wire constructors across the test suites of Qiskit, PennyLane, and Cirq, excluding sizes defined through variables, expressions, or parameterized fixtures. Among the 13,109 extracted qubit-count entries, the median is two qubits, and 98.9 percent are twenty or fewer (Figure 2a and Table 1). For human-authored unit tests, tests of small circuits are appropriate. Whether a function rejects invalid input, whether a gate has the right matrix, or whether a compiler pass rewrites a local pattern are readily verified with one to three qubits without slowing continuous integration. The question for agentic development is whether repository test suites also include verification at larger circuit sizes in the modules whose behavior depends on scale. Grouped by software function, we find that the 99th-percentile circuit size reaches 120 qubits for simulation and quantum-state operations and 41 for algorithms and applications, compared with 11 for circuit construction and 10 for data import and export. However, the median remains two or three qubits across all categories, and 96.9% of qubit-count entries from simulation tests are 20 or fewer.

Because we classify test files by path, 3,526 of the 13,109 entries fall outside the named categories, and only five entries fall under error correction, reflecting that large-scale stabilizer and quantum error-correction (QEC) testing is often done against specialized packages such as Stim [15] rather than general SDK unit tests. Such tests are often constructed programmatically rather than via literal qubit constructors and are not covered by our methodology. We therefore use the upper quantiles to characterize where larger tests occur rather than to estimate total coverage.

More broadly, small tests alone may not capture errors in methods whose behavior changes with circuit size. Non-local methods, such as block-partitioned synthesis in BQSkit [10], activate partitioning logic only above threshold sizes, accumulate numerical error with scale, and require verification at target widths.

Scaling up verification also requires matching the solver to the circuit structure. When the ucc compiler benchmarked decision-diagram (QCEC [100]), ZX-calculus (PyZX [101]), and certified-compilation (Giallar [102]) verifiers on unstructured random Clifford circuits, none completed 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 [103]. Yet diagram and ZX verifiers scale well on structurally close compilation pairs, while unitary Clifford circuits admit efficient equivalence verification through tableau comparison [15], showing that no single verifier replaces state-vector verification across all circuit families. Test suites also diverge in circuit construction across domains: random generators account for 75% of matched calls in Cirq and 57% in Qiskit (suited for fuzzing transpiler passes), versus 5% in PennyLane (which tests analytical gradients on named states like GHZ, Bell, and W or structured ansätze). A problem can arise when coding agents transfer compiler-style random fuzzing to variational algorithms, Hamiltonian simulation, or QEC decoding, where correctness depends on symmetries or syndrome invariants that random circuits never probe.

Furthermore, passing existing unit tests provides evidence for expected behavior on small circuits, but is insufficient to verify behavior across machine-word boundaries, routing on larger topologies, or QEC logical error rates. Yet the practical impact of these verification gaps depends on developer workflows; in § 0.4, we examine how respondents validate AI-generated code and find they rely on automated tests less often than manual review.

Practice. Use small unit tests to check local correctness, but do not treat them as a sufficient acceptance criterion for coding agents. Supplement them with targeted verification above machine-word and partitioning thresholds (for example, $> 64$ qubits), and require agents to pair random-circuit fuzzing for compiler passes with invariant-preserving structured tests for algorithmic and QEC code.

Risks of agentic workflows

An agent that opens a pull request in a quantum repository can install packages, edit the continuous-integration configuration, and use credentials for hardware backends where each run costs money. Most of these risks are shared with other automated contributors that have write access. Installing packages can introduce malicious dependencies from public registries [104], while instructions embedded in issues or web pages can redirect an agent’s actions [105]. Established security practices for automated development therefore also apply to quantum repositories. Access to paid hardware introduces a financial risk, because repeated retries consume device time and incur charges even when the task remains unresolved. This risk also applies to agents using other paid computing services.

Furthermore, agents operating quantum experiments may also make scientifically consequential choices that successful code execution does not validate. In a neutral-atom workflow, an agent selected an unsuitable observable and produced an incorrect hardware diagnosis, both of which required domain-expert review to identify [39].

Practice. Run agents in isolated environments with task-specific permissions. Require maintainer approval before installing new dependencies or changing verification workflows. Enforce hardware access, spending, and retry limits outside the agent’s control. We provide templates for these boundaries in the companion repository [38].

The contributor pipeline

It has been reported that, in 81.7 percent of the public quantum repositories surveyed, maintenance rests on a single contributor [106]. These projects recruit and train future maintainers through good first issues and hackathons. Coding agents could take over this introductory work, reducing opportunities for newcomers to gain experience. Organizers of community hackathon events such as unitaryHACK also report that unverified AI-generated contributions shift maintainer time from mentoring to reviewing submissions [31]. Assessing how much of this work agents could take over requires understanding the tasks involved. The 417 unitaryHACK tasks analyzed in § 0.4 include feature development, compatibility work, documentation, and bug fixes. The candidate task collection described in § 0.5.3 provides material for future evaluations of these activities.

Completing a contribution with AI assistance also raises the question of what the contributor learns. A randomized study of developers learning an unfamiliar Python library found lower subsequent comprehension and debugging scores with AI assistance [107]. For newcomers, pressure to complete tasks quickly may conflict with the time needed to develop these skills [108]. Community projects should therefore make room for learning through implementation and debugging, alongside the goal of resolving issues. The longer-term question is whether participants continue contributing and eventually become maintainers. We present relevant evidence along this direction in § 0.4.

Practice. Maintainers should configure review agents with project documentation and verification tools, and evaluate them on previously reviewed pull requests. These agents should detect bugs and provide verification results for maintainer review. For introductory tasks, contributors should develop an initial approach before requesting generated code and use AI feedback to revise their own work. Maintainers and event organizers should allocate time for mentored implementation and debugging, and recognize learning alongside completed contributions. Follow-up tasks completed without AI assistance could assess whether participants can apply what they learned.

Evidence from the QOSS community

AI disclosure in public repositories

We first examine the community questions raised in § 0.3 using public repository records from 11 quantum projects and 8 other scientific Python projects. We measured how often contributors disclose AI involvement by scanning the attribution lines of commit messages and the text of pull requests. Specifically, we compare quarterly disclosure rates for commits and pull requests separately in Figure 2b. Disclosure is rare in both groups, with the median quantum project carrying a disclosure on 0.43 percent of its 2026 pull requests and the median mainstream project on 4.56 percent (Table I). We also compare project-level rates according to whether the pull request template asks contributors to disclose AI use, as shown in Figure 2c. All eight mainstream projects request disclosure, compared with three of the eleven quantum projects, so we interpret recorded disclosure in the context of project policy and as a lower bound on actual use. Individual contributors can also dominate these rates. In one project, 50 percent of 2026 commits carry a disclosure, and 1,107 of its 1,145 disclosing commits come from one maintainer (Figure 2d). This concentration limits what pooled rates can tell us about typical contributor behavior.

Maintenance tasks from community events

To examine maintainer workload and contributor experiences, we turn to records from unitaryHACK, an annual hackathon that we organize for projects across the quantum open-source community [36]. The event brings contributors and maintainers together to resolve project issues, develop skills, and introduce newcomers to QOSS. For this study, we compiled annual bounty lists and post-event surveys of contributors and maintainers from 2022 to 2026, which span the years before language models were in general use, the years after ChatGPT, and the current period of coding agents. Across these events, 7 to 14 maintainers and 16 to 33 contributors responded to each annual survey. Our dataset also includes written records of the 2026 maintainer meeting, attended by 27 maintainers. These records provide the basis for our analysis of maintainer workload, contributor experiences, and community responses to AI-assisted development.

The unitaryHACK records also document the maintenance work undertaken by participating projects. Across the five events, we identified 417 distinct candidate tasks from 812 bounty listings, spanning 110 QOSS repositories. Each candidate links an issue description (which might serve as an agent prompt) to a selected merged pull request (which might serve as the reference solution). For 275 candidates, the reference pull request modifies test-related files (Figure 3a,Figure 3b and Table I). The ratio of retained candidate tasks to bounty listings is 42 percent for 2022 and 65 percent for 2026 (Figure 3b).

Feature development and support for software use account for much of this work. Feature and method extensions constitute 225 tasks (54.0%), while documentation, examples, and presentation-oriented interfaces account for 74 (17.7%). The remaining tasks include bug fixes, compatibility and integration work, testing, refactoring, performance improvements, and build infrastructure. This composition reflects the work required both to extend software capabilities and to support their use and maintenance. We discuss the collection’s technical coverage, its relationship to existing evaluations, and the verification requirements for future agent benchmarking in § 0.5.3.

Community experiences with AI-assisted development

To examine AI use beyond individual community events, we analyze responses to the annual Quantum Open Source Software Survey conducted by Unitary Foundation [37]. We use a snapshot collected on 26 October 2026 comprising 1,691 respondents, while the survey remained open. Among the 917 respondents who answered the question on AI use, 715 reported using AI tools for quantum tasks. Across the six workflow tasks surveyed, 71 to 89 percent of respondents performing each task reported AI assistance (Figure 3c). These tasks range from reading research papers and learning quantum concepts to developing code and calibrating hardware. Respondents could report both manual work and AI assistance for a task. These responses describe individual tool use, complementing the contribution-level disclosure records analyzed above.

We also examine how respondents verify AI-generated code and assess its usefulness. Among the 621 respondents to the code-verification question, 79 percent reported manual review, 60 percent automated test or verification, and 17 percent formal verification, while 5 percent reported no verification (Figure 3d). Manual review was the most commonly reported method, and respondents could select multiple methods. Agreement was higher for the benefits of AI assistance than for the accuracy of its output. Among those who rated each statement, 83 percent agreed that AI assistants improved the efficiency and effectiveness of their quantum computing work ($n = 601$), compared with 59 percent who agreed that generated code was accurate ($n = 597$) (Figure 3e). These responses support making verification a routine part of AI-assisted development.

To examine the implications for contribution review, we return to the unitaryHACK surveys. In 2026, six of the 10 responding maintainers reported using AI tools in their work, and five reported having policies for AI contributions. We grouped free-text responses from nine maintainers and 16 contributors by topic. Maintainers most often raised human oversight (4 of 9) and review burden (3 of 9). Among contributors, six mentioned review burden and six mentioned contributors’ understanding of their changes, while 5 reported that AI tools had helped them. Only one respondent in each group raised disclosure.

When asked about workload after the 2026 unitaryHACK event, 5 of 10 maintainers reported more work than they had anticipated. The corresponding counts were 0 of 8 in 2023, 2 of 7 in 2024, and 4 of 14 in 2025. The free-text responses describe time spent explaining rejections of poor submissions and establishing how AI was used, even in otherwise acceptable contributions. One maintainer described maintaining as talking to an AI tool through the GitHub interface. At the 2026 meeting, maintainers discussed design conversations before pull requests, freezing issues that attracted competing submissions, and office hours before review. The organizers also limited each participant to four open pull requests at a time in 2026 to reduce AI slop.

What the community can build

The evidence in Sections 3 and 4 identifies practical needs in verification, agent evaluation, and contribution review (Table 1). These needs also arise when agents use QOSS to conduct research. Here we propose tools and practices that help projects assess software contributions and build research environments in which agents can explore candidate solutions under explicit scientific criteria.

To support these proposals, we provide resources that projects can adapt to their own workflows in the companion repository [38]. These resources include a verifier catalog documenting tool capabilities and limitations, guidance on collecting and preparing candidate maintenance tasks for future benchmarking, and contribution templates for reporting changes and verification evidence. We also provide draft agent harness designs that describe how agents can use these tools during development and research. Furthermore, we maintain an annotated reading list to help readers follow the relevant literature as the field develops [38].

As an illustrative example, our draft harness outlines how an agent could modify a quantum compiler to reduce two-qubit gate counts. The agent would evaluate each proposed change on a fixed circuit set using equivalence checks whose acceptance criteria it cannot modify. Projects can use our verifier catalog to select tools based on their scope and limitations. Contributors can then use our provided templates to report their changes, verification results, and AI assistance for maintainer review.

Verification beyond full-state simulation

To extend verification beyond the small circuits described in § 0.3.2, projects need methods that do not require full-state simulation. Equivalence verifiers such as decision diagrams [100] and ZX-calculus rewriting [101] can verify whether a compiled circuit preserves the intended computation, including transformations proposed by AI tools. Their worst-case cost remains exponential, so projects should evaluate their runtime on the circuit families and sizes they intend to support. Stabilizer simulation provides another option for Clifford circuits, reaching tens of thousands of qubits [15]. This supports verification of large stabilizer error-correction circuits, while non-Clifford operations require other methods such as Clifft [109]. Detector error models, which represent errors in quantum error-correction experiments [15], also support efficient equivalence verification. For these models, verification runs in quasilinear time and is exact for non-adaptive pipelines and sound for partially adaptive pipelines such as lattice surgery [110].

Beyond verifying circuits and error models, we can use proof assistants [111, 112, 113, 114, 115, 116, 117, 118, 119] to formalize the mathematical results underlying quantum software. The open-source optimizer tzap includes a Lean 4 implementation with mechanized correctness proofs for core deterministic Clifford+$T$ and $R_z$ optimization passes alongside its Rust implementation [111, 112], while also illustrating a practical scope boundary: newer high-level synthesis and heuristic passes in the Rust and Python codebase evolve faster than the formal gate model. Lean-QEC formalizes stabilizer-code theory in Lean 4 and certifies distance lower bounds for bivariate bicycle codes, including a 90-qubit instance. It uses a verified reduction to Boolean satisfiability and verifies the resulting solver certificates in Lean, removing reliance on unverified solver outputs [113]. Developing such proofs requires work on formal definitions and supporting lemmas, which can then be reused in later proofs. Coding agents can help develop these formal libraries by completing proofs. Two Lean 4 benchmarks evaluate this capability through 36 and 40 theorem-completion tasks in quantum algorithms and quantum information theory [114]. The best of four models scores 60.4 and 59.6 out of 100, respectively, on a difficulty-weighted scale. Access to a verified domain library improves both scores and completion rates across all eight model–benchmark pairs, with gains of up to 15.9 points. These results support community investment in verified libraries that agents can reuse and extend.

Before adding a verifier to continuous integration, projects should state which properties and circuit families it covers and the sizes at which it remains practical. We maintain a catalog recording this scope, computational cost, and tool maturity in the companion repository [38]. The catalog also identifies priorities for further work. Equivalence verification for non-Clifford circuits beyond exact simulation needs clear soundness guarantees and evidence of practical scaling. Other priorities include distance certification for broader qLDPC code families and automated verification that noise-model parameters satisfy physical constraints. Transpiler passes could also generate correctness certificates for a separate, simpler verifier, removing the transpiler implementation from the components whose correctness must be trusted. Together, these developments would automate more of the verification work currently required of reviewers.

Open-source harnesses for AI-driven research

A research harness connects an agent to the software that generates, evaluates, and records candidate solutions. These harnesses are being deployed effectively across tasks in quantum information and computing research [25, 69, 73, 87]. We recommend making the scientific objective explicit before choosing a score, since an easily measured improvement may capture only part of the intended research goal. For quantum error correction, for example, code parameters and logical error rates under a specified noise model address different questions. A harness should state which of these it evaluates and the assumptions under which comparisons are meaningful.

As an example, the QEC Challenge illustrates how an open repository can support this process through shared submission rules and automated checks [74]. Its verification pipeline checks code structure and searches for logical operators that refute a claimed distance. This supports iterative discovery while leaving a clear distinction between a candidate that survives the search and a code whose distance has been certified. We recommend preserving this distinction in the feedback given to agents and in the results reported to the community.

We further propose separating the agent’s search process from the final evaluation, with acceptance criteria that the agent cannot modify [87]. Promising candidates should undergo verification appropriate to the claim, with additional tests or stronger certification where needed. We also encourage projects to retain enough information to reproduce each result’s construction and evaluation, including the software environment and computational budget. Open-source communities can then contribute improved evaluators and checks alongside new candidates, allowing the research process itself to be inspected and refined.

Benchmarks built from real repository work

QOSS maintenance involves modifying existing repositories beyond short programs and functions. SWE-bench evaluates this type of work by asking agents to resolve GitHub issues and assessing their changes with repository tests [24]. AInsteinBench applies repository-level evaluation to scientific software across six codebases, including Qiskit [120]. Quantum Arena further provides a public leaderboard comparing general-purpose LLMs and quantum-specific coding assistants on quantum-programming benchmarks [121]. The pilot collection described in § 0.4 contains 417 candidate maintenance tasks from 110 QOSS repositories across five unitaryHACK events. Across the candidate tasks, selected reference changes have a median of approximately 300 modified lines. The collection’s coverage of feature development, documentation, and other maintenance activities provides material for evaluating how agents extend and maintain existing projects.

The tasks span several parts of the quantum software stack, with uneven representation across domains. Circuit, operator, and intermediate-representation tasks account for 141 cases, and simulation or numerical methods for 86. Error correction and error mitigation account for 12 and 10 tasks, respectively, and domain labels can overlap. The frameworks involved include Qiskit, PennyLane, and Cirq, with Qiskit appearing directly in 53 tasks across 26 repositories. Python files are modified in 76.5% of tasks, alongside changes in Julia, Rust, C++, and other languages. These file-based counts include test and documentation changes. Simulator involvement is recorded for 96 tasks and provider-interface involvement for 24, including Amazon Braket, IonQ, and IBM Quantum. Provider-interface involvement includes mocked API tests and does not establish execution on quantum hardware. This distribution reflects the participating projects and their bounty choices.

The variety of maintenance activities requires verification matched to each task’s requirements. A merged pull request may address only part of an issue, and changes to test files do not establish complete coverage or scientific correctness. For circuit transformations intended to preserve the computation, equivalence verification can assess correctness. Numerical methods require appropriate reference values or invariants, and performance changes require correctness and resource measurements. Documentation and interface tasks may combine executable examples, build or interaction tests, and maintainer review. Future work should establish reproducible project environments and task-specific verification criteria before evaluating agents on the collection.

Once these criteria are established, the tasks could also provide a way to study the role of verification. For circuit-transformation tasks, we can compare an agent given repository tests alone with one given additional equivalence verification during development. Holding the agent configuration, computational budget, and final evaluation criteria fixed would allow us to measure how the additional verification affects the resulting solutions. These comparisons require scoring criteria that reflect the intended capability. For example, Quantum-Harbor verifies scientific results against recorded data or fresh hidden evaluations and distinguishes scientific errors from submission failures [87]. Repository benchmarks should likewise accept valid alternative implementations and isolate reference solutions and held-out evaluation data from the agent. Future benchmark evaluations should also examine how programming language affects agent performance. Comparisons on similar tasks with a fixed agent configuration could help distinguish the effects of compiler feedback from differences in model familiarity with each language and its libraries. Such evidence could inform language choices for new QOSS projects alongside runtime performance and maintenance needs.

Annual community events such as unitaryHACK provide a recurring source of candidate tasks for future benchmark updates. We recommend collecting and archiving issue descriptions, merged reference solutions, and associated tests as tasks are completed, preserving these records as repositories change (Figure 3b). For each model, evaluations should prioritize tasks resolved after its training cutoff to reduce contamination from previously published solutions [122]. Task recency alone does not establish freedom from training contamination. We provide the collection and classification methods and aggregate results in the companion repository [38], while the task list remains unreleased. The collection method can also be applied to other projects with linked issues and merged pull requests.

Standards for AI contributions

AI should reduce the cost of contributing to and using open-source software without lowering the standards of responsibility, evidence, and reciprocity that make open source work. This is particularly important in quantum software, where AI-generated claims may rely on subtle mathematical assumptions or physical intuitions, making hallucinations difficult to detect and increasing the cost of verification. Open-source implementations and reproducible results help make these claims independently verifiable, but this openness must be matched by good research and development hygiene: clearly documenting assumptions, rigorously checking results, and giving proper credit to the people whose ideas, methods, and code make the work possible.

Contribution standards should require authors to explain the value of a result and provide evidence that others can assess without repeating the entire investigation. Our unitaryHACK surveys identify review workload, human oversight, and contributors’ understanding of their changes as recurring concerns (§ 0.4). The broader QOSS survey finds that manual review is the most commonly reported method for verifying AI-generated code, with automated tests reported less often. Together, these findings motivate contribution requirements that provide reviewers with reproducible verification evidence. We recommend applying these requirements to all contributions, including those developed with AI assistance.

To put these requirements into practice, we suggest that contributors should explain the intended outcome of a change and provide reproducible verification evidence. Bug reports and fixes should include reproducing examples to reduce the review burden illustrated by the curl case in § 0.3 [96]. New features or methods should include verification against stated functional or performance requirements. Automated workflows should run the required verification procedures before maintainer review. Project-specific review agents can detect bugs and summarize verification results, as discussed in § 0.3.4. Maintainers can then assess whether the evidence supports the proposed change and decide whether to accept it.

Alongside verification evidence, contributions should record which AI tools were used and which parts of the work they assisted. Tool names and versions can be recorded automatically where available to support later investigation of tool-related problems. Acceptance should depend on the quality of the contribution and its verification evidence. Contributors remain responsible for explaining their changes and responding to issues raised during review [123, 124]. We provide contribution templates and configurations for automated verification in the companion repository [38].

Finally, we propose taking verified QOSS contributions as a form of research publication on equal footing with journal or conference articles. For certain quantum research results such as computational methods, a versioned software release with reproducible evidence may communicate the result more effectively than a standalone paper. Such contributions should explain their scientific significance and limitations and provide clear attribution, so that researchers and agents can assess and reuse them.

Outlook

Our analysis identifies verification and maintenance as central to the practical use of AI in QOSS. We draw on project data and community records, and characterize a pilot collection of candidate maintenance tasks for future agent evaluation. The collection identifies maintenance activities and verification requirements that future studies could examine alongside the review effort required from maintainers. The broader goal is to support both reliable quantum software and AI-driven research whose results the community can independently assess and build upon.

For quantum software development, we propose that future evaluations should establish how model capability, access to project knowledge, and verification affect the quality and cost of agent-generated changes. Comparisons on maintenance tasks with common final evaluation criteria could determine whether additional verification improves correctness and reduces subsequent review effort. Sharing verified examples and formal libraries would allow projects to reuse this work while retaining their own interfaces and development practices. These evaluations should also account for bugs discovered after merging and the effort required to maintain accepted changes.

For AI-driven auto-research, QOSS can provide environments in which agents explore open problems in quantum information and computation [125, 126]. We further propose evaluating whether agents can select productive research directions and revise their approaches in response to unsuccessful attempts. Such evaluations should establish whether the resulting findings remain valid beyond the conditions explored during the search and can be independently reproduced. Recording computational costs alongside scientific outcomes would help identify where agent-driven exploration is useful and which improvements to software and verification tools would most benefit further research.

Sustaining both directions will require attention to the communities that develop and maintain this infrastructure. We recommend assessing changes in review effort alongside opportunities for contributors to learn and take responsibility for their work. Review agents could help maintainers devote more time to design and mentoring. Our October 2026 analyses provide a baseline for tracking maintenance activity through public repository records, complemented by surveys of review effort and contributor experiences. We also propose using these community records and evaluation resources for metascience research on how AI changes scientific practice. Given the rapid development of the field, we maintain supporting resources in an open companion repository so that the analyses and proposals can evolve with frameworks and AI capabilities [38]. These efforts will help the community develop reliable quantum software and verifiable AI-driven research while sustaining the expertise needed to support both.

Acknowledgments

We thank Travis L. Scholten (IBM Quantum and Unitary Foundation Board of Directors) for his valuable feedback on earlier drafts of this manuscript. We thank Mateo Uldemolins for helpful feedback on the manuscript. M.R.’s work has been supported by the Mozilla Foundation. We used OpenAI Codex and Claude Code to assist with literature searches, manuscript preparation, and the development of data-analysis and plotting scripts.

Data and code availability

Data for the figures are available in the companion repository at https://github.com/unitaryfoundation/ai4qoss. The repository also provides methodological descriptions and example code and configurations for automated verification. For the candidate task collection, we provide collection and classification methods, category definitions, and aggregate statistics.

References