Paper deep dive
QuSema: Detecting Silent Bugs in Quantum Libraries via Quantum-knowledge-enhanced Agents
Yujin Song, Kaining Zhang, Qixin Zhang, Shuai Wang, Pingchuan Ma, Yuxuan Du
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 10/11/2026, 4:14:46 AM
Summary
The paper introduces QuSema, an autonomous testing agent designed to detect silent bugs in quantum libraries like Qiskit and PennyLane. Unlike existing methods that rely on failure-based or comparison-based oracles, QuSema uses quantum semantics and documentation as a source-level semantic oracle to identify implementation logic deviations. It employs Large Language Models (LLMs) to reason about intended behavior, generate executable tests, and validate semantic deviations. QuSema outperforms coding agents like Claude Code and Codex on historical bug benchmarks and discovered 40 previously unknown bugs, including 30 silent bugs, in real-world libraries.
Entities (11)
Relation Signals (9)
QuSema → implementsfor → Qiskit
confidence 98% · We implement QuSema for Qiskit and PennyLane.
QuSema → implementsfor → PennyLane
confidence 98% · We implement QuSema for Qiskit and PennyLane.
QuSema → detects → Silent Bugs
confidence 95% · QuSema: Detecting Silent Bugs in Quantum Libraries... QuSema achieves higher mean bug relocation counts... QuSema also discovers 40 previously unknown bugs... including 30 silent bugs.
QuSema → uses → Large Language Models
confidence 95% · QuSema employs large language models (LLMs) to reason about implementation behavior using relevant quantum semantics and documentation.
QuSema → usesasoracle → Quantum Semantics
confidence 95% · QuSema uses constraints from quantum semantics and documentation as a source-level semantic oracle
Differential Testing → islimitedby → Limited Availability of Expected Relations
confidence 90% · Their reliance on black-box test oracles introduces two fundamental limitations. (L1). Limited Availability of Expected Relations Between Execution Results.
Metamorphic Testing → islimitedby → Inefficient Triggering Without Semantic Guidance
confidence 90% · (L2). Ineffective Triggering Without Semantic Guidance. Many quantum-software functionalities involve complex mathematical semantics... Generic program generation may require extensive exploration
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Quantum libraries are now critical infrastructure for quantum algorithm development, yet their correctness remains difficult to test. Existing testing techniques mainly rely on failure-based or comparison-based oracles, exposing bugs only when executions fail, violate runtime checks, or disagree with another implementation. Their applicability is limited when suitable execution-based oracles are unavailable, leaving some silent bugs undetected. Such missed bugs can produce incorrect results that propagate into experimental conclusions, simulation studies, and algorithmic designs. Here we present QuSema, an autonomous testing agent for finding silent bugs in quantum libraries. QuSema uses constraints from quantum semantics and documentation as a source-level semantic oracle to assess whether implementation logic can produce invalid outputs from valid inputs. It operates through an agentic loop that repeatedly inspects library API documentation and source code, reasons about the intended behavior of quantum operations, identifies potential semantic deviations, and validates them by generating executable tests through library APIs. Guided by quantum-domain reasoning, QuSema turns high-level behavioral mismatches into concrete, user-triggerable bug reports, enabling it to uncover non-crash defects. We implement QuSema for Qiskit and PennyLane. On a benchmark of 20 historical silent bugs, QuSema achieves higher mean bug relocation counts than Claude Code and Codex, with the DeepSeek configuration costing less than Claude Code. QuSema also discovers 40 previously unknown bugs confirmed by the developers, including 30 silent bugs.
Tags
Links
- Source: https://arxiv.org/abs/2610.10258v1
- Canonical: https://arxiv.org/abs/2610.10258v1
Trouble viewing inline? Open PDF directly →
Full Text
99,768 characters extracted from source content.
Expand or collapse full text
QuSema: Detecting Silent Bugs in Quantum Libraries via Quantum-knowledge-enhanced Agents Yujin Song Affiliation: Nanyang Technological University, Singapore email: SONG0316@e.ntu.edu.sg , Kaining Zhang Note: Corresponding authors. Affiliation: Nanyang Technological University, Singapore email: kaining.zhang@ntu.edu.sg , Qixin Zhang Affiliation: Nanyang Technological University, Singapore email: qixin.zhang@ntu.edu.sg , Shuai Wang Affiliation: Hong Kong University of Science and Technology, Hong Kong, China email: shuaiw@cse.ust.hk , Pingchuan Ma Affiliation: Zhejiang University of Technology, Hangzhou, China email: pma@zjut.edu.cn and Yuxuan Du Affiliation: Nanyang Technological University, Singapore email: yuxuan.du@ntu.edu.sg © none Abstract. Quantum libraries are now critical infrastructure for quantum algorithm development, yet their correctness remains difficult to test. Existing testing techniques mainly rely on failure-based or comparison-based oracles, exposing bugs only when executions fail, violate runtime checks, or disagree with another implementation. Their applicability is limited when suitable execution-based oracles are unavailable, leaving some silent bugs undetected. Such missed bugs can produce incorrect results that propagate into experimental conclusions, simulation studies, and algorithmic designs. Here we present QuSema, an autonomous testing agent for finding silent bugs in quantum libraries. QuSema uses constraints from quantum semantics and documentation as a source-level semantic oracle to assess whether implementation logic can produce invalid outputs from valid inputs. It operates through an agentic loop that repeatedly inspects library API documentation and source code, reasons about the intended behavior of quantum operations, identifies potential semantic deviations, and validates them by generating executable tests through library APIs. Guided by quantum-domain reasoning, QuSema turns high-level behavioral mismatches into concrete, user-triggerable bug reports, enabling it to uncover non-crash defects. We implement QuSema for Qiskit and PennyLane. On a benchmark of 20 historical silent bugs, QuSema achieves higher mean bug relocation counts than Claude Code and Codex, with the DeepSeek configuration costing less than Claude Code. QuSema also discovers 40 previously unknown bugs confirmed by the developers, including 30 silent bugs. Keywords: quantum library testing, quantum computing, silent bugs, coding agents 1. Introduction Quantum computing (Dalzell et al., 2025; Nielsen and Chuang, 2001) offers the potential to tackle computational problems beyond the reach of classical methods, with promising applications in quantum chemistry (McArdle et al., 2020), optimization (Abbas et al., 2024), and machine learning (Cerezo et al., 2022). To facilitate the design and refinement of quantum algorithms, quantum software libraries such as Qiskit (Javadi-Abhari et al., 2024) and PennyLane (Bergholm et al., 2018) have been developed and widely adopted. These libraries provide essential support for building, simulating, and executing quantum algorithms, and have become critical infrastructure in the quantum software ecosystem. However, quantum software is still in its early stage, and these rapidly evolving libraries contain bugs that lead to incorrect or unexpected behaviors (Paltenghi and Pradel, 2022). Accordingly, systematic quantum software testing (Dwivedi et al., 2024) is becoming increasingly essential for building a reliable and robust quantum software ecosystem. Substantial research effort has been devoted to quantum software testing, particularly automated bug detection for quantum libraries (Paltenghi and Pradel, 2024a). Existing approaches have shown promising results (Xia et al., 2026; Xia et al., 2024) for crash bugs (Rosa and Santiago, 2026), where exceptions or program termination provide explicit failure signals. Beyond crash bugs, quantum libraries also contain silent bugs (Zappin et al., 2026), which return incorrect results that violate intended behavior or quantum semantics without explicit failures. For example, a quantum library may return an incorrect commutativity judgment for a pair of quantum operators (Qiskit Developers, 2026c) or apply a quantum circuit optimization method that does not preserve semantics of the original circuit (Qiskit Developers, 2024b). These incorrect but undetected results can propagate through downstream workflows, which in turn mislead algorithm design, lead to erroneous hardware executions, and waste quantum computing resources (Upadhyay et al., 2026). To mitigate these risks and improve reliability, quantum software testing should be capable of effectively detecting silent bugs in quantum libraries. Current approaches to silent bug detection in quantum libraries mainly rely on differential testing (Wang et al., 2021; Klimis et al., 2025; Blackwell et al., 2024; Ye et al., 2026; Paltenghi and Pradel, 2025) and metamorphic testing (Paltenghi and Pradel, 2023; Kitt and Cohen, 2024; Luo et al., 2026). Differential testing analyzes the same quantum circuit across different quantum software stacks and checks whether equivalent outputs are observed (Andrews et al., 2026). Metamorphic testing instead applies transformations that should preserve circuit semantics, such as inserting identities or replacing a gate with an equivalent decomposition, and checks the expected relations between execution results from the source and transformed programs (Fortunato et al., 2024). Both approaches use black-box test oracles (Rigger and Su, 2022) to validate expected relations between execution results (Gao et al., 2026). While these approaches have successfully detected silent bugs in quantum libraries (Wang et al., 2021; Klimis et al., 2025; Blackwell et al., 2024; Ye et al., 2026; Paltenghi and Pradel, 2025; Paltenghi and Pradel, 2023; Kitt and Cohen, 2024; Luo et al., 2026), their reliance on black-box test oracles introduces two fundamental limitations. (L1). Limited Availability of Expected Relations Between Execution Results. Some quantum library functionalities lack either semantically corresponding implementations across libraries for differential testing or circuit transformations with predictable output relations for metamorphic testing. For example, PennyLane supports the resource-estimation functionality (PennyLane, 2026) for predefined algorithms, while Qiskit has no counterpart (Qiskit Developers, 2026t), and semantics-preserving transformations may still change resource quantities such as gate count or circuit depth. Consequently, approaches that employ black-box test oracles cannot provide complete coverage of quantum library functionality. (L2). Ineffective Triggering Without Semantic Guidance. Many quantum-software functionalities involve complex mathematical semantics (Salam and Ilyas, 2024), and their bugs are triggered only under specific semantic conditions (Leite Ramalho et al., 2025). Such conditions may involve specific parameter values, quantum operations, or circuit layouts (Hu et al., 2024). Generic program generation may require extensive exploration to trigger these conditions (Li et al., 2026), limiting the effectiveness of black-box testing. To address these limitations, we develop QuSema, an automated agent for detecting silent bugs in quantum libraries by auditing Quantum Semantics. Its design follows our data-flow analysis, which localizes a silent bug to the library API that first transforms a valid input into an invalid output. Our study of reported bugs in Qiskit and PennyLane provides supporting evidence for this localization. QuSema therefore targets such API-local semantic deviations by directly analyzing the relevant implementation logic. More precisely, QuSema employs large language models (LLMs) (Wei et al., 2025; Mikuriya et al., 2025) to reason about implementation behavior using relevant quantum semantics and documentation. This information serves as a source-level semantic oracle for identifying candidate defects, which are subsequently validated through execution and checked for triggerability through documented library APIs. This design brings quantum semantics into source-level correctness reasoning and extends silent bug detection beyond cases covered by existing execution-based relations. We systematically evaluate QuSema on Qiskit and PennyLane, two widely used quantum libraries. On a benchmark of 20 historical silent bugs, QuSema substantially outperforms Claude Code and Codex in localizing known defects. When instantiated with DeepSeek as its LLM backend, QuSema achieves this performance at a lower estimated cost than Claude Code and a comparable cost to Codex. Beyond historical benchmarks, applying QuSema to real-world quantum libraries uncovers 40 previously unknown bugs confirmed by developers, including 30 silent bugs. The identified bugs span quantum-program execution, semantic analysis, and library infrastructure. Notably, five of these silent bugs affect functionalities that lack either comparable implementations or suitable circuit transformations with known output relations. Such bugs fall beyond the detection scope of existing differential and metamorphic testing methods. These results validate the practical value of grounding source code inspection in quantum semantics for systematic silent bug detection across large quantum libraries. In summary, our main contributions can be summarized in threefold: ∙ We characterize silent bugs in quantum libraries and show that all examined cases are API-local, leaving semantic evidence in implementation logic and documentation. This defines a well-scoped and prevalent bug class for source-level detection with quantum semantics. ∙ We propose QuSema, an automated testing agent that uses LLMs to reason about quantum semantics and implementation logic. By inferring semantic constraints from library source code and identifying potential implementation logic deviations from contracts and quantum semantics, it provides a new paradigm for silent bug detection in various quantum software libraries. ∙ We demonstrate the effectiveness of QuSema on 20 historical silent bugs through comparisons with coding agents and ablation studies. In addition, QuSema discovers 40 previously unknown bugs in Qiskit and PennyLane that are confirmed by developers, including 30 silent bugs, 5 of which affect functionality beyond the coverage of existing differential and metamorphic testing. 2. Background This section provides the background on quantum computing, quantum-library structure, and existing bug detection approaches. In Sec. 2.1, we review basic concepts in quantum computing. In Sec. 2.2, we describe the functionality and software structure of quantum libraries. Finally, in Sec. 2.3, we review existing approaches to silent bug detection in quantum libraries. 2.1. Basic Concepts in Quantum Computing Qubits and Quantum States. Quantum information is represented by quantum states, with the qubit as the fundamental unit (Nielsen and Chuang, 2001). In the computational basis |0⟩,|1⟩\|0 ,|1 \, where |0⟩=(1,0)T|0 =(1,0)^T and |1⟩=(0,1)T|1 =(0,1)^T, a pure qubit state can be written as |ψ⟩=α|0⟩+β|1⟩|ψ =α|0 +β|1 , where α,β∈ℂα,β satisfy |α|2+|β|2=1|α|^2+|β|^2=1. For n qubits, the basis states are formed through tensor products as |x⟩=|x1⟩⊗⋯⊗|xn⟩|x =|x_1 ·s |x_n for each xi∈0,1x_i∈\0,1\, which span a 2n2^n-dimensional Hilbert space. An n-qubit pure state can be expressed as |ψ⟩=∑x∈0,1nαx|x⟩|ψ = _x∈\0,1\^n _x|x , where ∑x|αx|2=1 _x| _x|^2=1. Quantum Gates. Quantum gates act on quantum states through unitary operators. Up to a global phase, a single-qubit unitary can be written as U(θ,φ,λ)=[cos(θ/2)−eiλsin(θ/2)eiφsin(θ/2)ei(φ+λ)cos(θ/2)]U(θ, ,λ)= [ smallmatrix (θ/2)&-e^iλ (θ/2)\\ e^i (θ/2)&e^i( +λ) (θ/2) smallmatrix ]. Common single-qubit gates include H=12[111−1]H= 1 2 [ smallmatrix1&1\\ 1&-1 smallmatrix ], the Pauli gates X=[0110]X= [ smallmatrix0&1\\ 1&0 smallmatrix ], Y=[0−i0]Y= [ smallmatrix0&-i\\ i&0 smallmatrix ], Z=[100−1]Z= [ smallmatrix1&0\\ 0&-1 smallmatrix ], S=[100i]S= [ smallmatrix1&0\\ 0&i smallmatrix ], and Pauli rotations RP(θ)=e−iθP/2=cos(θ/2)I−isin(θ/2)PR_P(θ)=e^-iθ P/2= (θ/2)I-i (θ/2)P for P∈X,Y,ZP∈\X,Y,Z\. Controlled gates apply an operation conditionally. For a single-qubit target, CU(θ,φ,λ,γ)=|0⟩⟨0|⊗I+eiγ|1⟩⟨1|⊗U(θ,φ,λ) CU(θ, ,λ,γ)=|0 0| I+e^iγ|1 1| U(θ, ,λ), which gives CNOT for U=XU=X and γ=0γ=0. Quantum Circuits. A quantum circuit represents quantum operations on qubit wires. For example, a single-qubit unitary U is represented as U, and its controlled version as U, where the filled dot denotes the control qubit. For input |ψ⟩|ψ and gates U1,…,UkU_1,…,U_k applied left to right, the output is |ϕ⟩=Uk⋯U1|ψ⟩|φ =U_k·s U_1|ψ . Their arrangement determines circuit depth and gate count. Different circuit structures may implement the same computation, enabling semantics-preserving circuit transformation and compilation. 2.2. Functionality and Software Structure of Quantum Libraries Quantum Library Functionality. Quantum libraries provide functionality in three main categories: Quantum programming language, Compilation, and Execution environment (Paltenghi and Pradel, 2022). The first provides quantum and classical abstractions, such as gates, circuits, matrices, and tensors, together with domain-specific abstractions for quantum algorithms. Compilation supports intermediate representations, circuit optimization, and code generation. The execution environment provides hardware interfaces, simulators, and quantum state evaluation, including measurement and error mitigation. Auxiliary components support testing, visualization, and software integration. Individual libraries implement different parts of this functionality. Library APIs. Quantum software libraries expose their functionality through APIs in a host programming language (Upadhyay et al., 2025). In Qiskit and PennyLane, documented user-facing APIs are primarily Python functions and methods. Their official documentation specifies intended usage, accepted inputs, expected outputs, and relevant behavioral constraints. These APIs provide the interface through which users construct quantum programs and access library functionality. Code Segments. A library API is typically implemented by one or more functions or methods in the source code. Following prior work (Altmayer Pizzorno and Berger, 2025), we refer to each function or method as a code segment. A library API may invoke multiple code segments, while the same code segment may participate in multiple APIs. Code segments may also contain local documentation, such as docstrings or source comments. For segments that do not correspond to documented API entries, this local documentation is not part of the official API documentation. 2.3. Existing Approaches to Bug Detection in Quantum Libraries Bugs can manifest as explicit crashes such as exceptions and resource exhaustion, or as silent bugs that produce incorrect behavior without interrupting execution (Rosa and Santiago, 2026). An empirical study (Paltenghi and Pradel, 2022) shows that quantum-specific bugs frequently manifest as incorrect outputs rather than crashes. Accordingly, silent bug detection in quantum libraries has received substantial attention. Existing methods in this context primarily fall into two categories. Differential Testing. Quantum differential testing detects inconsistencies by comparing corresponding executions across different quantum software stacks (Andrews et al., 2026). Concretely, QDiff (Wang et al., 2021) and QITE (Paltenghi and Pradel, 2025) derive comparable programs through program transformations. Blackwell et al. (Blackwell et al., 2024) and FuzzQ (Klimis et al., 2025) employ fuzzing to generate test programs, guided respectively by predefined grammars and constraints from a formal model. QSPE (Ye et al., 2026) systematically enumerates program variants from skeletal programs and compares their final state vectors. Metamorphic Testing. Quantum metamorphic testing applies transformations that should preserve circuit semantics and checks whether the resulting executions satisfy expected relations (Fortunato et al., 2024). Specifically, MorphQ (Paltenghi and Pradel, 2023) derives transformed programs using quantum metamorphic relations, while MorphQ++ (Kitt and Cohen, 2024) extends these transformations to additional circuit representations and transpilation settings. QEMI (Luo et al., 2026) constructs equivalent program variants by eliminating code that does not affect selected inputs in quantum programs with control flow. These methods exercise circuit construction, compilation, and execution, involving functionality from the three categories introduced in Sec. 2.2. Moreover, their applicability to individual functionalities depends on whether corresponding executions or suitable circuit transformations can be constructed. Differential and metamorphic testing rely on black-box test oracles that evaluate relations between execution results. Their applicability therefore depends on the availability of comparable executions or suitable metamorphic relations, leaving some quantum library functionalities difficult to test. In contrast, QuSema derives semantic oracles directly from source-level implementation logic, enabling silent bug detection without requiring such predefined relations. LLM-based Testing. Recent studies have explored large language models (LLMs) for test generation, input construction, fuzzing, and debugging (Deng et al., 2023; Deng et al., 2024; Xia et al., 2024; Zhang et al., 2025; Jiang et al., 2024; Yang et al., 2024a; Zhang et al., 2024; Altmayer Pizzorno and Berger, 2025; Pham et al., 2026). These methods primarily use LLMs to generate test cases and expose failures through program execution, without directly reasoning about semantic defects in library implementations. In contrast, QuSema uses the LLM to analyze implementation logic and identify potential semantic deviations. These candidates are subsequently verified and checked for triggerability through documented library APIs. 3. Current Limitations and Semantic Evidence for Quantum Silent Bug Detection In this section, we analyze the limitations of existing silent bug detection methods in quantum libraries and explore source-level semantic evidence as a potential basis for broader and more efficient bug detection. For clarity, we first analyze two limitations of existing approaches employing black-box test oracles in Sec. 3.1, namely (L1) incomplete functionality coverage due to unavailable expected relations between execution results and (L2) inefficient bug triggering without semantic guidance. We then analyze in Sec. 3.2 how data flow can be used to localize semantic deviations to individual library APIs and examine reported bugs to support this analysis. Finally, in Sec. 3.3, we discuss the implications and challenges of using this evidence for reliable silent-bug detection. 3.1. Two Limitations of Existing Approaches Existing approaches for detecting silent bugs in quantum libraries, particularly differential and metamorphic testing introduced in Sec. 2.3, mainly rely on black-box test oracles (Rigger and Su, 2022). They have shown effectiveness for functionalities such as circuit execution and compilation, yet two limitations defined in Sec. 1 (i.e., (L1) and (L2)) remain. For some quantum library functionalities, the expected relations between execution results cannot be established. This occurs when cross-library counterparts are unavailable or circuit-level transformations do not yield predictable output relations. Moreover, many silent bugs are triggered only under specific quantum semantic conditions, making generic program generation inefficient. Below, we elaborate on these two limitations with representative examples in Fig. 1. Figure 1. Limitations of approaches employing black-box test oracles. (a) Limited availability of expected relations between execution results, where equivalent circuits can have different resource counts and some higher-level resource-estimation functionality lacks a cross-library counterpart. (b) Inefficient triggering, where a bug when implementing the CU gate is exposed only under specific semantic conditions. (L1) Limited Availability of Expected Relations Between Execution Results. For some functionalities in quantum libraries, the expected relations between execution results needed for differential or metamorphic testing cannot be established. Here, we use resource estimation as a representative example to illustrate the limitations of both metamorphic and differential testing. As shown in Fig. 1(a), PennyLane provides the qml.estimator.estimate API to estimate the gate count required to implement a quantum circuit or operator under a specified gate set. For metamorphic testing, consider Trotterized time evolution under the Hamiltonian H=Y0Y1H=Y_0Y_1. The same functionality reports 3 and 9 gates for two equivalent circuit representations using the gate sets RY,CNOT,CY\R_Y,CNOT,CY\ and RY,CNOT,S,Z\R_Y,CNOT,S,Z\, respectively. Because the gate count is not preserved across semantics-preserving circuit transformations, the expected relation between the two outputs is unavailable as a metamorphic oracle. For differential testing, the same resource-estimation functionality presents a different limitation. PennyLane supports resource estimation for predefined quantum algorithms such as the illustrated Trotter decomposition, while Qiskit does not provide a corresponding functionality. Consequently, no cross-library output is available to construct a differential oracle. (L2) Inefficient Triggering Without Semantic Guidance. Approaches based on black-box test oracles rely on testing generated programs to expose faulty behavior. In practice, many silent bugs in quantum libraries are triggered under specific semantic conditions involving parameter values, quantum states, or circuit structures. Generic testing may require substantial exploration to reach the defective implementation under these conditions. We use Qiskit #13118 (Qiskit Developers, 2024h) in Fig. 1(b) as a representative case. As shown on the left side of the figure, the Python library API qc.cu is designed to implement the gate CU. Its call path passes through CUGate and reaches the Rust kernel cu_gate, which incorrectly swaps parameters ϕφ and λ. A test exposes this bug only if it reaches cu_gate with ϕ≠λφ≠λ and sin(θ/2)≠0 (θ/2)≠ 0. Generic testing may require repeated executions to meet these conditions, leading to inefficient bug triggering as shown on the right side of Fig. 1(b). These examples reflect two key limitations of existing approaches that employ black-box test oracles for quantum libraries. These limitations motivate alternative approaches. 3.2. Motivating Study: Source-Level Semantic Evidence In this section, we analyze how silent bugs arise along the data flow of quantum programs and how their origins can be identified from source-level semantic evidence. Specifically, we first characterize silent bugs as semantic deviations that produce invalid outputs from valid inputs and localize each deviation to the first library API that introduces it. We then use a representative bug to illustrate how inconsistencies between implementation logic and quantum semantics or documentation provide evidence for identifying such defects. Characterization of Silent Bugs. We consider an input or output valid if it satisfies the relevant quantum semantics and does not violate the documentation, and invalid otherwise. At the code-segment level, validity also includes applicable software semantics, since local implementation logic may manipulate objects not fully constrained by quantum semantics. Under these criteria, a silent bug is characterized by a semantic deviation that produces an invalid output from a valid input without an explicit failure signal. Localization of Semantic Deviations. A quantum program may invoke multiple library APIs, with the output of one call serving as input to subsequent calls. Within this flow, we treat each library API as a data-transformation unit from its received input to its resulting output. For an execution exhibiting a silent bug, the first library API that transforms a valid input into an invalid output introduces the semantic deviation and is identified as its origin. Earlier calls preserve validity, while later calls may only propagate or expose the resulting incorrect behavior. This data-flow view localizes the semantic deviation to an individual library API. To examine whether reported bugs provide counterexamples to this localization, we screened 3,184 bug reports from Qiskit and PennyLane using Codex with GPT-5.6-Sol (Ultra). We specifically searched for cases in which each API behaves correctly in isolation, but a permitted composition of APIs produces incorrect behavior. The screening surfaced two candidate counterexamples, Qiskit #4369 (Qiskit Developers, 2020) and PennyLane #534 (PennyLane Developers, 2020). In both cases, an output accepted as valid by one component is rejected by a subsequent API, producing an explicit exception instead of a silent incorrect result. Thus, no silent bug counterexample to the API-localization criterion was found among the screened reports. Accordingly, we scope this work to API-local silent bugs, whose semantic deviation can be localized to the first library API that transforms a valid input into an invalid output. Figure 2. Circuit-level manifestation and source-level semantic evidence of Qiskit #13079 (Qiskit Developers, 2024b) in HoareOptimizer. (a) The triggering program and actual and expected circuits, showing an extra X on q0q_0. (b) The implementation caches the original node after replacing it, so subsequent cancellation leaves the replacement X in the circuit. This violates quantum circuit semantics and is inconsistent with the documented node replacement. Inconsistencies with Quantum Semantics and Documentation. Both forms of semantic evidence are illustrated by Qiskit #13079 (Qiskit Developers, 2024b) as shown in Fig. 2. The bug affects the Qiskit API HoareOptimizer, described in the documentation of hoare_opt.py (Qiskit Developers, 2024f) for circuit optimization. As shown in Fig. 2(a), when the control qubit is |1⟩ 1 , the CX gate can be simplified to an X gate on the target. This X gate should cancel with the adjacent X gate because X2=IX^2=I, whereas the implementation leaves an extra X gate in the circuit. The incorrect simplification arises from the internal function _traverse_dag, as shown in Fig. 2(b). That is, after updating the circuit using substitute_node_with_dag, the subsequent code should process the replacement node but instead continues to process the original node. This behavior violates the quantum circuit semantics that the optimization should preserve and provides direct evidence of the bug. This defect is also exposed by the documentation of substitute_node_with_dag in dagcircuit.py (Qiskit Developers, 2024e), as the function replaces a node and returns a mapping to the newly inserted nodes. Continuing to process the original node after replacement is inconsistent with the documented behavior. Both quantum semantics and documentation provide semantic evidence of the same defect. The above data-flow analysis motivates API-local defect analysis, and the issue study provides supporting evidence from reported bugs. The Qiskit case in Fig. 2 further illustrates how such deviations can be identified from source-level semantic evidence without relying on expected relations between execution results, addressing (L1). Besides, the associated semantic conditions can guide the construction of triggering inputs, helping mitigate (L2). 3.3. Implications and Challenges The motivating study in Sec. 3.2 suggests that source-level semantic evidence can help address (L1) and (L2) in existing approaches to silent bug detection in quantum libraries. Turning this insight into a practical testing method requires systematically identifying and validating such evidence, which introduces two key challenges. (C1) Incorporating Quantum Semantics into Source-Level Correctness Reasoning. As discussed in Sec. 3.2, discovering silent bugs requires analyzing source code, interpreting documentation, and reasoning with quantum-domain knowledge. Documentation can encode semantic constraints on API behavior, whose interpretation may itself require such knowledge, as illustrated by the inconsistency between documentation and implementation logic in Fig. 2. Since these constraints often involve mathematical and domain-specific concepts, the first challenge is to integrate relevant quantum semantics into correctness reasoning over library implementation logic. (C2) Distinguishing Internal Defects from Bugs Exposed Through Valid Library API Use. A source-level semantic defect may be unreachable through documented library APIs because higher-level logic prevents the defective code from being executed. We exclude such unreachable defects and consider only those that can arise during valid API use. The second challenge is therefore to determine whether an identified defect is triggerable through a documented library API. 4. QuSema: Semantics-Driven Detection of Silent Bugs in Quantum Libraries This section presents QuSema, a framework for detecting silent bugs in quantum libraries using semantic evidence from implementations. Inspired by prior work on large language models (LLMs) reasoning about program semantics (Wei et al., 2025) and quantum programming (Mikuriya et al., 2025), QuSema leverages the reasoning and coding abilities of LLMs to identify semantic deviations by analyzing implementation logic against quantum semantics and documentation. There are two critical issues in completing such a reasoning process. First, it is unknown how to assign an appropriate analysis scope. More concretely, excessive context may contain irrelevant information that interferes with LLM reasoning (Blinn et al., 2024), whereas insufficient context may omit information required for correct analysis (Sheng et al., 2026). Each code segment forms a complete data-flow unit within a library API, allowing a silent bug to be localized to the first segment that introduces a semantic deviation. Subsequent segments may propagate or expose it, as illustrated in Fig. 2. Second, analyzing the target code segment may require implementation logic defined outside its boundaries. To address both issues in quantum software testing, QuSema adopts a structured analysis around each code segment together with relevant documentation and call relations, which collectively constitute a contextual unit. QuSema analyzes each contextual unit for semantic defects and then determines whether the identified defects can be triggered through library APIs. In this way, QuSema keeps a focused analysis scope while incorporating additional context when needed, which supports more effective LLM reasoning. 4.1. Overview of QuSema QuSema follows a three-stage workflow for discovering and validating silent bugs, as illustrated in Fig. 3. Its key principle is to use LLMs to examine implementation logic against quantum semantics and relevant documentation, identify semantic deviations, and determine whether they can be triggered through valid library API use. The workflow begins with Stage I, Contextual Unit Preparation, which establishes a focused scope for semantic analysis. QuSema uses code segments as the primary analysis units and associates them with documentation that constrains their intended behavior and call relations that provide access to related implementation logic when needed. The resulting contextual units reduce unrelated source context while preserving information required to interpret the behavior of each segment. Next, in Stage I, Semantic Defect Detection, QuSema interprets the relevant quantum semantics or documented behavior as semantic constraints on each code segment. These constraints form the source-level semantic oracle used to identify conditions under which a valid input may produce an invalid output. Each suspected violation is converted into a testable defect hypothesis with predicted erroneous behavior and validated through execution. Hypotheses supported by the observed results are retained as candidate defects. This stage addresses (C1) by incorporating quantum-specific semantic knowledge into source-level correctness reasoning. Finally, in Stage I, Library API Triggering and Bug Validation, QuSema determines whether a verified source-level defect can be reproduced through valid use of a documented library API. It searches for API entries that can reach the defective implementation, constructs user-level inputs that may preserve the triggering condition identified in Stage I, and verifies whether the same semantic deviation is exposed at the API level. The reverse chain in Fig. 3(c) provides additional guidance for this search. Reproduced cases are then classified according to input validity and API documentation. This stage addresses (C2) by distinguishing internal implementation defects from user-triggerable library bugs. Across these stages, QuSema progresses from library source code to focused contextual units, verified semantic defects, and finally user-triggerable bugs. We next detail these stages in Secs. 4.2, 4.3, and 4.4, respectively. Figure 3. Workflow of QuSema for detecting silent bugs in quantum libraries. (a) Contextual Unit Preparation extracts code segments from library source code and combines them with call relations and documentation to form contextual units. (b) Semantic Defect Detection searches each contextual unit for semantic violations, formulates defect hypotheses and executes tests to produce candidate defects. (c) API Triggering and Bug Validation searches for documented APIs that expose the candidate defects, uses the reverse chain as auxiliary guidance, verifies the triggers, and classifies the results as bugs, potential bugs, or not bugs. 4.2. Contextual Unit Preparation Stage I establishes the scope of semantic analysis. An entire source file may contain substantial logic unrelated to the behavior under examination, while an isolated function may omit dependencies needed to interpret that behavior. Following the localization in Sec. 3.2, QuSema analyzes individual code segments and retrieves related information as needed. Specifically, a contextual unit contains the target code segment, documentation that constrains its intended behavior, and call relations that provide access to relevant implementation logic. This design keeps the initial reasoning scope focused while preserving access to dependencies that may affect the semantic behavior of the segment. For example, the Qiskit 2.4.1 Rust file standard_gates_commutations.rs (Qiskit Developers, 2026u) contains 7,778 lines covering gate metadata, commutation tables, and helper logic. Analyzing the complete file introduces substantial unrelated context, whereas analyzing an extracted function alone may omit referenced tables or surrounding logic required to determine whether its commutation behavior is correct. QuSema therefore constructs contextual units through code segment extraction, call-relation analysis, and documentation association. Code Segment Extraction. QuSema extracts individual code segments from the quantum library source code shown on the left side of Fig. 3(a). For Python, QuSema uses source positions from the standard ast module (Python Software Foundation, 2026) to extract module-level functions and class methods, while nested functions remain within their enclosing function. For Rust, regular expressions identify module-level functions and functions or methods in impl blocks, with brace-depth tracking determining their boundaries. Functions exposed through PyO3 are also included (PyO3 Project, 2026). Each segment retains its attached Python decorators or Rust attributes and records its qualified name, signature, source file, and line range. QuSema further partitions the few Rust functions exceeding 1,000 lines while retaining the enclosing function context. Call-Relation Analysis. A code segment may depend on implementation logic defined elsewhere. QuSema records these dependencies for inspection without expanding the initial scope to the entire source file. The Call relations component in Fig. 3(a) records callers and callees (Gharibi et al., 2018), together with class references, variable definitions, and cross-language relations. Source locations are retained for inspecting related code. For Python, call targets are resolved from call expressions and import bindings. For Rust, QuSema uses call sites, enclosing impl types, and qualified names. Referenced constants, class attributes, and tables from the same file are included when available. PyO3 export attributes and module registrations connect Rust implementations to their corresponding Python interfaces (PyO3 Project, 2026). Unresolved calls are retained for later inspection. For partitions of large Rust functions, QuSema also records definitions and updates of local variables outside the partition. Documentation Association. Semantic analysis also requires evidence of the implementation’s intended behavior. QuSema therefore associates each code segment with relevant documentation, as illustrated in Fig. 3(a). Python docstrings are obtained from syntax-tree nodes, while Rust documentation is collected from documentation comments (/// and //!) and the #[doc = ...] attribute (The Rust Project, 2026). For Python class methods, class-level documentation is also included when it specifies relevant behavior. Documentation from the constructor, resolvable base classes, and directly related classes is included when available. For Rust segments, QuSema resolves documentation from the corresponding Python interface through exported names and containing types, using related #[pyclass] types as fallback. Partitions of large Rust functions retain the enclosing function documentation and relevant gate-class documentation. Documentation sources and missing documentation are explicitly recorded. The design in Stage I of QuSema organizes library code into compact contextual units with explicit links to supporting information. This structure limits irrelevant context while preserving access to dependencies that may affect code behavior. The subsequent semantic defect detection stage can then begin from a focused scope and retrieve additional context when needed. 4.3. Semantic Defect Detection After contextual unit preparation, Stage I of QuSema performs Semantic Defect Detection, as illustrated in Fig. 3(b). It examines whether the implementation logic of each code segment satisfies the relevant quantum semantics and documented behavior under valid inputs. These semantic constraints form the source-level semantic oracle used to identify conditions under which the implementation may produce an invalid output. QuSema then turns each suspected violation into a testable defect hypothesis and validates it through execution. This process consists of candidate search, defect hypothesis generation, and hypothesis verification. Candidate Search. As shown on the left of Fig. 3(b), QuSema analyzes each contextual unit against the source-level semantic oracle. The LLM identifies the quantum-semantic and documented constraints relevant to the target code segment and examines whether the implementation can violate these constraints under valid inputs. When additional implementation logic is required, it follows the call relations to inspect referenced definitions and related code segments, and may execute exploratory code to examine suspected inconsistencies. QuSema records plausible semantic violations as candidates. Search ends when the LLM determines that no further candidates can be identified in the contextual unit. Each candidate then proceeds individually through the remaining workflow. Defect Hypothesis Generation. For each retained candidate, QuSema converts the suspected semantic violation into a testable defect hypothesis, as shown on the upper right of Fig. 3(b). The hypothesis specifies the triggering input, the erroneous behavior predicted from the implementation, and the quantum-semantic or documented constraint expected to be violated. QuSema then constructs executable test code that directly exercises the target code segment under the identified condition. The resulting hypothesis provides a concrete prediction for subsequent verification. Hypothesis Verification. As shown on the lower right of Fig. 3(b), QuSema executes the generated test, compares the observed behavior with the erroneous behavior predicted by the defect hypothesis, and checks whether the claimed semantic violation is justified. If the two do not match or the claimed violation is unjustified, the LLM revisits the triggering condition, test code, and predicted behavior, revises the hypothesis when needed, and repeats the verification. A candidate is retained as a semantic defect only when the predicted violation is reproduced through execution. Otherwise, it is discarded. Stage I progresses from semantic constraints on implementation behavior to executable evidence of their violation. This process addresses (C1) by incorporating quantum semantic knowledge into source-level correctness reasoning. 4.4. Library API Triggering and Bug Validation The candidate defects from Stage I may either be exposed through valid use of documented library APIs or remain confined to internal implementation logic. The latter do not constitute silent bugs considered in this work. To distinguish these cases, Stage I of QuSema determines whether a verified source-level defect can be reproduced through a documented library API, thereby addressing (C2), as illustrated in Fig. 3(c). This stage consists of library API trigger search, which identifies an API and valid input that may expose the defect, and bug qualification, which verifies whether the semantic deviation is reproduced at the API level and determines the final classification. Library API Trigger Search. As shown on the left of Fig. 3(c), QuSema searches for documented library APIs that can reach the verified defect and preserve its triggering condition. The LLM examines candidate APIs and constructs valid inputs that may reproduce the erroneous behavior identified in Stage I, using exploratory execution when needed. QuSema supplements this search with the reverse chain shown in the Auxiliary component of Fig. 3(c). Starting from the smallest code segment containing the defect, the reverse chain performs a bounded search over CodeQL-derived caller relations (GitHub, 2026) toward documented library APIs. For Qiskit Rust code, PyO3 bindings connect Rust implementations to the corresponding Python classes or methods. These paths identify possible API entries and guide trigger construction. An API and valid input that may reproduce the defect are retained as a trigger candidate. If no valid trigger is found, the candidate receives the workflow status not bug and is not reported. Bug Qualification. As shown on the right of Fig. 3(c), QuSema determines whether a trigger candidate reproduces the semantic deviation identified in Stage I. For each candidate, QuSema formulates a trigger hypothesis specifying the library API call, input, and expected erroneous behavior, then verifies it using the procedure in Sec. 4.3. A candidate whose predicted behavior cannot be reproduced is classified as not bug. For a reproduced defect, QuSema checks the triggering input against the API documentation. Cases arising from inputs explicitly permitted by the documented API are classified as bug, while cases involving valid inputs whose support is not established by the documentation are retained as potential bug for developer assessment. This stage determines whether an internal defect can be exposed through valid library API use. The final classification distinguishes true bugs from potential bugs according to whether the triggering input is permitted by the API documentation. 5. Experimental Setup We evaluate the effectiveness and utility of QuSema through the following three research questions: RQ1: How does QuSema perform compared with general coding agents and across LLM backends? RQ2: How do individual components of QuSema contribute to its effectiveness? RQ3: Can QuSema discover previously unknown bugs in quantum libraries? Subjects and Benchmark. We evaluate QuSema on Qiskit and PennyLane. For RQ1 and RQ2, we construct a benchmark of 20 maintainer-confirmed historical silent bugs, with 10 from each library, and reproduce each bug on its corresponding buggy version. The benchmark covers 10 functionality types, as summarized in Table 1. In particular, 10 of these bugs, evenly split between Qiskit and PennyLane, lack comparable implementations in the other library and therefore cannot be directly checked by differential testing. Metamorphic testing is also insufficient for these cases. For PennyLane #9361 (PennyLane Developers, 2026g) and Qiskit #12429 (Qiskit Developers, 2024a), equivalent circuit transformations do not guarantee unchanged resource estimates. For the remaining eight bugs, equivalent circuit variants can be constructed, but their execution results do not expose the defects. For RQ1 and RQ2, each benchmark instance centers on one historical bug. Issue reports, known triggering inputs, fixes, and regression tests are withheld from all methods. RQ1 and RQ2 evaluate defect identification and bug validation under controlled inputs, while RQ3 examines repository-scale discovery. For RQ3, we apply QuSema to the full source code of Qiskit 2.4.1 (Qiskit Developers, 2026t) and PennyLane 0.45.0 (PennyLane, 2026). Table 2 reports the size, documented APIs, and extracted code segments of the two library versions. Table 1. Historical silent bug benchmark covering 20 maintainer-confirmed bugs in Qiskit and PennyLane. Comparable functionality indicates whether cross-library comparison is available. Category Functionality type Library Issue Version Comparable functionality Quantum programming language Semantic queries PennyLane #4842 (PennyLane Developers, 2023) 0.33.1 Unavailable Semantic queries Qiskit #14107 (Qiskit Developers, 2025b) 2.2.0 Unavailable Construction PennyLane #6359 (PennyLane Developers, 2024) 0.38.0 Available Construction Qiskit #15465 (Qiskit Developers, 2025a) 2.4.1 Available Specialized quantum algorithms PennyLane #9521 (PennyLane Developers, 2026w) 0.45.0 Available Specialized quantum algorithms Qiskit #12093 (Qiskit Developers, 2024d) 1.0.2 Available Compilation Compilation workflow orchestration PennyLane #8048 (PennyLane Developers, 2025e) 0.42.3 Unavailable Compilation workflow orchestration Qiskit #14329 (Qiskit Developers, 2025c) 2.1.1 Unavailable Structural placement decisions PennyLane #9009 (PennyLane Developers, 2026l) 0.42.3 Unavailable Structural placement decisions Qiskit #12157 (Qiskit Developers, 2024c) 1.3.2 Unavailable Resource estimation PennyLane #9361 (PennyLane Developers, 2026g) 0.45.0 Unavailable Resource estimation Qiskit #12429 (Qiskit Developers, 2024a) 1.0.2 Unavailable Representation conversion and interoperability PennyLane #6978 (PennyLane Developers, 2025c) 0.40.0 Unavailable Representation conversion and interoperability Qiskit #10570 (Qiskit Developers, 2023a) 1.0.2 Unavailable Transformation and synthesis PennyLane #8746 (PennyLane Developers, 2025d) 0.45.0 Available Transformation and synthesis Qiskit #11974 (Qiskit Developers, 2024i) 1.0.2 Available Execution environment Execution and device modeling PennyLane #8366 (PennyLane Developers, 2025b) 0.42.3 Available Execution and device modeling Qiskit #13047 (Qiskit Developers, 2024g) 1.0.2 Available Measurement and result processing PennyLane #7344 (PennyLane Developers, 2025a) 0.38.0 Available Measurement and result processing Qiskit #11393 (Qiskit Developers, 2023b) 2.4.1 Available Table 2. Library statistics for RQ3. APIs count entries listed in the official documentation. Library LoC excludes comments and blank lines, while segment lengths include them and exclude attached context. Library Version LoC APIs Code segments Min. lines Max. lines Qiskit 2.4.1 169,750 899 8,949 1 908 PennyLane 0.45.0 104,172 1,270 7,786 2 446 Configurations. For RQ1, we compare QuSema with Claude Code (Anthropic, 2026a) using Fable 5 (Max) (Anthropic, 2026b) and Codex (OpenAI, 2026a) using GPT-5.6-Sol (Max) (OpenAI, 2026b). Two QuSema configurations are instantiated with DeepSeek-V4.1-Flash (Max) (DeepSeek, 2026) and Opus 5 (Extra) (Anthropic, 2026c), respectively. Both QuSema configurations use the same workflow, prompts, tools, and execution constraints, while Claude Code and Codex retain their native workflows and tools. Both baselines are instructed to search until they identify no further silent bugs in the target code segment, then report all findings in one final response. All configurations aim to identify silent bugs triggerable through valid library API use. Each QuSema model request permits up to 128,000 generated tokens, with no task-level limit on turns or cumulative token usage. For RQ2, we use QuSema with DeepSeek-V4.1-Flash (Max) in two controlled comparisons. First, we evaluate candidate search under three configurations: a base QuSema configuration that analyzes complete source files without the source-level semantic oracle, a configuration with Contextual Unit Preparation, and one that additionally uses the oracle. This comparison measures their contributions to defect identification. Second, starting from the defects identified by the third configuration, we compare the subsequent workflow with and without hypothesis verification in Stages I and I. This comparison assesses the role of verification in correcting hypotheses and filtering candidates. The benchmark, environment, execution budget, and other settings remain fixed within each comparison. For RQ3, we use the complete QuSema configuration with DeepSeek-V4.1-Flash (Max). Procedure and Metrics. For RQ1 and RQ2, we evaluate each configuration in three independent runs on the historical bug benchmark. For each bug, we define the root-cause code segment as the first segment along the call chain that produces an invalid output from a valid input. In RQ1, all methods receive this segment, and Claude Code and Codex may inspect other library code as needed. For QuSema, this corresponds to analyzing a single contextual unit. In RQ2, the base QuSema configuration receives the containing source file, while the remaining configurations receive the root-cause segment. Each bug is counted at most once per run, and we report per-run counts and three-run means. A defect is identified when a candidate matches the ground-truth implementation defect and correctly explains how a valid input produces an output violating the relevant quantum semantics or documented behavior. A bug is relocated when the identified defect is reproduced through valid library API use, with executable evidence and a correct explanation of the invalid output. We check the reported root cause, input validity, and semantic explanation using issue reports, documentation, and executable evidence. RQ1 reports bug relocation counts and total cost across three runs. The two RQ2 comparisons report defect identification and bug relocation counts, respectively. For RQ3, QuSema analyzes code segments from the target library versions until 40 previously unknown bugs are identified. We report each unique finding to library maintainers and record its status as fixed, confirmed, pending, or rejected. 6. Evaluation Results This section answers the three research questions in Sec. 5. We compare QuSema with general coding agents on the historical benchmark, examine the contributions of contextual units and the source-level semantic oracle to defect identification, and assess hypothesis verification in bug qualification. We then report previously unknown bugs found in Qiskit and PennyLane. 6.1. RQ1: Historical Bug Relocation Table 3. Bug relocation and estimated cost on the historical benchmark. Runs 1–3 report manually reviewed counts, Mean is their average, and Cost covers all three runs. Configuration Run 1 Run 2 Run 3 Mean Costs (USD) QuSema + Opus 5 16 15 17 16.00 1,603.44 QuSema + DeepSeek 15 16 16 15.67 162.27 Claude Code + Fable 5 15 14 15 14.67 425.04 Codex + GPT-5.6-Sol 15 12 13 13.33 117.29 Table 4. Candidate outcomes for all findings produced during historical bug relocation after deduplication. Configuration Run Candidates Verified defects API triggers Final reports QuSema + Opus 5 1 65 64 64 64 2 56 55 54 54 3 66 66 66 66 QuSema + DeepSeek 1 64 61 60 60 2 73 72 72 72 3 65 62 62 62 We compare two QuSema configurations with Claude Code and Codex on the historical bug benchmark. As shown in Table 3, QuSema with Opus 5 achieves the highest mean bug relocation count of 16.00, followed by QuSema with DeepSeek-V4.1-Flash at 15.67. Claude Code with Fable 5 and Codex with GPT-5.6-Sol achieve mean counts of 14.67 and 13.33, respectively. Thus, both QuSema configurations relocate more historical bugs than the evaluated coding agents. In addition, QuSema with DeepSeek retains nearly all of the relocation performance of the Opus configuration while requiring approximately one-tenth of the cost. It achieves a higher mean relocation count than Claude Code at a lower cost, and achieves a higher mean bug relocation count than Codex with only a modest increase in cost. These results indicate that QuSema can achieve a better effectiveness–cost trade-off than the evaluated coding agents by using a less expensive LLM backend. Beyond relocating the historical target bugs, QuSema also identifies additional defect candidates. As shown in Table 4, each run produces 56–73 candidates, of which 54–72 remain after validation and proceed to final reporting. Defect hypothesis verification and library API trigger search exclude 0–4 candidates per run because the predicted semantic violation cannot be reproduced or the triggering condition cannot arise through valid API use. Among the reports not corresponding to the 20 targets, 15 correspond to independently reported issues. Manual review finds the remaining reports consistent with our silent bug criteria, although they have not yet been submitted for maintainer validation. These results show that QuSema can identify findings beyond the benchmark targets while filtering unsupported or non-triggerable candidates through Stages I and I. Answer to RQ1. QuSema achieves mean relocation counts of 16.00 with Opus 5 and 15.67 with DeepSeek-V4.1-Flash, compared with 14.67 for Claude Code and 13.33 for Codex. Despite using a less expensive LLM backend, DeepSeek-based QuSema exceeds both coding agents and costs $162.27 across three runs, about one-tenth of Opus and less than Claude Code. 6.2. RQ2: Component Contributions We conduct two controlled comparisons of QuSema components, as shown in Fig. 4. The first evaluates Contextual Unit Preparation and the Source-level Semantic Oracle for defect identification, while the second evaluates hypothesis verification for bug relocation. In the first comparison, the base configuration analyzing complete source files identifies 12–15 defects across three runs, averaging 13.67. Contextual Unit Preparation raises the mean to 15.00, with 15 defects identified in each run, and adding the Source-level Semantic Oracle raises it to 15.67. The larger gain from Contextual Unit Preparation suggests that reducing unrelated context is particularly important for defect identification and improves consistency across runs. The oracle’s additional gain indicates that semantic evidence helps determine correctness when observed behavior alone is insufficient. The two components address complementary sources of failure. Contextual Unit Preparation focuses the analysis on relevant implementation context, while the Source-level Semantic Oracle provides evidence for distinguishing semantic defects from permissible implementation choices. In the second comparison, the mean bug relocation count increases from 15.33 without hypothesis verification to 15.67 with full QuSema. The increase in mean bug relocation count is modest, but the verification record shows its role in correcting semantic assumptions. For example, in the benchmark case Qiskit #11974 (Qiskit Developers, 2024i), QuSema identifies the unitary-synthesis defect but incorrectly assumes that [’rz’,’x’,’cx’] forms a universal gate set. Hypothesis verification corrects this assumption before evaluating the target gate-set violation, avoiding an incorrect bug qualification. Answer to RQ2. The mean defect identification count increases from 13.67 to 15.00 with Contextual Unit Preparation and to 15.67 with the Source-level Semantic Oracle. Hypothesis verification further increases mean bug relocation from 15.33 to 15.67 and corrects invalid assumptions during bug qualification, as illustrated by Qiskit #11974 (Qiskit Developers, 2024i). Two bar charts on the same row. Each group contains four bars for Runs 1--3 and their mean. The left chart shows identified historical defects: Base, 12, 14, and 15, with mean 13.67; adding Contextual Unit Preparation, 15, 15, and 15, with mean 15.00; further adding the Source-level Semantic Oracle, 15, 16, and 16, with mean 15.67. The right chart shows relocated historical bugs: without hypothesis verification, 14, 16, and 16, with mean 15.33; full QuSema, 15, 16, and 16, with mean 15.67. Figure 4. Component contributions with DeepSeek-V4.1-Flash (Max). (a) Candidates matching historical defects as Contextual Unit Preparation and the Source-level Semantic Oracle are added. (b) Bugs satisfying the relocation criterion with and without hypothesis verification in Stages I and I. Each group reports the counts from Runs 1–3 and their mean across the three runs.Two bar charts on the same row. Each group contains four bars for Runs 1–3 and their mean. The left chart shows identified historical defects: Base, 12, 14, and 15, with mean 13.67; adding Contextual Unit Preparation, 15, 15, and 15, with mean 15.00; further adding the Source-level Semantic Oracle, 15, 16, and 16, with mean 15.67. The right chart shows relocated historical bugs: without hypothesis verification, 14, 16, and 16, with mean 15.33; full QuSema, 15, 16, and 16, with mean 15.67. 6.3. RQ3: Previously Unknown Bugs QuSema with DeepSeek-V4.1-Flash (Max) is used to analyze the source code of Qiskit 2.4.1 and PennyLane 0.45.0 for previously unknown bugs. It analyzes 68,687 lines and 2,753 code segments in Qiskit, and 72,262 lines and 2,269 code segments in PennyLane. QuSema reports 40 previously unknown bugs, all confirmed by the maintainers. Among them, 30 are silent bugs that return invalid outputs without explicit failure signals, while the other 10 cause crashes or exceptions on valid inputs. Tables 6 and 6 summarize these findings by API location and bug type, where S denotes a silent bug and C a crash or exception. The confirmed bugs span circuit transformation, symbolic computation, commutativity, measurement, resource estimation, serialization, and execution. Among the 30 silent bugs, 5 affect PennyLane functionalities without directly comparable APIs in the evaluated Qiskit SDK, preventing direct cross-library comparison. These cases also lack applicable circuit-based metamorphic relations. Specifically, Bosonic-operator multiplication, measurement-condition comparison, and download concurrency are not exercised by equivalent-circuit variants, while lost wire-count information and parameter trainability can remain incorrect even when circuit execution is unchanged. Two Python reproducers. In panel (a), BoseWord objects constructed from identical dictionary entries in different insertion orders compare equal, but multiplication returns different products. In panel (b), OptimizeAnnotated combines nested controls incorrectly and changes the circuit unitary. Figure 5. Silent bugs discovered by QuSema: (a) incorrect bosonic-operator multiplication in PennyLane #9650 (PennyLane Developers, 2026b) and (b) incorrect control-state composition in Qiskit #16410 (Qiskit Developers, 2026n).Two Python reproducers. In panel (a), BoseWord objects constructed from identical dictionary entries in different insertion orders compare equal, but multiplication returns different products. In panel (b), OptimizeAnnotated combines nested controls incorrectly and changes the circuit unitary. Figure 5 shows two representative silent bugs. In Fig. 5(a), PennyLane’s BoseWord multiplication (#9650 (PennyLane Developers, 2026b)) produces incorrect results for equivalent operands constructed from identical dictionary entries in different insertion orders. The implementation pairs sorted dictionary keys with values retained in insertion order, which can exchange creation and annihilation operators during multiplication. This symbolic-operator functionality has no direct counterpart in the evaluated Qiskit SDK and no applicable circuit-based metamorphic relation. Figure 5(b) shows Qiskit #16410 (Qiskit Developers, 2026n) in the OptimizeAnnotated pass. The implementation combines nested control modifiers in the wrong order. For an inner open control and an outer closed control, it produces control state 2 instead of 1, changing the control condition and thereby violating circuit semantics without raising an error. The maintainer response (Qiskit Developers, 2026n) further highlighted that QuSema pinpointed the underlying root cause: “I have pushed a fix in #16428 (Qiskit Developers, 2026g), but here is a general question for you: would you be interested in submitting PRs for some of the issues that you are discovering (especially that you already do the work of pinpointing the exact root cause for each problem)?” The response indicates that the root-cause information reported by QuSema can provide developers with actionable guidance for subsequent bug diagnosis and repair. Answer to RQ3. QuSema finds 40 previously unknown bugs confirmed by the maintainers, including 5 silent bugs that existing differential and metamorphic testing methods cannot detect. Table 5. Previously unknown bugs in Qiskit. # Issue API Location Type Status 1 #16271 (Qiskit Developers, 2026a) transpiler.passes S Confirmed 2 #16205 (Qiskit Developers, 2026f) transpiler.passes S Confirmed 3 #16185 (Qiskit Developers, 2026w) transpiler.passes S Confirmed 4 #16166 (Qiskit Developers, 2026h) converters S Confirmed 5 #16377 (Qiskit Developers, 2026d) transpiler.passes S Confirmed 6 #16259 (Qiskit Developers, 2026o) circuit S Confirmed 7 #16260 (Qiskit Developers, 2026r) circuit S Confirmed 8 #16262 (Qiskit Developers, 2026q) circuit S Confirmed 9 #16263 (Qiskit Developers, 2026p) circuit S Confirmed 10 #16161 (Qiskit Developers, 2026e) transpiler.passes S Confirmed 11 #16164 (Qiskit Developers, 2026c) circuit S Confirmed 12 #16410 (Qiskit Developers, 2026n) transpiler.passes S Confirmed 13 #16411 (Qiskit Developers, 2026m) transpiler.passes S Confirmed 14 #16184 (Qiskit Developers, 2026j) circuit.library C Confirmed 15 #16173 (Qiskit Developers, 2026b) primitives.containers S Confirmed 16 #16168 (Qiskit Developers, 2026l) circuit.library S Confirmed 17 #16190 (Qiskit Developers, 2026k) result S Confirmed 18 #16412 (Qiskit Developers, 2026v) circuit C Confirmed 19 #16413 (Qiskit Developers, 2026i) circuit.library S Confirmed 20 #15841 (Qiskit Developers, 2026s) transpiler.passes C Confirmed Table 6. Previously unknown bugs in PennyLane. # Issue API Location Type Status 1 #9612 (PennyLane Developers, 2026f) devices C Confirmed 2 #9613 (PennyLane Developers, 2026k) devices.preprocess C Confirmed 3 #9617 (PennyLane Developers, 2026i) estimator C Confirmed 4 #9633 (PennyLane Developers, 2026a) ops.op_math C Confirmed 5 #9652 (PennyLane Developers, 2026o) debugging C Confirmed 6 #9610 (PennyLane Developers, 2026s) devices S Confirmed 7 #9631 (PennyLane Developers, 2026v) ops.op_math S Confirmed 8 #9632 (PennyLane Developers, 2026p) ops.functions S Confirmed 9 #9650 (PennyLane Developers, 2026b) bose S Confirmed 10 #9669 (PennyLane Developers, 2026d) devices S Confirmed 11 #9622 (PennyLane Developers, 2026q) ops.functions S Confirmed 12 #9623 (PennyLane Developers, 2026r) ops.functions S Confirmed 13 #9653 (PennyLane Developers, 2026u) devices S Confirmed 14 #9670 (PennyLane Developers, 2026e) measurements S Confirmed 15 #9616 (PennyLane Developers, 2026h) estimator S Confirmed 16 #9618 (PennyLane Developers, 2026j) estimator C Confirmed 17 #9609 (PennyLane Developers, 2026c) data S Confirmed 18 #9614 (PennyLane Developers, 2026t) debugging S Confirmed 19 #9601 (PennyLane Developers, 2026m) concurrency.executors C Confirmed 20 #9606 (PennyLane Developers, 2026n) data S Confirmed 7. Discussion and Threats to Validity Discussion. QuSema localizes semantic deviations to responsible code segments and reproduces them through documented library APIs. The resulting reports provide root-cause information and user-level triggers that support diagnosis and repair, as also reflected in the maintainer feedback in RQ3. Differential and metamorphic testing rely on comparable implementations or predictable execution relations, whereas QuSema examines implementation logic against quantum semantics and documentation. This allows it to detect confirmed silent bugs in RQ3 for which such relations are unavailable or uninformative. Construct Validity. QuSema relies on LLM knowledge of quantum computing and software to identify defects. This knowledge may be incomplete, and hallucinations (Kalai et al., 2026) may cause incorrect semantic judgments. Hypothesis verification tests these judgments against execution evidence but cannot guarantee reliable detection. QuSema also uses documentation as semantic evidence of intended behavior without independently establishing whether the documentation itself is correct. Documentation errors (Xu et al., 2025) may therefore affect bug assessment and require maintainer review. Internal Validity. LLM outputs vary across runs (Ouyang et al., 2025) and model versions. We repeat each configuration three times under the same experimental settings. Candidate reports are reviewed manually, so assessment may involve subjective judgment. The checks described in Sec. 5 help limit this subjectivity. RQ1 compares QuSema with Claude Code and Codex as complete configurations, so performance differences cannot be attributed to agent design alone. Public benchmark issues and fixes may have appeared in LLM training data despite being withheld from the evaluated methods. RQ3 reduces this threat by evaluating previously unknown bugs, although prior exposure to the underlying library source code cannot be excluded. External Validity. The historical benchmark contains 20 bugs from Qiskit and PennyLane, and practical discovery uses Qiskit 2.4.1 and PennyLane 0.45.0. The results may not generalize to closed-source or poorly documented libraries, or to different implementation languages and binding systems. Applying QuSema may require changes to code segmentation, call-relation analysis, and documentation association. QuSema targets API-local silent bugs and does not directly address bugs arising solely from interactions among individually correct APIs. 8. Related Work Quantum software correctness and testing. Research on quantum-software correctness spans language design, formal verification, static analysis, and testing. At the program level, Silq (Bichsel et al., 2020) supports safe automatic uncomputation through its language and type system, while VOQC (Hietala et al., 2021) verifies that circuit optimizations preserve quantum semantics. LintQ (Paltenghi and Pradel, 2024b) uses quantum-specific abstractions to statically detect problems in Qiskit programs. Beyond program-level correctness, quantum software testing addresses library reliability. Differential and metamorphic testing detect bugs through cross-library comparisons or semantics-preserving transformations, while KQFuzz (Xia et al., 2026) uses codebase knowledge to guide LLM-based test generation. QuSema instead uses quantum semantics and documentation as source-level correctness evidence for auditing library logic, without requiring predefined relations between executions. LLM-based software analysis and semantic auditing. LLMs support repository-level issue resolution, test and oracle generation, and source auditing. For general software engineering tasks, SWE-agent (Yang et al., 2024b) and RepairAgent (Bouzenia et al., 2025) use repository tools to resolve software issues. CoverUp (Altmayer Pizzorno and Berger, 2025) uses coverage and execution feedback to generate tests, while Doc2OracLL (Hossain et al., 2025) uses documentation for test-oracle generation. For source-level auditing, RepoAudit (Guo et al., 2025) validates data-flow and path conditions during repository exploration, whereas RFCAudit (Zheng et al., 2025) checks implementations against RFC specifications and retrieves related source code as needed. QuSema brings source-level auditing to quantum libraries by combining documentation with quantum semantics and validating whether identified defects can be exposed through documented library APIs. 9. Conclusion This paper presents QuSema, an agentic approach for detecting silent bugs in quantum libraries using source-level semantic evidence. QuSema analyzes implementation logic against quantum semantics and documentation to identify candidate defects. Library API triggering establishes whether these defects produce invalid outputs under valid library use. This approach does not depend on cross-library counterparts or predefined metamorphic relations. Applied to Qiskit and PennyLane, QuSema discovers 40 previously unknown bugs. References Abbas et al. (2024) A. Abbas, A. Ambainis, B. Augustino, A. Bärtschi, H. Buhrman, C. Coffrin, G. Cortiana, V. Dunjko, D. J. Egger, B. G. Elmegreen, et al. Challenges and opportunities in quantum optimization. Nature Reviews Physics 6 (12), p. 718–735. Cited by: §1. Altmayer Pizzorno and Berger (2025) J. Altmayer Pizzorno and E. D. Berger Coverup: effective high coverage test generation for python. Proceedings of the ACM on Software Engineering 2 (FSE), p. 2897–2919. Cited by: §2.2, §2.3, §8. Andrews et al. (2026) E. Andrews, A. Jayasena, and P. Mishra A survey of functional testing and validation of quantum circuits. IEEE Design & Test. Cited by: §1, §2.3. Anthropic (2026a) Anthropic Claude code overview. Note: Product documentation External Links: Link Cited by: §5. Anthropic (2026b) Anthropic Introducing claude fable 5 and claude mythos 5. Note: Model documentation External Links: Link Cited by: §5. Anthropic (2026c) Anthropic Introducing Claude Opus 5. Note: Model announcement External Links: Link Cited by: §5. Bergholm et al. (2018) V. Bergholm, J. Izaac, M. Schuld, C. Gogolin, S. Ahmed, V. Ajith, M. S. Alam, G. Alonso-Linaje, B. AkashNarayanan, A. Asadi, et al. Pennylane: automatic differentiation of hybrid quantum-classical computations. arXiv preprint arXiv:1811.04968. Cited by: §1. Bichsel et al. (2020) B. Bichsel, M. Baader, T. Gehr, and M. Vechev Silq: a high-level quantum language with safe uncomputation and intuitive semantics. In Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation, p. 286–300. Cited by: §8. Blackwell et al. (2024) D. Blackwell, J. Petke, Y. Cao, and A. Bensoussan Fuzzing-based differential testing for quantum simulators. In International Symposium on Search Based Software Engineering, p. 63–69. Cited by: §1, §2.3. Blinn et al. (2024) A. Blinn, X. Li, J. H. Kim, and C. Omar Statically contextualizing large language models with typed holes. Proceedings of the ACM on Programming Languages 8 (OOPSLA2), p. 468–498. Cited by: §4. Bouzenia et al. (2025) I. Bouzenia, P. Devanbu, and M. Pradel Repairagent: an autonomous, llm-based agent for program repair. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), p. 2188–2200. Cited by: §8. Cerezo et al. (2022) M. Cerezo, G. Verdon, H. Huang, L. Cincio, and P. J. Coles Challenges and opportunities in quantum machine learning. Nature computational science 2 (9), p. 567–576. Cited by: §1. Dalzell et al. (2025) A. M. Dalzell, S. McArdle, M. Berta, P. Bienias, C. Chen, A. Gilyén, C. T. Hann, M. J. Kastoryano, E. T. Khabiboulline, and A. Kubica Quantum algorithms: a survey of applications and end-to-end complexities. Cambridge University Press, Cambridge, UK. External Links: Document Cited by: §1. DeepSeek (2026) DeepSeek DeepSeek-v4.1-flash release. Note: API documentation External Links: Link Cited by: §5. Deng et al. (2023) Y. Deng, C. S. Xia, H. Peng, C. Yang, and L. Zhang Large language models are zero-shot fuzzers: fuzzing deep-learning libraries via large language models. In Proceedings of the 32nd ACM SIGSOFT international symposium on software testing and analysis, p. 423–435. Cited by: §2.3. Deng et al. (2024) Y. Deng, C. S. Xia, C. Yang, S. D. Zhang, S. Yang, and L. Zhang Large language models are edge-case generators: crafting unusual programs for fuzzing deep learning libraries. In Proceedings of the 46th IEEE/ACM international conference on software engineering, p. 1–13. Cited by: §2.3. Dwivedi et al. (2024) K. Dwivedi, M. Haghparast, and T. Mikkonen Quantum software engineering and quantum software development lifecycle: a survey. Cluster Computing 27 (6), p. 7127–7145. Cited by: §1. Fortunato et al. (2024) D. Fortunato, L. Jiménez-Navajas, J. Campos, and R. Abreu Verification and validation of quantum software. In Quantum Software: Aspects of Theory and System Design, p. 93–123. Cited by: §1, §2.3. Gao et al. (2026) X. Gao, Z. Liu, J. Cui, H. Li, H. Zhang, K. Wei, and K. Zhao A comprehensive survey on database management system fuzzing: techniques, taxonomy and evaluation. ACM Computing Surveys 58 (10), p. 1–36. Cited by: §1. Gharibi et al. (2018) G. Gharibi, R. Tripathi, and Y. Lee Code2graph: automatic generation of static call graphs for python source code. In Proceedings of the 33rd ACM/IEEE international conference on automated software engineering, p. 880–883. Cited by: §4.2. GitHub (2026) GitHub CodeQL. External Links: Link Cited by: §4.4. Guo et al. (2025) J. Guo, C. Wang, X. Xu, et al. RepoAudit: an autonomous LLM-agent for repository-level code auditing. In Proceedings of the 42nd International Conference on Machine Learning, Proceedings of Machine Learning Research, Vol. 267, p. 21083–21100. External Links: Link Cited by: §8. Hietala et al. (2021) K. Hietala, R. Rand, S. Hung, X. Wu, and M. Hicks A verified optimizer for quantum circuits. Proceedings of the ACM on Programming Languages 5 (POPL), p. 1–29. Cited by: §8. Hossain et al. (2025) S. B. Hossain, R. Taylor, and M. Dwyer Doc2oracll: investigating the impact of documentation on llm-based test oracle generation. Proceedings of the ACM on Software Engineering 2 (FSE), p. 1870–1891. Cited by: §8. Hu et al. (2024) T. Hu, G. Ye, Z. Tang, et al. Upbeat: test input checks of q# quantum libraries. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, p. 186–198. Cited by: §1. Javadi-Abhari et al. (2024) A. Javadi-Abhari, M. Treinish, K. Krsulich, C. J. Wood, J. Lishman, J. Gacon, S. Martiel, P. D. Nation, L. S. Bishop, A. W. Cross, et al. Quantum computing with qiskit. arXiv preprint arXiv:2405.08810. Cited by: §1. Jiang et al. (2024) Y. Jiang, J. Liang, F. Ma, Y. Chen, C. Zhou, Y. Shen, Z. Wu, J. Fu, M. Wang, S. Li, et al. When fuzzing meets llms: challenges and opportunities. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, p. 492–496. Cited by: §2.3. Kalai et al. (2026) A. T. Kalai, O. Nachum, S. S. Vempala, and E. Zhang Evaluating large language models for accuracy incentivizes hallucinations. Nature, p. 1–3. Cited by: §7. Kitt and Cohen (2024) L. J. Kitt and M. B. Cohen Morphq++: a reproducibility study of metamorphic testing on quantum compilers. In Proceedings of the 39th IEEE/ACM international conference on automated software engineering workshops, p. 8–14. Cited by: §1, §2.3. Klimis et al. (2025) V. Klimis, A. Bensoussan, E. Chachkarova, K. Even-Mendoza, S. Fortz, and C. Lenihan Shaking up quantum simulators with fuzzing and rigour. Proceedings of the ACM on Programming Languages 9 (OOPSLA2), p. 1400–1428. Cited by: §1, §2.3. Leite Ramalho et al. (2025) N. C. Leite Ramalho, H. Amario de Souza, and M. Lordello Chaim Testing and debugging quantum programs: the road to 2030. ACM Transactions on Software Engineering and Methodology 34 (5), p. 1–46. Cited by: §1. Li et al. (2026) Y. Li, M. Shao, J. Zhao, and Q. Wang A methodological analysis of empirical studies in quantum software testing. ACM Transactions on Software Engineering and Methodology. Cited by: §1. Luo et al. (2026) J. Luo, S. Xia, F. Zhang, and J. Zhao QEMI: a quantum software stacks testing framework via equivalence modulo inputs. In International Conference on Fundamental Approaches to Software Engineering, p. 149–169. Cited by: §1, §2.3. McArdle et al. (2020) S. McArdle, S. Endo, A. Aspuru-Guzik, S. C. Benjamin, and X. Yuan Quantum computational chemistry. Reviews of Modern Physics 92 (1), p. 015003. Cited by: §1. Mikuriya et al. (2025) T. Mikuriya, T. Ishigaki, M. Kawarada, et al. Qcoder benchmark: bridging language generation and quantum hardware through simulator-based feedback. In Proceedings of the 18th International Natural Language Generation Conference, p. 743–752. Cited by: §1, §4. Nielsen and Chuang (2001) M. A. Nielsen and I. L. Chuang Quantum computation and quantum information. Vol. 2, Cambridge university press Cambridge. Cited by: §1, §2.1. OpenAI (2026a) OpenAI Codex: a lightweight coding agent that runs in your terminal. Note: GitHub repository External Links: Link Cited by: §5. OpenAI (2026b) OpenAI GPT-5.6 Sol model documentation. Note: Model documentation External Links: Link Cited by: §5. Ouyang et al. (2025) S. Ouyang, J. M. Zhang, M. Harman, and M. Wang An empirical study of the non-determinism of chatgpt in code generation. ACM Transactions on Software Engineering and Methodology 34 (2), p. 1–28. Cited by: §7. Paltenghi and Pradel (2022) M. Paltenghi and M. Pradel Bugs in quantum computing platforms: an empirical study. Proceedings of the ACM on Programming Languages 6 (OOPSLA1), p. 1–27. Cited by: §1, §2.2, §2.3. Paltenghi and Pradel (2023) M. Paltenghi and M. Pradel MorphQ: metamorphic testing of the qiskit quantum computing platform. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), p. 2413–2424. Cited by: §1, §2.3. Paltenghi and Pradel (2024a) M. Paltenghi and M. Pradel A survey on testing and analysis of quantum software. arXiv preprint arXiv:2410.00650. Cited by: §1. Paltenghi and Pradel (2024b) M. Paltenghi and M. Pradel Analyzing quantum programs with lintq: a static analysis framework for qiskit. Proceedings of the ACM on Software Engineering 1 (FSE), p. 2144–2166. Cited by: §8. Paltenghi and Pradel (2025) M. Paltenghi and M. Pradel Qite: assembly-level, cross-platform testing of quantum computing platforms. arXiv preprint arXiv:2503.17322. Cited by: §1, §2.3. PennyLane Developers (2020) PennyLane Developers Normalization tolerance checks not consistent between core and Qiskit plugin (np.isclose vs math.isclose). Note: GitHub issue #534, PennyLaneAI/pennylane External Links: Link Cited by: §3.2. PennyLane Developers (2023) PennyLane Developers Equal does not work with symmetry of control wires. Note: GitHub issue #4842, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2024) PennyLane Developers qml.PhaseAdder adds "None" work_wire when this is not specified. Note: GitHub issue #6359, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2025a) PennyLane Developers CountsMP.process_counts returns incorrect results with an observable. Note: GitHub issue #7344, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2025b) PennyLane Developers MCMs postselecting with "fill-shots" breaks correlation between measurements.. Note: GitHub issue #8366, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2025c) PennyLane Developers poly_to_angles only works with list and may modify input. Note: GitHub issue #6978, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2025d) PennyLane Developers simplify unexpectedly removes all wires with the Identity observable. Note: GitHub issue #8746, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2025e) PennyLane Developers Transforms are applied repeatedly with qml.specs. Note: GitHub issue #8048, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2026a) PennyLane Developers Batched-coefficient qml.s_prod crashes in label(decimals=…) and qml.draw. Note: GitHub issue #9633, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026b) PennyLane Developers BoseWord.__mul__ returns the wrong operator when a factor was built from a non-sorted dict. Note: GitHub issue #9650, PennyLaneAI/pennylane External Links: Link Cited by: Figure 5, §6.3, Table 6. PennyLane Developers (2026c) PennyLane Developers Dataset serialization silently strips requires_grad from PennyLane tensor parameters. Note: GitHub issue #9609, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026d) PennyLane Developers default.clifford returns an invalid density matrix for states with complex amplitudes. Note: GitHub issue #9669, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026e) PennyLane Developers default.clifford(tableau=False) returns a probability vector for qml.expval(qml.Projector(…)). Note: GitHub issue #9670, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026f) PennyLane Developers default.mixed crashes with TypeError when readout_prob is set. Note: GitHub issue #9612, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026g) PennyLane Developers Estimating resources for a symbolic operator does not use updated decompositions from config. Note: GitHub issue #9361, PennyLaneAI/pennylane External Links: Link Cited by: Table 1, §5. PennyLane Developers (2026h) PennyLane Developers estimator Identity loses multi-wire arity in resource_rep_from_op. Note: GitHub issue #9616, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026i) PennyLane Developers FirstQuantization accepts eta=1 then crashes with internal NaN conversion. Note: GitHub issue #9617, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026j) PennyLane Developers GQSPTimeEvolution default poly_approx_precision crashes during resource estimation. Note: GitHub issue #9618, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026k) PennyLane Developers measurements_from_counts crashes on broadcasted partitioned-shot tapes. Note: GitHub issue #9613, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026l) PennyLane Developers MultiControlledX does not handle work_wire_type properly.. Note: GitHub issue #9009, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane Developers (2026m) PennyLane Developers PyNativeExec.map fails to unpack iterables for single-argument functions, causing TypeError in concurrency executors. Note: GitHub issue #9601, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026n) PennyLane Developers qml.data.load ignores num_threads and downloads datasets serially. Note: GitHub issue #9606, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026o) PennyLane Developers qml.debug_probs(op=<MeasurementValue>) crashes on a documented input via an if op: truthiness check. Note: GitHub issue #9652, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026p) PennyLane Developers qml.eigvals returns nan for a legal fractional power operator. Note: GitHub issue #9632, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026q) PennyLane Developers qml.equal returns True for opposite MeasurementValue predicates (e.g. m0==0 vs m0==1). Note: GitHub issue #9622, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026r) PennyLane Developers qml.is_commuting returns False for commuting CZ and SWAP gates. Note: GitHub issue #9623, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026s) PennyLane Developers qml.mutual_info returns incorrect results on default.clifford (missing S(AB) in formula). Note: GitHub issue #9610, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026t) PennyLane Developers qml.snapshots on default.mixed drops shot-vector partitions from snapshot payloads. Note: GitHub issue #9614, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026u) PennyLane Developers QubitDevice/QutritDevice probability(wires=0) silently returns the full distribution instead of the marginal. Note: GitHub issue #9653, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026v) PennyLane Developers two_qubit_decomposition can return a non-equivalent local circuit for a slightly entangling two-qubit unitary. Note: GitHub issue #9631, PennyLaneAI/pennylane External Links: Link Cited by: Table 6. PennyLane Developers (2026w) PennyLane Developers Wrong index being used for getting number of modes in qchem.vibrational module.. Note: GitHub issue #9521, PennyLaneAI/pennylane External Links: Link Cited by: Table 1. PennyLane (2026) PennyLane PennyLane Documentation. Note: Documentation source for version 0.45.0 External Links: Link Cited by: §1, §5. Pham et al. (2026) A. B. Pham, H. T. Nguyen, and M. Usman QBugLM: an agentic benchmarking framework for llm-based quantum software debugging. arXiv preprint arXiv:2606.07314. Cited by: §2.3. PyO3 Project (2026) PyO3 Project PyO3: Rust Bindings for Python. External Links: Link Cited by: §4.2, §4.2. Python Software Foundation (2026) Python Software Foundation ast—abstract syntax trees. Note: Python 3 documentation External Links: Link Cited by: §4.2. Qiskit Developers (2020) Qiskit Developers Isometry fails to decompose 16x16 unitary. Note: GitHub issue #4369, Qiskit/qiskit External Links: Link Cited by: §3.2. Qiskit Developers (2023a) Qiskit Developers circuit_to_dag doesnt copy metadata. Note: GitHub issue #10570, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2023b) Qiskit Developers sampled_expectation_value returning incorrect results for complex coefficients. Note: GitHub issue #11393, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2024a) Qiskit Developers Fix QuantumCircuit.depth with zero-operands and Expr nodes. Note: GitHub pull request #12429, Qiskit/qiskit External Links: Link Cited by: Table 1, §5. Qiskit Developers (2024b) Qiskit Developers HoareOptimizer() changes circuit semantics. Note: GitHub issue #13079, Qiskit/qiskit External Links: Link Cited by: §1, Figure 2, §3.2. Qiskit Developers (2024c) Qiskit Developers Incorrect Topological Order when Specifying a Custom-Tiebreaker. Note: GitHub issue #12157, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2024d) Qiskit Developers Pauli.evolve(qc, frame=’s’) will ignore contents of qc for certain values of qc.name. Note: GitHub issue #12093, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2024e) Qiskit Developers Qiskit 1.2.0: dagcircuit implementation (dagcircuit.py). Note: GitHub source codeVersion 1.2.0 External Links: Link Cited by: §3.2. Qiskit Developers (2024f) Qiskit Developers Qiskit 1.2.0: hoareoptimizer pass implementation (hoare_opt.py). Note: GitHub source codeVersion 1.2.0 External Links: Link Cited by: §3.2. Qiskit Developers (2024g) Qiskit Developers StatevectorSampler always samples the same outcomes when seed is an integer. Note: GitHub issue #13047, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2024h) Qiskit Developers Transpiler changes circuit semantics. Note: GitHub issue #13118, Qiskit/qiskit External Links: Link Cited by: §3.1. Qiskit Developers (2024i) Qiskit Developers UnitarySynthesis silently decomposes to invalid bases. Note: GitHub issue #11974, Qiskit/qiskit External Links: Link Cited by: Table 1, §6.2, §6.2. Qiskit Developers (2025a) Qiskit Developers Isometry is phase-incorrect for [-1,0]. Note: GitHub issue #15465, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2025b) Qiskit Developers SparsePauliOp.is_unitary() doesn’t respect the input tolerance values. Note: GitHub issue #14107, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2025c) Qiskit Developers TimingConstraints in a Target are ignored in generate_preset_pass_manager. Note: GitHub issue #14329, Qiskit/qiskit External Links: Link Cited by: Table 1. Qiskit Developers (2026a) Qiskit Developers BasicSwap silently inflates circuit global_phase. Note: GitHub issue #16271, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026b) Qiskit Developers BitArray.bitcount() counts packed padding bits after bitwise invert. Note: GitHub issue #16173, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026c) Qiskit Developers CommutationChecker yields false positives for CRZ and SWAP resulting in silent miscompilation. Note: GitHub issue #16164, Qiskit/qiskit External Links: Link Cited by: §1, Table 6. Qiskit Developers (2026d) Qiskit Developers CommutativeCancellation incorrectly adds spurious global phase to P/U1 gates accumulating to 2π. Note: GitHub issue #16377, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026e) Qiskit Developers CommutativeOptimization silently corrupts direction-sensitive XXPlusYYGate by incorrectly treating it as a symmetric gate. Note: GitHub issue #16161, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026f) Qiskit Developers Commuting2qGateRouter silently inflates circuit global_phase. Note: GitHub issue #16205, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026g) Qiskit Developers Correctly combining control modifiers in OptimizeAnnotated. Note: GitHub pull request #16428, Qiskit/qiskit External Links: Link Cited by: §6.3. Qiskit Developers (2026h) Qiskit Developers dagdependency_to_circuit() drops DAGDependency.global_phase. Note: GitHub issue #16166, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026i) Qiskit Developers Initialize.gates_to_uncompute loses num_qubits for documented integer-bitmap inputs. Note: GitHub issue #16413, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026j) Qiskit Developers LinearFunction.inverse() raises CircuitError for valid LinearFunction inputs. Note: GitHub issue #16184, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026k) Qiskit Developers marginal_counts silently fails for Counts constructed from hex keys when optional memory_slots is omitted. Note: GitHub issue #16190, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026l) Qiskit Developers MultiplierGate(1, 1).decompose() fails because its definition has the wrong number of qubits. Note: GitHub issue #16168, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026m) Qiskit Developers OptimizeAnnotated (_canonicalize_modifiers) changes the unitary for a negative fractional PowerModifier. Note: GitHub issue #16411, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026n) Qiskit Developers OptimizeAnnotated changes the circuit unitary when combining nested ControlModifiers with different ctrl_state. Note: GitHub issue #16410, Qiskit/qiskit External Links: Link Cited by: Figure 5, §6.3, Table 6. Qiskit Developers (2026o) Qiskit Developers Parameter binding incorrectly evaluates p**n ± q**n as (p ± q)**n. Note: GitHub issue #16259, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026p) Qiskit Developers ParameterExpression add/sub simplification treats division as multiplication, observable via assign_parameters(). Note: GitHub issue #16263, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026q) Qiskit Developers ParameterExpression division simplification gives wrong values, observable via QuantumCircuit.assign_parameters(). Note: GitHub issue #16262, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026r) Qiskit Developers ParameterExpression.gradient() misses chain-rule factors for power expressions with composite base or exponent. Note: GitHub issue #16260, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026s) Qiskit Developers pyo3_runtime.PanicException: index out of bounds in Rust nlayout.rs during Sabre transpilation on disconnected CouplingMap. Note: GitHub issue #15841, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026t) Qiskit Developers Qiskit 2.4.1. Note: GitHub release External Links: Link Cited by: §1, §5. Qiskit Developers (2026u) Qiskit Developers Qiskit 2.4.1: standard gate commutation implementation. Note: GitHub source codeVersion 2.4.1 External Links: Link Cited by: §4.2. Qiskit Developers (2026v) Qiskit Developers QuantumCircuit.for_loop raises OverflowError for negative integers in a list indexset. Note: GitHub issue #16412, Qiskit/qiskit External Links: Link Cited by: Table 6. Qiskit Developers (2026w) Qiskit Developers UnrollForLoops adds loop-body global_phase one extra time. Note: GitHub issue #16185, Qiskit/qiskit External Links: Link Cited by: Table 6. Rigger and Su (2022) M. Rigger and Z. Su Intramorphic testing: a new approach to the test oracle problem. In Proceedings of the 2022 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, p. 128–136. Cited by: §1, §3.1. Rosa and Santiago (2026) E. Rosa and R. Santiago Schrödinger’s bug: a survey on quantum software debugging. Quantum Information Processing 25 (3), p. 96. Cited by: §1, §2.3. Salam and Ilyas (2024) M. Salam and M. Ilyas Quantum computing challenges and solutions in software industry—a multivocal literature review. IET Quantum Communication 5 (4), p. 462–485. Cited by: §1. Sheng et al. (2026) Z. Sheng, Z. Chen, Q. Xu, K. Zhu, and J. Huang FuzzingBrain v2: a multi-agent llm system for automated vulnerability discovery and reproduction. arXiv preprint arXiv:2605.21779. Cited by: §4. The Rust Project (2026) The Rust Project The Rust Reference: Comments. Note: Language reference External Links: Link Cited by: §4.2. Upadhyay et al. (2025) K. Upadhyay, V. Chhetri, A. Siddique, and U. Farooq Analyzing the evolution and maintenance of quantum software repositories. In 2025 IEEE International Conference on Quantum Software (QSW), p. 173–184. Cited by: §2.2. Upadhyay et al. (2026) K. Upadhyay, M. Fakorede, and U. Farooq Understanding bugs in quantum simulators: an empirical study. arXiv preprint arXiv:2603.22789. Cited by: §1. Wang et al. (2021) J. Wang, Q. Zhang, G. H. Xu, and M. Kim QDiff: differential testing of quantum software stacks. In 2021 36th IEEE/ACM international conference on automated software engineering (ASE), p. 692–704. Cited by: §1, §2.3. Wei et al. (2025) A. Wei, J. Cao, R. Li, et al. EquiBench: benchmarking large language models’ reasoning about program semantics via equivalence checking. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, p. 33856–33869. Cited by: §1, §4. Xia et al. (2024) C. S. Xia, M. Paltenghi, J. Le Tian, M. Pradel, and L. Zhang Fuzz4all: universal fuzzing with large language models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, p. 1–13. Cited by: §1, §2.3. Xia et al. (2026) F. Xia, Q. Zhang, C. Ying, H. Zhu, S. Wang, Y. Luo, P. Ma, and Y. Du KQFuzz: knowledge-guided fuzzing for quantum libraries via large language models. arXiv preprint arXiv:2607.25647. Cited by: §1, §8. Xu et al. (2025) X. Xu, F. Xie, C. Zhu, et al. Identifying multi-parameter constraint errors in python data science library api documentation. Proceedings of the ACM on Software Engineering 2 (ISSTA), p. 1536–1558. Cited by: §7. Yang et al. (2024a) C. Yang, Y. Deng, R. Lu, J. Yao, J. Liu, R. Jabbarvand, and L. Zhang Whitefox: white-box compiler fuzzing empowered by large language models. Proceedings of the ACM on Programming Languages 8 (OOPSLA2), p. 709–735. Cited by: §2.3. Yang et al. (2024b) J. Yang, C. Jimenez, A. Wettig, et al. Swe-agent: agent-computer interfaces enable automated software engineering. In Advances in Neural Information Processing Systems, Vol. 37, p. 50528–50652. Cited by: §8. Ye et al. (2026) J. Ye, F. Zhang, S. Xia, X. Guo, X. Wu, J. Zhao, and Y. Xue QSPE: enumerating skeletal quantum programs for quantum library testing. arXiv preprint arXiv:2602.00024. Cited by: §1, §2.3. Zappin et al. (2026) J. Zappin, T. Stalnaker, O. Chaparro, and D. Poshyvanyk Challenges and practices in quantum software testing and debugging: insights from practitioners. ACM Transactions on Software Engineering and Methodology. Cited by: §1. Zhang et al. (2024) C. Zhang, Y. Zheng, M. Bai, Y. Li, W. Ma, X. Xie, Y. Li, L. Sun, and Y. Liu How effective are they? exploring large language model based fuzz driver generation. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, p. 1223–1235. Cited by: §2.3. Zhang et al. (2025) K. Zhang, S. Wang, J. Han, X. Zhu, X. Li, S. Wang, and S. Wen Your fix is my exploit: enabling comprehensive dl library api fuzzing with large language models. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), p. 3110–3122. Cited by: §2.3. Zheng et al. (2025) M. Zheng, C. Wang, X. Liu, et al. RFCAudit: an llm agent for functional bug detection in network protocols. arXiv preprint arXiv:2506.00714. External Links: Document, Link Cited by: §8.