Pith. sign in

REVIEW 3 major objections 6 minor 1 cited by

Pushing the Limits of LLMs in Quantum Operations

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that four publicly available LLMs produce executable quantum gate designs for 80% of a 25-prompt benchmark, with Gemini the fastest overall.

desk verdict A transparent but under-powered benchmark: the timing ranking has no variance, and the 80% success rate is contradicted by the paper's own 23/25 table. read the letter →

arxiv 2507.21327 v1 pith:PXLDO2DY submitted 2025-07-28 quant-ph

Dayton C. Closser , Zbigniew J. Kabala This is my paper
classification quant-ph
keywords largelanguagemodelsquantumgatesynthesisbenchmarkingcircuitgenerationGeminiQiskitLLMspeedinteroperability
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper reports what the authors describe as the first systematic benchmark of four publicly available large language models—WolframLLM, OpenAI ChatGPT, Google Gemini, and DeepSeek—on the task of producing executable quantum gate designs. They claim that Gemini is the fastest overall, with an average combined time of 1.35 seconds per prompt when LLM response time and Python execution time are added, and that all four models produced code that compiled successfully in 80% of the 25 test prompts. The study matters because it tests whether generic, publicly available LLMs can serve as practical collaborators for quantum circuit synthesis, an application the authors frame as advancing interoperability between AI and quantum computers. The speed advantage is the headline result, but the uniform 80% compilation rate is the result with the broader practical consequence.

What carries the argument

The argument is carried by a benchmark harness built in Wolfram Mathematica: 25 quantum gate synthesis prompts (Pauli gates, Bell states, Deutsch's algorithm, quantum Fourier transform, teleportation, among others) are sent to each LLM, the per-prompt response time is recorded through the Mathematica connection, the programmatic output between the START and END markers is filtered into Python3, and that code is executed twice in a Jupyter Notebook on a fixed testbed machine. The final speed ranking is computed as the average, over the 25 prompts, of the LLM response time plus the Python execution time, with a separate ServiceConnect time measured for three of the four models to gauge networking latency.

What would settle it

Re-run the same 25 prompts several times per model, isolating the model's generation time from network latency by timing the Mathematica request locally, and check whether Gemini still has the lowest average total time; if the ordering changes under repetition, the central speed claim is overturned.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is an empirical ranking: given the same 25 quantum-circuit prompts, Google Gemini produced the fastest overall working code when both the model's response time and the Python execution time of the generated code are averaged together (1.35 s), followed by WolframLLM (1.75 s), OpenAI ChatGPT (2.62 s), and DeepSeek (6.12 s). Every model compiled 80% of the prompts, and no model beat the others in success rate; the failures were prompt-specific, with only Prompt 13 failing for multiple models and with different error types. The ranking is unchanged when the measured service-connect times are factored in, and it holds even though DeepSeek had the fastest average Python execution time (4.38 ms) and lowest memory usage (49.90 KB). The authors interpret the result as evidence that publicly available LLMs are already fast and reasonably reliable generators of quantum gate designs.

Load-bearing premise

The speed ranking assumes that a single response from each LLM for each prompt is representative of that model's performance, with no repeated trials or variance estimates and with network latency included in the recorded times.

Editorial extensions

If this is right

  • If the 80% compilation rate holds across other gate-synthesis prompt sets, general-purpose LLMs become a viable first-pass tool for producing quantum circuit code, with a human or automated checker catching the remaining 20%.
  • A standardized benchmark of this kind can be rerun as new LLM versions appear, turning 'which model is fastest at quantum gate design' into a continuously measurable quantity rather than an anecdotal comparison.
  • The fact that most outputs rely on the Qiskit framework suggests that LLM training data is skewed toward one quantum programming ecosystem, which could shape which quantum software stack new users adopt.
  • If response time continues to dominate total time, then reducing network and inference latency matters more than optimizing the generated Python code for end-to-end quantum design speed.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next test is to scale the prompt set from 25 to several hundred and stratify by difficulty, which would tell whether the 80% success rate is stable or an artifact of the particular prompt mix.
  • Because DeepSeek had the fastest generated-code execution and lowest memory usage but the slowest LLM response, the paper hints that speed rankings are sensitive to whether the bottleneck is model generation or code efficiency; weighting the two components differently could reverse the overall ranking.
  • For practical LLM-assisted quantum work, the more consequential finding may be the uniform 80% compile rate rather than Gemini's speed: even the slowest model finishes in about 6 seconds, so reliability, not latency, is what currently limits fully automated gate synthesis.
  • The paper's 'interoperability' framing suggests a research program in which LLMs serve as a natural-language-to-circuit layer above quantum hardware, but the data measure compilation success and gate-design correctness only indirectly, not full unitary fidelity.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents a benchmark of four publicly available LLMs (WolframLLM, OpenAI ChatGPT, Google Gemini, and DeepSeek) for generating quantum gate designs. Prompts for 25 quantum tasks were issued through Wolfram Mathematica; the resulting code was extracted and executed in Python, with measurements of LLM response time (including network latency), Python execution time, lines of code, memory usage, and compilation success. The authors claim that Gemini is the fastest overall LLM and that the tested models achieved working quantum operations 80% of the time. The manuscript includes prompt tables, an error table, and links to a public repository with raw outputs.

Significance. If the benchmark were statistically and methodologically sound, it would be a useful reference point for LLM-based quantum gate synthesis and for the broader interoperability agenda the authors advocate. The main strengths are the concrete prompt set, the public repository of raw outputs, and the transparency about the testbed. However, the two headline claims, the Gemini-fastest ranking and the 80% success rate, are not supported by the reported evidence: the speed comparison rests on single observations per prompt with no variance estimates and includes network latency, while the success-rate figure contradicts the paper's own compilation table. These issues are load-bearing, so the current version does not justify its central conclusions.

major comments (3)
  1. [Section 4, Tables 1 and 6] The headline speed ranking is not supported by the reported measurements. Each of the 25 prompts was sent once per LLM, with no repeated trials, no standard deviations or confidence intervals, and the timings include network/service latency as the Abstract explicitly states; in addition, the LLM versions and test dates are not pinned. Because Table 1 averages one observation per prompt, a single slow or fast response can change the Gemini/WolframLLM/OpenAI ordering. Table 6 compounds the problem by averaging Table 1 (seconds) with Table 3 (milliseconds), so the 'overall' ranking is effectively the one-shot LLM response-time ranking with negligible contribution from Python execution time. Repeating each prompt multiple times and reporting distributions, or performing paired per-prompt comparisons, is necessary before claiming that Gemini is fastest.
  2. [Abstract, Section 4.5, Section 4.6, Table 7] The claimed 80% success rate is internally inconsistent with the paper's own data. Table 7 lists exactly two non-compiling prompts per model, and Section 4.6 reports 23 compiled programs out of 25, which is 92%, not 80%. The 80% figure is repeated in the Abstract and Section 5, so it is not a one-off typo. The authors should correct the success-rate calculation, or explain what additional criterion beyond compilation produces the 80% number, and ensure that all statements of the accuracy claim are consistent.
  3. [Section 4.6 and Tables 8–12] The paper does not describe how the Eval Criteria listed in the prompt tables were applied to the compiled outputs, nor how 'successes' were counted beyond compilation. Since 'working quantum operations' is one of the two headline claims, the evaluation protocol should be specified in enough detail to be reproduced, for example whether correctness was checked by unitary comparison, statevector inspection, measurement statistics, or manual review. Without this, the reader cannot verify that the compiled programs actually satisfy the intended quantum operations.
minor comments (6)
  1. [Abstract] The opening line of the abstract contains run-together words ('ArtificialIntelligenceLargeLanguageModel'); the manuscript has numerous similar spacing and formatting issues that should be corrected by copyediting.
  2. [Section 3] The exact LLM model identifiers (e.g., GPT-4o versus ChatGPT-4, Gemini 1.5 versus 2.0, DeepSeek-V3) are not stated, and the dates of the queries are not given; because these services change rapidly, this information is essential for reproducibility.
  3. [Section 4.3.1] The statement that OpenAI and WolframLLM had identical average lines of code and are 'population-wise, identical!' is confusing; identical averages do not imply identical populations, and the paragraph should be reworded to avoid this implication.
  4. [Abstract and Introduction] The claim of being the 'first benchmarking study' is difficult to reconcile with the existing LLM quantum-code benchmarks cited in references [25]–[27]; the novelty claim should be qualified, for example as the first speed-focused comparison of publicly available LLM chat services for gate synthesis.
  5. [Section 4.2] The statement that each Python program was executed twice, with the second execution logged, is welcome; however, no analogous repetition is reported for the LLM response times, which are the dominant contribution to the overall ranking.
  6. [Section 5] The claim that including ServiceConnect times 'does not change these rankings' is not demonstrated, since WolframLLM has no ServiceConnect measurement and the corrected numbers are not tabulated.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an empirical external benchmark with no derivation chain whose conclusions could reduce to their inputs.

full rationale

The paper's central claims are direct measurements, not derived predictions. The 'fastest LLM' result is a restatement of recorded execution times (Table 1 and Table 6), and the '80% success rate' is a tally of compile outcomes; neither quantity is fitted, defined in terms of itself, or justified by a self-citation. No uniqueness theorem, ansatz, or known result is repackaged as a discovery. The averaging procedure that combines seconds and milliseconds in Table 6 is statistically questionable, and the 80% figure conflicts with the paper's own 23-of-25 compiled programs (92%), but these are correctness or reporting concerns, not circularity. The benchmarking is self-contained as an external measurement of LLM behavior over a public prompt set, so the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper contains no fitted mathematical parameters or invented entities. The central claims rest on measurement assumptions: that one-shot timing is representative, that compile-and-run success means functional correctness, and that the prompt set is representative of quantum operation design.

assumptions (3)
  • domain assumption LLM response time is stable enough for a single measurement per prompt to rank models.
    The ranking in Table 6 is computed from one LLM response per prompt per model; the paper reports no repeated trials or variance, so ranking validity depends on this stability assumption.
  • domain assumption Compile-and-run success is a valid measure of a correct quantum operation.
    The test harness evaluates whether output compiles and runs; many outputs rely on Qiskit and are not checked for unitary equivalence to the requested operation, so the 80% figure assumes execution implies correctness.
  • domain assumption The 25 handpicked prompts represent the space of quantum gate design tasks.
    Prompt selection is budget-driven and not justified by coverage; bias toward Qiskit-common tasks limits generalization of the results.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Pushing the Limits of LLMs in Quantum Operations." pith.science (2026). https://pith.science/paper/PXLDO2DY

@misc{pith2026250721327,
  author       = {Pith},
  title        = {Pith review of: Pushing the Limits of LLMs in Quantum Operations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PXLDO2DY}},
  note         = {Machine review of arXiv:2507.21327}
}
read the original abstract

What is the fastest Artificial Intelligence Large Language Model (AI LLM) for generating quantum operations? To answer this, we present the first benchmarking study comparing popular and publicly available AI models tasked with creating quantum gate designs. The Wolfram Mathematica framework was used to interface with the 4 AI LLMs, including WolframLLM, OpenAI ChatGPT, Google Gemini, and DeepSeek. This comparison evaluates both the time taken by each AI LLM platform to generate quantum operations (including networking times), as well as the execution time of these operations in Python, within Jupyter Notebook. Our results show that overall, Gemini is the fastest AI LLM in producing quantum gate designs. At the same time, the AI LLMs tested achieved working quantum operations 80% of the time. These findings highlight a promising horizon where publicly available Large Language Models can become fast collaborators with quantum computers, enabling rapid quantum gate synthesis and paving the way for greater interoperability between two remarkable and cutting-edge technologies.

Figures

Figures reproduced from arXiv: 2507.21327 by the authors.

Figure 1
Figure 1. Testbed Platform. As well, we also measured the quantities of time for how long each AI platform took to respond to initial requests or connections with Mathemat￾ica. At the time of this writing, this was not pos￾sible for Wolfram LLM, as there was no native API support for measuring the connection time for this internal Wolfram service. Crucially, this captured the total time from the sending of the prompt request … view at source ↗
Figure 3
Figure 3. WolframLLM AI Execution Times [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. OpenAI Execution Times. Gemini was followed by WolframLLM, Ope￾nAI, and DeepSeek, respectively. Because DeepSeek was extraordinarily slower than the other LLMs on the 0-15 second scale, we elected to use a larger 0-35 second window to accommo￾date this extra latency, as shown in [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (15 more)
Figure 5
Figure 5. Figure 5: DeepSeek AI Execution Times [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 7
Figure 7. Figure 7: DeepSeek ServiceConnect Moving Averages. [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 6
Figure 6. Figure 6: Comparison DeepSeek (Top) and OpenAI (Bottom) Average LLM Execution Time Table LLM Model Average Execution Time (s) Gemini 2.67 WolframLLM 3.48 OpenAI 5.22 DeepSeek 12.23 [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 9
Figure 9. Figure 9: OpenAI ServiceConnect Moving Averages. 5 [PITH_FULL_IMAGE:figures/full_fig_p005_9.png]
Figure 12
Figure 12. Figure 12: WolframLLM Python Execution Times [PITH_FULL_IMAGE:figures/full_fig_p006_12.png]
Figure 14
Figure 14. Figure 14: OpenAI Python Execution Times [PITH_FULL_IMAGE:figures/full_fig_p006_14.png]
Figure 15
Figure 15. Figure 15: Four Way Average Comparison of Python Execution Times. It is noteworthy that of all the LLMs, both OpenAI and Gemini were within a few tenths of a millisecond average of each other across executing all prompts. This average was computed by tak￾ing each prompt’s execut…
Figure 11
Figure 11. Figure 11: DeepSeek Python Execution Times [PITH_FULL_IMAGE:figures/full_fig_p006_11.png]
Figure 18
Figure 18. Figure 18: OpenAI LoC [PITH_FULL_IMAGE:figures/full_fig_p007_18.png]
Figure 19
Figure 19. Figure 19: WolframLLM LoC. 4.3.1 Average Four Way Comparison [PITH_FULL_IMAGE:figures/full_fig_p007_19.png]
Figure 16
Figure 16. Figure 16: Gemini LoC [PITH_FULL_IMAGE:figures/full_fig_p007_16.png]
Figure 17
Figure 17. Figure 17: DeepSeek LoC [PITH_FULL_IMAGE:figures/full_fig_p007_17.png]
Figure 21
Figure 21. Figure 21: DeepSeek Python Memory Usage [PITH_FULL_IMAGE:figures/full_fig_p008_21.png]
Figure 22
Figure 22. Figure 22: Gemini Python Memory Usage [PITH_FULL_IMAGE:figures/full_fig_p008_22.png]
Figure 23
Figure 23. Figure 23: WolframLLM Python Memory Usage [PITH_FULL_IMAGE:figures/full_fig_p008_23.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Qiskit Code Migration with LLMs

    cs.SE 2026-06 unverdicted novelty 5.0 of 10

    A taxonomy-guided RAG system with LLMs reduces hallucinations and improves migration suggestions for Qiskit code compared to unconstrained retrieval.

Reference graph

Works this paper leans on

30 extracted references · 14 canonical work pages · cited by 1 Pith paper

  1. [1]

    Quantum computing in the nisq era and beyond,

    J. Preskill, “Quantum computing in the nisq era and beyond,” Quantum, vol. 2, p. 79, 2018. [Online]. Available: https://doi.org/10.22331/q-2018-08-06-79

    doi:10.22331/q-2018-08-06-79 2018

  2. [2]

    Quantum error correction now!

    K. Brown, “Quantum error correction now!” Invited lecture at JST Moonshot Symposium, Japan Science and Technology Agency (JST), July 18, 2023, 2023. [Online]. Available: https://www.jst.go.jp/moonshot/sympo/20230718/material/1_4_ken_brown.pdf

    work page arXiv 2023

  3. [3]

    Relaxing hardware requirements for surface code circuits using time-dynamics,

    M. McEwen, D. Bacon, and C. Gidney, “Relaxing hardware requirements for surface code circuits using time-dynamics,” Quantum, vol. 7, p. 1172, 2023. [Online]. Available: https://doi.org/10.22331/q-2023-11-07-1172

    doi:10.22331/q-2023-11-07-1172 2023

  4. [4]

    Fault-tolerant hyperbolic floquet quantum error correcting codes,

    A. Fahimniya, H. Dehghani, K. Bharti, S. Mathew, A. J. Kollár, A. V. Gorshkov, and M. J. Gullans, “Fault-tolerant hyperbolic floquet quantum error correcting codes,” 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2309.10033

    arXiv doi:10.48550/arxiv.2309.10033 2023

  5. [5]

    Quantum error correction and architectures: A tutorial,

    K. Brown and M. Newman, “Quantum error correction and architectures: A tutorial,” 2024. [Online]. Available: https://brownlab.pratt.duke.edu/

    work page 2024

  6. [6]

    D. H. McIntyre, Quantum Mechanics. Cambridge University Press, 2022. [Online]. Available: https://doi.org/10.1017/9781009310598

    work page doi:10.1017/9781009310598 2022

  7. [7]

    Most quantum states are too entangled to be useful as computational resources,

    D. Gross, S. T. Flammia, and J. Eisert, “Most quantum states are too entangled to be useful as computational resources,” Phys. Rev. Lett. , vol. 102, no. 19, p. 190501, May 2009. [Online]. Available: https://doi.org/10.1103/PhysRevLett.102.190501

    work page doi:10.1103/physrevlett.102.190501 2009

  8. [8]

    A survey of quantum learning theory,

    S. Arunachalam and R. de Wolf, “A survey of quantum learning theory,” 2017. [Online]. Available: https://doi.org/10.1145/3106700.3106710

    work page arXiv 2017

Show all 30 references
  1. [9]

    Quantum computers,

    T. D. Ladd, F. Jelezko, R. Laflamme, Y. Nakamura, C. Monroe, and J. L. O’Brien, “Quantum computers,” Nature, vol. 464, no. 7285, pp. 45–53, 2010. [Online]. Available: https://doi.org/10.1038/nature08812

    2010 doi

  2. [10]

    Optical quantum computing,

    J. L. O’Brien, “Optical quantum computing,”Science, vol. 318, no. 5856, pp. 1567–1570, 2007. [Online]. Available: https://doi.org/10.1126/science.1156956

    2007 doi

  3. [11]

    Information content of the gravitational field of a quantum superposition,

    A. Belenchia, R. M. Wald, F. Giacomini, E. Castro-Ruiz, C. Brukner, and M. Aspelmeyer, “Information content of the gravitational field of a quantum superposition,” International Journal of Modern Physics D , vol. 28, no. 14, p. 1943001, 2019. [Online]. Available: https://doi.o...

    2019 doi arXiv

  4. [12]

    Exploiting chemistry and molecular systems for quantum information science,

    M. R. Wasielewski et al. , “Exploiting chemistry and molecular systems for quantum information science,” Nat. Rev. Chem. , vol. 4, no. 9, pp. 490–504, 2020. [Online]. Available: https://doi.org/10.1038/s41570-020-0210-7

    2020 doi

  5. [13]

    Decoherence effects on superpositions of chiral states in a chiral molecule,

    M. Bahrami, A. Shafiee, and A. Bassi, “Decoherence effects on superpositions of chiral states in a chiral molecule,” Physical Chemistry Chemical Physics , vol. 14, no. 25, pp. 9214–9218, 2012. [Online]. Available: https://doi.org/10.48550/arXiv.1202.0201

    2012 doi arXiv

  6. [14]

    Quantum metrology from a quantum information science perspective,

    G. Tóth and I. Apellaniz, “Quantum metrology from a quantum information science perspective,” Journal of Physics A: Mathematical and Theoretical , vol. 47, no. 42, p. 424006, 2014. [Online]. Available: https://doi.org/10.1088/1751-8113/47/42/424006

    2014 doi

  7. [15]

    Non-abelian anyons and topological quantum computation,

    C. Nayak, S. H. Simon, A. Stern, M. Freedman, and S. D. Sarma, “Non-abelian anyons and topological quantum computation,” Rev. Mod. Phys. , vol. 80, no. 3, pp. 1083–1159, 2008. [Online]. Available: https://doi.org/10.1103/RevModPhys.80.1083

    2008 doi

  8. [16]

    Trapped-ion quantum computing: Progress and challenges,

    C. D. Bruzewicz, J. Chiaverini, R. McConnell, and J. M. Sage, “Trapped-ion quantum computing: Progress and challenges,” Applied Physics Reviews , vol. 6, no. 2, p. 021314, 2019. [Online]. Available: https://doi.org/10.1063/1.5088164 16

    2019 doi

  9. [17]

    Elucidating reaction mechanisms on quantum computers,

    M. Reiher, N. Wiebe, K. M. Svore, D. Wecker, and M. Troyer, “Elucidating reaction mechanisms on quantum computers,” Proc. Natl. Acad. Sci. U.S.A , vol. 114, no. 29, pp. 7555–7560, 2017. [Online]. Available: https://doi.org/10.1073/pnas.1619152114

    2017 doi

  10. [18]

    A one-way quantum computer,

    R. Raussendorf and H. J. Briegel, “A one-way quantum computer,” Phys. Rev. Lett. , vol. 86, no. 22, p. 5188, 2001. [Online]. Available: https://doi.org/10.1103/PhysRevLett.86.5188

    2001 doi

  11. [19]

    Blueprint for a scalable photonic fault-tolerant quantum computer,

    J. E. Bourassa, R. N. Alexander, M. Vasmer, A. Patil, I. Tzitrin, T. Matsuura, I. Dhandet al., “Blueprint for a scalable photonic fault-tolerant quantum computer,”Quantum, vol. 5, p. 392,

  12. [20]

    Projectq: an open source software framework for quantum computing,

    D. S. Steiger, T. Häner, and M. Troyer, “Projectq: an open source software framework for quantum computing,” Quantum, vol. 2, p. 49, 2018. [Online]. Available: https: //doi.org/10.22331/q-2018-01-31-49

    2018 doi

  13. [21]

    Data-centric machine learning in quantum information science,

    S. Lohani, J. M. Lukens, R. T. Glasser, T. A. Searles, and B. T. Kirby, “Data-centric machine learning in quantum information science,” Machine Learning: Science and Technology , vol. 3, no. 4, p. 04LT01, 2022. [Online]. Available: https://doi.org/10.1088/2632-2153/ac96b5

    2022 doi

  14. [22]

    Quantum computation with quantum dots,

    D. Loss and D. P. DiVincenzo, “Quantum computation with quantum dots,” Phys. Rev. A , vol. 57, no. 1, p. 120, 1998. [Online]. Available: https://doi.org/10.1103/PhysRevA.57.120

    1998 doi

  15. [23]

    Fault-tolerant quantum computation by anyons,

    A. Y. Kitaev, “Fault-tolerant quantum computation by anyons,” Annals of Physics , vol. 303, no. 1, pp. 2–30, 2003. [Online]. Available: https://doi.org/10.1016/S0003-4916(02)00018-0

    2003 doi

  16. [24]

    The next revolution in computational simulations: Harnessing ai and quantum computing in molecular dynamics,

    A. Lappala, “The next revolution in computational simulations: Harnessing ai and quantum computing in molecular dynamics,” Current Opinion in Structural Biology , vol. 89, p. 102919,

  17. [25]

    Qiskit code assistant: Training llms for generating quantum computing code,

    N. Dupuis, L. Buratti, S. Vishwakarma, A. V. Forrat, D. Kremer, I. Faro, R. Puri, and J. Cruz-Benito, “Qiskit code assistant: Training llms for generating quantum computing code,”

  18. [26]

    Qiskit humaneval: An evaluation benchmark for quantum code generative models,

    S. Vishwakarma, F. Harkins, S. Golecha, V. S. Bajpe, N. Dupuis, L. Buratti, D. Kremer, I. Faro, R. Puri, and J. Cruz-Benito, “Qiskit humaneval: An evaluation benchmark for quantum code generative models,” in 2024 IEEE International Conference on Quantum Computing and Engineeri...

    2024

  19. [27]

    Pennylang: Pioneering llm-based quantum code generation with a novel pennylane-centric dataset,

    A. Basit, N. Innan, H. Asif, M. Shao, M. Kashif, A. Marchisio, and M. Shafique, “Pennylang: Pioneering llm-based quantum code generation with a novel pennylane-centric dataset,” 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2503.02497 17

    2025 doi arXiv

  20. [28]

    Available: https://doi.org/10.48550/arXiv.2405.19495

    [Online]. Available: https://doi.org/10.48550/arXiv.2405.19495

    doi arXiv

  21. [2021]

    Available: https://doi.org/10.22331/q-2021-02-22-392

    [Online]. Available: https://doi.org/10.22331/q-2021-02-22-392

    2021 doi

  22. [2024]

    Available: https://doi.org/10.1016/j.sbi.2024.102919

    [Online]. Available: https://doi.org/10.1016/j.sbi.2024.102919

    2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.