<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: kristian koci</title>
    <description>The latest articles on DEV Community by kristian koci (@kkoci).</description>
    <link>https://dev.to/kkoci</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F147375%2F1e323e10-f7e5-4f15-bdbc-ddc1e687b5cd.jpeg</url>
      <title>DEV Community: kristian koci</title>
      <link>https://dev.to/kkoci</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/kkoci"/>
    <language>en</language>
    <item>
      <title>I built three tools for Quantinuum's guppy stack. Along the way I found six real bugs.</title>
      <dc:creator>kristian koci</dc:creator>
      <pubDate>Tue, 15 Sep 2026 22:57:25 +0000</pubDate>
      <link>https://dev.to/kkoci/i-built-three-tools-for-quantinuums-guppy-stack-along-the-way-i-found-six-real-bugs-2cp4</link>
      <guid>https://dev.to/kkoci/i-built-three-tools-for-quantinuums-guppy-stack-along-the-way-i-found-six-real-bugs-2cp4</guid>
      <description>&lt;h1&gt;
  
  
  I built three tools for Quantinuum's guppy/HUGR stack. Along the way I found six real bugs.
&lt;/h1&gt;

&lt;p&gt;I've been working with &lt;a href="https://github.com/Quantinuum/guppylang" rel="noopener noreferrer"&gt;guppylang&lt;/a&gt; — Quantinuum's&lt;br&gt;
Python-embedded quantum programming language, compiling to HUGR, running on their Selene&lt;br&gt;
simulator and trapped-ion hardware. It's a young ecosystem, and I wanted to build things that&lt;br&gt;
were actually useful, not just demos. That meant treating correctness as the whole point, not&lt;br&gt;
an afterthought — every formula cited to its source, every claim about compiler behavior&lt;br&gt;
verified by actually compiling code and inspecting the output, not assumed from docs.&lt;/p&gt;

&lt;p&gt;That discipline turned out to matter more than expected. Building three fairly ordinary&lt;br&gt;
developer tools surfaced six real, confirmed bugs — four in guppylang itself, two in Google's&lt;br&gt;
Qualtran (a widely-used quantum resource-estimation library) — none of which I was looking for&lt;br&gt;
going in.&lt;/p&gt;

&lt;h2&gt;
  
  
  The three tools
&lt;/h2&gt;

&lt;p&gt;&lt;strong&gt;&lt;a href="https://github.com/kkoci/Qshelf" rel="noopener noreferrer"&gt;qshelf&lt;/a&gt;&lt;/strong&gt; — a tested package registry of quantum algorithm&lt;br&gt;
implementations for guppylang/HUGR (QFT, Grover, QAOA, VQE-H2), each verified against an&lt;br&gt;
independent mathematical reference (exact linear algebra, &lt;code&gt;scipy.linalg.expm&lt;/code&gt;, exact&lt;br&gt;
diagonalization), not just "it ran without crashing."&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;a href="https://github.com/kkoci/Estimand" rel="noopener noreferrer"&gt;Estimand&lt;/a&gt;&lt;/strong&gt; — a fault-tolerant resource estimator for&lt;br&gt;
guppy/HUGR programs. Given a compiled guppy circuit, it estimates physical qubit count,&lt;br&gt;
runtime, and error probability under a surface-code scheme. It's an adapter, not a&lt;br&gt;
resource-estimation engine — it extracts a gate-count summary from real guppy control flow&lt;br&gt;
(conditionals, nested loops, cross-function calls, even &lt;code&gt;CallIndirect&lt;/code&gt;) and feeds it to&lt;br&gt;
Qualtran's already-published cost models. Verified end-to-end against unmodified QFT and&lt;br&gt;
Grover implementations.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;a href="https://github.com/kkoci/qmatchpoint" rel="noopener noreferrer"&gt;qmatchpoint&lt;/a&gt;&lt;/strong&gt; — wires PyMatching (an established,&lt;br&gt;
peer-reviewed decoder) to the syndrome bits a guppy QEC circuit produces, since nothing in the&lt;br&gt;
guppylang/HUGR/Selene stack currently does decoding.&lt;/p&gt;

&lt;h2&gt;
  
  
  The bugs
&lt;/h2&gt;

&lt;p&gt;Building qshelf against real algorithm math found four guppylang issues: a wrong unitary from&lt;br&gt;
&lt;code&gt;iqft&lt;/code&gt; compiled standalone vs. combined with &lt;code&gt;qft&lt;/code&gt;, a wrong unitary from multi-controlled Z&lt;br&gt;
(later fixed upstream), a rejected generic array-length type, and a rejected &lt;code&gt;numpy.ndarray&lt;/code&gt;&lt;br&gt;
closure (reclassified as a feature request).&lt;/p&gt;

&lt;p&gt;The more interesting ones came from Estimand. Its whole job is turning guppy programs into gate&lt;br&gt;
counts, then trusting Qualtran's surface-code math to do the rest — so I went and checked that&lt;br&gt;
math against the actual cited papers (Beverland et al. 2022, Litinski 2019 x2), rather than&lt;br&gt;
trusting the citation. Two real discrepancies turned up:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;CompactDataBlock&lt;/code&gt;'s tile-count formula was missing an additive constant from its own cited
paper (&lt;code&gt;arxiv.org/abs/1808.02892&lt;/code&gt;, Fig. 9) — confirmed by a maintainer, and by the time I got
around to fixing it, main had already drifted to a &lt;em&gt;different&lt;/em&gt; wrong version of the same
formula. &lt;a href="https://github.com/quantumlib/Qualtran/pull/1949" rel="noopener noreferrer"&gt;PR here&lt;/a&gt;, awaiting review.&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;make_beverland_et_al()&lt;/code&gt;'s magic-state factory error model silently used Beverland's
threshold constant instead of Litinski's own, inside a component that's otherwise a faithful
reimplementation of Litinski's paper. Turned into a longer, still-open discussion about
whether the whole preset should more faithfully reproduce Beverland's actual architecture
choices (data block, factory grid-search) rather than borrowing Litinski's defaults.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;None of this was the goal going in. It's just what happens when "does this actually match what&lt;br&gt;
it claims to implement" is a mandatory question, not an optional one, and I think that's a more&lt;br&gt;
useful takeaway than any of the three tools individually — verification discipline finds real&lt;br&gt;
things, even (especially) in mature, widely-used libraries.&lt;/p&gt;

&lt;p&gt;Repos linked above if any of it's useful, and happy to talk through any of the decisions behind&lt;br&gt;
them.&lt;/p&gt;

</description>
      <category>debugging</category>
      <category>python</category>
      <category>softwaredevelopment</category>
    </item>
  </channel>
</rss>
