Chapter 40: The Quantum Programming Career

Thirty-nine chapters ago this book set out to teach quantum programming by measuring everything it claimed. This chapter asks what that adds up to, and what it qualifies you to do.

The honest summary is uncomfortable and it is not discouraging:

No quantum method in this book beat a tuned classical baseline on any problem we could check. Not one. And the field is hiring, the open problems are real, and the skills you have built are the ones it needs — which is a stranger and more interesting situation than either the hype or the backlash describes.

On the numbers in this chapter. Every figure below was harvested from the chapter files by scripts/harvest_scorecard.py, not written from memory. A capstone written from recall produces numbers that are plausible and wrong, and plausible wrong numbers are the hardest kind to catch. The harvest output is in _scratch/harvest-scorecard.md; you can regenerate and check it.

40.1 What the field actually employs people to do

The job title people imagine is "quantum algorithm designer." Almost nobody has it.

What the industry actually employs, in rough order of headcount:

The bottom row is the smallest. The top five are largely classical engineering roles where quantum literacy is the differentiator rather than the content — and the person who understands both is rare enough to be valuable.

Chapter 39 is the sharpest illustration. The dominant cost of a quantum computation turned out to be the queue, and improving it is a scheduling problem. That is a real, well-paid, high-impact job, and it is not a physics job.

What each role actually does

The table above is a taxonomy. Here is what the work looks like, because the titles conceal more than they reveal and students routinely choose badly on the basis of them.

Control software. You write the layer between a circuit description and the instruments that emit microwaves. Instrument drivers, FPGA gateware, timing calibration, and the automated routines that re-characterize a chip every few hours. Chapter 39 measured the artefacts of this work directly: a dt of 4 ns, gate durations of 68–184 ns, and calibration data whose two-qubit error rates spanned 1.79e-03 to 1.00 across one device. Somebody produced those numbers, and keeps producing them.

The skills: real-time systems, hardware interfaces, signal processing, and a great deal of Python wrapping a great deal of C. The quantum content: modest — you need to know what a $\pi/2$ pulse is and why $R_z$ costs nothing.

Compilers and transpilers. Routing, layout, scheduling, gate synthesis, and the optimization passes Chapter 28 measured. This is classical compiler engineering with an unusual cost model: your target has a sparse connectivity graph, per-edge error rates that change daily, and a hard deadline set by $T_2$.

Chapter 39 measured the headroom: a 14-qubit circuit spanning 49 to 112 two-qubit gates across transpiler seeds, with a 2.03× fidelity difference. That spread is unclaimed engineering, and closing it is worth more than most algorithmic work available today.

The skills: graph algorithms, compiler construction, heuristic search. The quantum content: moderate — you need the gate algebra and the noise model, not the physics.

Error-correction decoders. Given a stream of syndrome measurements, infer which errors occurred, in microseconds, continuously, while the computation runs. Chapter 25 built the small codes; the production version is a real-time inference problem under a latency budget set by the physics.

This is the role Chapter 40 §40.5 argues is on the critical path of everything, and Chapter 15's measurement is why: 450 physical qubits for a circuit with zero T gates, 2,882 with one. Every fault-tolerant proposal assumes a decoder that keeps up.

The skills: algorithms, HPC, sometimes FPGA or ASIC, increasingly machine learning. The quantum content: you need stabilizer formalism and nothing beyond it.

Cryogenics and RF. Dilution refrigerators, microwave engineering, wiring, shielding, and the thermal budget that decides how many control lines can enter a cold stage. Largely invisible in software discussions and a hard constraint on every roadmap.

The skills: physics and hardware engineering. This is the one role in the table that genuinely requires a physics degree.

Platform and DevOps. Queues, schedulers, APIs, billing, observability. Chapter 39 is entirely about the output of this work, and its central measurement — a job occupying the device for 6.92 ms with a utilization of $2.31\times10^{-5}$ — is a scheduling result, not a physics one.

The skills: ordinary cloud engineering. The quantum content: enough to know why a job cannot simply be preempted and resumed.

Applications research. The Part VI and VII work: taking a domain problem, mapping it to a quantum formulation, and measuring honestly against the classical incumbent. Chapters 36–38 are three worked examples, and all three concluded against the quantum method.

The skills: the domain first, quantum second. A chemist who learns quantum computing is more useful here than a quantum computing specialist who learns chemistry, because Chapter 36's binding constraint was an active-space decision that a computational chemist would have flagged immediately.

Algorithm theory. New algorithms, complexity separations, resource estimates. Small, mostly academic, and the source of nearly everything the other six roles implement.

The skills: mathematics. The reality: Shor's algorithm is from 1994 and Grover's from 1996, and the field is still implementing them.

⚠️ Common Pitfall: choosing the role with "quantum" hardest in the title.

The two roles with the most quantum content — algorithm theory and cryogenics — are the smallest and the most credential-gated. The five in between are largely classical engineering jobs where quantum literacy is a differentiator, and they are where the hiring is.

This is good news and it is consistently heard as bad news. A backend engineer who understands Chapter 39's queue arithmetic is immediately employable; a person who has memorized the Bloch sphere is not.

How to tell which one you would be good at

Three diagnostic questions, drawn from what each role actually rewards:

Did Chapter 39's queue arithmetic strike you as interesting or as a distraction? If interesting: platform engineering. The finding that a device is idle 99.998% of a job's lifetime is a systems problem with real headroom, and the people who find it boring will not fix it.

Did Chapter 28's optimization-level measurement — levels 2 and 3 differing in 14 of 40 circuit-seed pairs — make you want to look at the passes? If yes: compilers.

Did Chapter 25's error correction feel like the point of the whole book, or like a detour? If the point: decoders and fault tolerance. That reaction is uncommon and the field needs it.

And a fourth, which is about temperament rather than topic: how did you feel when Part VI ended with no quantum model beating a classical baseline? A person who found that clarifying rather than disappointing will do well in applications research, where the job is mostly establishing that things do not work and occasionally finding one that does.

40.2 The skills that transfer

Work backwards from what the previous 39 chapters actually asked of you.

Transfers immediately:

• Refusing to accept a number without its denominator, statistic, or sample size. This was the book's most repeated lesson and it is a general research skill.
• Reading a cost model. Chapter 39's 3,718× billing spread, Chapter 36's $10^{20}$ shots, Chapter 33's 27.8 QPU hours per million predictions — all of it is arithmetic over published parameters.
• Benchmarking against the method people actually use. Chapter 21 §21.7's lesson, and the single most valuable habit in this book.
• Classical software engineering. Testing, reproducibility, versioning, review. Chapter 39 §39.8 showed quantum computing is behind on this, not ahead.

Transfers with work:

• Linear algebra fluency, which is the actual mathematical content of the subject.
• Numerical statistics — variance, confidence intervals, hypothesis testing. Chapters 27, 28, 33, 34, 37, 38, and 39 each failed at this before succeeding.
• Compiler and scheduling theory, if you want the highest-demand roles.

Does not transfer, and is worth knowing:

• Deep circuit-identity manipulation. Useful and narrow.
• Any specific SDK's API. Chapter 31 opened with qiskit.pulse being removed in Qiskit 2.0, taking add_calibration, backend.defaults, and instruction_schedule_map with it. The API you learn will be deprecated; the reasoning will not.

The statistics gap, specifically

One item on the "transfers with work" list deserves separating out, because it is the single most common deficiency and the cheapest to fix.

Almost nobody arrives able to answer "is this difference real?" — including people with strong mathematics, because the question is not mathematical sophistication but a habit of applying an elementary formula every single time.

The formula is $\sigma = \sqrt{p(1-p)/N}$, and the habit is computing it before interpreting anything. What it buys, chapter by chapter:

• Chapter 27 — a tolerance below the shot-noise floor ($\approx 3/\sqrt{N}$) makes a test blind, not strict. Students and practitioners both tighten tolerances to make tests stricter, which is backwards.
• Chapter 28 — an optimization is not "better" until the difference exceeds the seed-to-seed spread. Levels 2 and 3 differ in 14 of 40 pairs.
• Chapter 33 — two gaps in the same experiment: $+0.0202 \pm 0.0170$ (not significant) and $+0.0626 \pm 0.0067$ (significant at nine standard errors). Nothing distinguishes them but the arithmetic.
• Chapter 38 — 37 test bits to exclude a fully compromised channel, 62,761 for a partial tapper. Both come out of a confidence interval.
• Chapter 39 — a 2.03× layout spread that is invisible at 4 qubits and decisive at 14.

Five chapters, one formula. A person who applies it automatically reads this book differently from one who does not, and the difference is larger than any amount of additional linear algebra would buy.

📐 Math Aside: the three numbers worth memorizing.

$\sigma \le 1/(2\sqrt{N})$. The worst-case standard error on a probability from $N$ shots. At 1,024 shots that is 0.0156, so anything within about 0.03 of your expectation is unremarkable.

$3/\sqrt{N}$. The approximate shot-noise floor on a total variation distance. At 1,000 shots, the measured max over 40 runs is 0.03700 (mean 0.01313) — and a distribution test with a tighter tolerance than that will fail on correct code.

$(\sigma/\epsilon)^2$. Shots needed for precision $\epsilon$ on an observable with spread $\sigma$. At chemical accuracy this is 97,657 per energy evaluation, and multiplying it by Chapter 36's term count and iteration count is where $1.91\times10^{20}$ comes from.

Those three cover essentially every cost argument in Parts IV through VII. They are also the entire statistical content of this book, which is worth saying to anyone put off by the word "statistics."

40.3 The scorecard

Assembled by harvest from the chapters themselves.

Where quantum methods were measured against classical baselines and lost:

   Ch.24  QAOA p=1 on MaxCut          0.8086   vs Goemans-Williamson  0.8785 (proven)
   Ch.32  VQC on iris-binary          1.0000   vs LogisticRegression  1.0000  (tie, 50.2 s)
   Ch.33  1-qubit data re-uploading   0.8343   vs kNN  0.8970   (-0.0626 ± 0.0067, 9 SE)
   Ch.34  quantum kernel              0.8313   vs SVC(rbf)  0.8889  (+0.0576, 7 SE)
   Ch.35  quantum-data classifier     0.6429   vs SVC(rbf)  0.7857
   Ch.37  QAOA p=3, 10 instances      0 wins   vs Goemans-Williamson  6 wins, 4 ties
          (GW's per-rounding success rate is 0.680; the 8/10 exact hits was a
           favourable draw, and distribution-vs-distribution GW wins 10 of 10)

Where the cost was priced and found prohibitive:

   Ch.15  one T gate                  450 physical qubits -> 2,882      (a 6.4x cliff)
   Ch.21  20-bit Grover search        229,944 T gates across 804 iterations
   Ch.33  inference                   27.8 QPU hours per million predictions
   Ch.36  VQE at the 50-orbital crossover   1.91e20 shots = 6.06e8 QPU-YEARS
   Ch.37  QAOA p=3, eps=0.01, 12 nodes      13,000,000 shots = 22 minutes vs GW's 8 ms
   Ch.39  Ch.36's VQE run                   $50, $7,432, or $185,542 for 31.2 seconds

Where the measurement itself was the finding:

   Ch.28  approximation_degree=0.9    ZERO two-qubit gates -- the "optimization" deleted the circuit
   Ch.30  same chip, quoted 2q error  0.00750 to 0.07205 -- a factor of 9.6
   Ch.31  dynamical decoupling        SIGNIFICANTLY WORSE: XX -0.0053 ± 0.0012
   Ch.32  gradient variance, 2->10 q  1.03e-01 -> 1.17e-03  (88x) -- barren plateaus, measured
   Ch.36  active-space error          9,870,104x larger than the VQE error it contained
   Ch.38  intercept-resend eavesdrop  QBER 0.2398 against a 1/2 x 1/2 = 0.25 prediction
   Ch.39  transpiler seed alone       fidelity 0.5755 to 0.7911 -- 2.03x the error

And where things genuinely worked:

   Ch.19  ancillas on an 8-bit oracle    26,978 T gates -> 55
   Ch.22  phase estimation, dyadic       exact, zero error
   Ch.23  Shor factoring 15 (a=7, t=8)   four outcomes at ~25% each, as predicted
   Ch.24  VQE on H2                      four parameters, chemical accuracy
   Ch.29  hardware-aware L1 (0.9116)     beats naive L3 (0.7720) by +0.1397
   Ch.35  classical shadows              win at equal total budget by 1.5-1.8x
   Ch.36  VQE inside its active space    2.04e-09 Ha from three parameters
   Ch.38  BB84                           works exactly as proven

📊 What the Numbers Say. Read those four blocks together. The techniques work. The physics is real. The engineering is impressive. And the comparisons lose — because the classical baseline is decades of optimization on hardware that costs nothing to run.

Both halves are true, and a person who can hold both is more useful to this field than one who believes either alone.

Reading the scorecard correctly

Four blocks of numbers invite four wrong conclusions. It is worth heading each one off.

Wrong conclusion 1: "quantum computing does not work."

Look at the fourth block. Ancillas cut an 8-bit oracle from 26,978 T gates to 55. Phase estimation is exact for dyadic phases — not approximately, exactly. Shor factored 15 producing exactly the four predicted outcomes at ~25% each. VQE reached chemical accuracy on H₂ from four parameters. Hardware-aware layout beat naive transpilation by +0.1397. BB84 works exactly as proven, and an eavesdropper leaves a 24% error rate she cannot avoid.

Every one of those is a real quantum effect doing real work. The physics is not in question.

Wrong conclusion 2: "the classical baselines were unfairly strong."

They were ordinary. kNN, SVC, LogisticRegression — three lines of scikit-learn, no tuning beyond defaults in most cases. Goemans–Williamson is from 1994. CCSD(T) is what a computational chemist runs on a laptop.

The baselines were strong because decades of engineering went into them and they run on hardware that costs nothing. That is not unfairness; it is the situation. A quantum method that beats a tuned classical baseline has done something; one that beats an untuned one has not, and Chapter 21 §21.7 is the general statement.

Wrong conclusion 3: "better hardware will change this."

For some entries, yes — every cost in the second block is a hardware-and-engineering problem, and Chapter 15's overhead numbers moved measurably with the 2023–24 below-threshold demonstrations.

For the head-to-head block, mostly no. Part VI's four comparisons ran on exact simulators with no noise, no shot limits, and no decoherence. Perfect hardware would not have changed a single number in that block. The limits measured were the input problem, kernel concentration, and dequantization — all properties of the methods.

And Chapter 37 §37.7's finding is stronger still: Goemans–Williamson returns a certificate and QAOA returns a bitstring. That is a difference in what the algorithms produce. A faster QAOA is a faster uncertified answer.

Wrong conclusion 4: "the negative results mean the field is a bubble."

The negative results are the field's most valuable output and they were produced by people trying to make the techniques work. Barren plateaus (McClean et al.), the input problem (Aaronson), kernel concentration, dequantization — none was published by a critic. A field that publishes its own negative results is functioning correctly, and Chapter 35's reading list is largely composed of them.

Compare the applications with the loudest commercial claims, which are also the ones this book measured most carefully and found furthest behind. The gap is not between quantum computing and reality; it is between the research literature and the marketing.

📊 What the Numbers Say: the scorecard is a snapshot with a date on it.

Every figure was measured against software and hardware available while this book was written — Qiskit 2.5.1, PennyLane 0.45.1, a 133-qubit heavy-hex device, and the classical libraries of the same moment.

Chapter 40 Exercise 40.35 asks you to re-read §40.3 in two years and note which entries changed. That list is the field's actual rate of progress, and it is the only honest way to measure it — better than any roadmap, because roadmaps are predictions and this is a measurement.

A prediction worth recording: the entries most likely to move are in the second block, the costs. Those are engineering. The head-to-head block will move only if something changes about the methods, and Part VI's obstacles are not the kind that yield to effort on hardware.

What a positive result would have to look like

Since the scorecard is empty in the quantum column, it is worth being precise about what would fill it — otherwise "no wins" degrades into an unfalsifiable position, which is the mirror of the hype.

A convincing demonstration needs all six:

1. A problem someone actually wants solved, not a benchmark chosen for tractability. Chapter 32's iris-binary tie fails here: three classical methods already reached 100%.
2. A tuned classical baseline, named, run by someone who wanted it to win.
3. Enough instances to have error bars. Chapter 37 measured ten; Chapter 33 measured ten splits. One is a draw from a distribution, and this book made that error seven times.
4. Equal resource accounting. Chapter 35's shadows comparison inverted when the budget was fixed properly.
5. The full cost, in shots, QPU-seconds, and dollars. Chapter 39's three prices span 3,718×.
6. A statement of what the method produces — a certificate, a bound, an error estimate — not just how it scored.

No result in this book's literature survey meets all six, in either direction. That is a statement about the field's reporting standards as much as about its results, and it is a fixable problem that does not require a single additional qubit.

40.4 How to read a quantum claim

The book's recurring lessons, as a checklist. Every one was learned by getting it wrong first.

1. Compared to what? Not to random, not to no algorithm, not to the method nobody uses. Chapter 21 §21.7; Chapter 36 §36.6 (CCSD(T), not full CI); Chapter 37 §37.5 (Goemans–Williamson, not greedy).

2. How many samples? This book published the error seven times:

Note that the last one is not about sample count — 24 seeds, wrong system. A measurement can be too small in more than one dimension.

3. What is the denominator? Chapter 37 §37.1: the same random assignment is 0.5 of the edges and 0.577 of the optimum.

4. Which statistic? Chapter 30 §30.5 refused to quote a fidelity without one, because the same chip supports 0.00750 and 0.07205.

5. What is the total error, not the method's error? Chapter 36's VQE was accurate to $2\times10^{-9}$ inside an approximation wrong by $2\times10^{-2}$.

6. What does it produce, not just how does it score? Chapter 37 §37.7: Goemans–Williamson returns a certificate and QAOA returns a bitstring. Chapter 38: QKD's guarantee is airtight and covers the component that was not the weak point.

7. Can the measurement detect the thing being claimed? Part V's refrain — six instances across Chapters 25, 26, 27, 29, 30, and 31, and in every case the blindness was a documented property of the method.

8. What did it cost? In shots, in QPU time, and in dollars — Chapter 39 showed those are three different questions with answers spanning 3,718×.

Working the checklist on a real claim

The eight questions are easier to state than to apply, so here is one worked end to end. The claim, of a kind you will see monthly:

"Our hybrid quantum-classical solver found solutions 1.6× better than the classical baseline on industry-scale portfolio optimization problems, running on 127 qubits."

Question 1 — compared to what? "The classical baseline" is unnamed. This is the load-bearing omission and it is almost always the first one. Portfolio optimization has commercial solvers with decades of tuning; if the comparison is against a greedy allocator, 1.6× is not evidence. vqelab.claims rejects "greedy", "random", and "unoptimized" outright, and Chapter 36 §36.6 added "full CI" to that list for the same reason — nobody runs it at scale.

Question 2 — how many samples? No instance count, no seed count. Chapter 37 §37.4 measured what one seed is worth: a $p=4$ result that appeared worse than $p=3$ and reversed in 7 of 8 seeds. A "1.6×" from one instance is a draw from a distribution nobody characterized.

Question 3 — what is the denominator? "1.6× better" at what. Better objective value? Lower risk? Faster? A ratio of objective values is not scale-free unless the objective has a natural zero, and portfolio objectives generally do not. Chapter 37 §37.1's version: the same MaxCut assignment is 0.5 of the edges and 0.577 of the optimum.

Question 4 — which statistic? Mean over instances, median, or best? Chapter 30 measured a single chip supporting quoted two-qubit errors from 0.00750 to 0.07205 — a factor of 9.6 — purely from the choice.

Question 5 — total error or method error? For an optimization result this reads as: is 1.6× measured against the true optimum, or against the relaxation, or against another heuristic? Chapter 36's version was a VQE error of $2\times10^{-9}$ inside an approximation wrong by $2\times10^{-2}$.

Question 6 — what does it produce? Does the solver return a bound? Chapter 37 §37.7 is the sharpest question on this list and the one almost never asked: Goemans–Williamson returns a certificate and QAOA returns a bitstring, and the incumbent solver in Case Study 37.1 was printing a 0.046% optimality gap every day that nobody had read.

Question 7 — can the measurement detect the thing? If the comparison is on instances the classical solver solves to optimality in seconds, no improvement is possible and 1.6× must be measuring something else.

Question 8 — what did it cost? Absent. Chapter 39 priced one computation at $50, $7,432, or $185,542 depending only on the billing model.

Verdict: unevaluable. Not refuted — unevaluable, which is a different and more precise thing to say. audit_claim returns failures rather than a refutation for exactly this reason, and "I cannot assess this claim, here are the six things that would let me" is a stronger professional position than either belief or dismissal.

⚠️ Common Pitfall: mistaking the checklist for a debunking tool.

The eight questions are not a device for proving quantum computing does not work. Run them on Chapter 19's ancilla result — 26,978 T gates to 55 — and it passes cleanly: named comparison, exact counts, unambiguous denominator, a stated cost, and a clearly-produced artefact.

Run them on Chapter 31's dynamical-decoupling result and it passes too, despite the finding being negative. The checklist does not care which direction the answer points. That is what makes it usable on your own work, which is the only place it really matters.

The failure modes the checklist does not catch

Worth stating, because a checklist that seems complete is more dangerous than one that admits its gaps.

Fabrication. Nothing here detects invented data. The eight questions assume good faith and check reasoning, not honesty.

Correct answers to the wrong question. Chapter 36's VQE error was correct, well-characterized, and answered a question nobody had asked. The claim passed every question except sample size and was still seven orders of magnitude away from the quantity that mattered. Question 5 catches this only if you already suspect the decomposition exists.

Selection effects across papers. A field where twenty groups try an approach and one publishes a positive result produces a literature of individually-defensible claims and a collectively-misleading picture. No per-claim checklist sees this; only the field's willingness to publish negative results does, which is Chapter 35's reading list's point and §40.6's last question.

Well-specified irrelevance. A result can pass all eight questions and still not matter, because the problem was chosen for tractability rather than importance. Chapter 32's iris-binary tie is the clean example: everything about the measurement was sound, and the dataset was already saturated by three classical methods.

40.5 Where the real problems are

Three areas where the case survives this book's own scrutiny.

1. Error correction. Chapter 15's measurement — 450 physical qubits for a circuit with zero T gates, 2,882 for one with a single T gate — is the whole story. Every algorithm with a proven exponential speedup needs fault tolerance, and fault tolerance is an engineering problem with a known shape and no fundamental obstruction. This is where the serious money and the serious people are, and correctly so.

2. Simulation of quantum systems. Feynman's original argument, and the one this book found hardest to dismiss. Chapter 36 narrowed the honest target to strongly-correlated systems where CCSD(T) breaks down — transition-metal catalysis, some excited states, bond-breaking. Narrow, real, and not reachable by VQE at the shot budgets measured.

3. Learning from quantum data. Chapter 35's surviving case. When the input is already a quantum state — from a sensor, an experiment, another quantum computer — Chapter 32's input problem disappears, and there are proven exponential separations for learning tasks.

And one honest negative: the applications with the loudest commercial claims — optimization, finance, near-term machine learning — are the ones this book measured most carefully and found furthest behind.

Why these three and not the others

The three areas above were not chosen by enthusiasm. Each survives a specific test that the popular applications fail, and it is worth making the test explicit.

The test: is the bottleneck a quantity that improves with engineering?

For error correction, yes, and measurably. Chapter 15's overhead — 450 physical qubits at zero T gates, 2,882 at one — is set by code distance and magic-state distillation, and both are engineering targets with known improvement paths. The 2023–24 below-threshold demonstrations moved the actual number. Nothing about the problem's shape says it cannot be solved; it is expensive, and expense responds to work.

For simulation of quantum systems, partly. Chapter 36 measured VQE's shot budget at $1.91\times10^{20}$ — 6.06 × 10⁸ QPU-years — which does not respond to engineering, because it is $1/\epsilon^2$ sampling against an $\mathcal{O}(n^4)$ term count. But the chapter also identified the route that survives the arithmetic: phase estimation on error-corrected hardware, where precision costs $\mathcal{O}(1/\epsilon)$ because it comes from circuit depth rather than sampling. That reduces to area one.

For learning from quantum data, yes, and for a different reason: the obstacle Chapter 32 identified — the input problem, $N - \log_2 N - 1$ gates to load $N$ classical values — does not exist when the data is already a quantum state. The bottleneck was removed by changing the problem rather than by improving the hardware.

Now apply the same test to the applications with the loudest commercial claims:

Near-term optimization. Chapter 37 measured QAOA losing 0–6 to a 1994 algorithm, and §37.7 identified the gap as what the algorithms produce — a certificate versus a bitstring. A faster QAOA is a faster uncertified answer. That gap does not close with better hardware, which fails the test.

Near-term machine learning. Chapter 32's input problem, Chapter 34's kernel concentration driven by feature dimension, and Chapter 35's dequantization results are all statements about the method, not the device. Part VI's scorecard — zero wins across four datasets — was measured on exact simulators with no noise at all. Better qubits would not have changed a single number in it.

Finance specifically. Every quantum finance proposal this book examined reduces to optimization or to sampling, and inherits the corresponding limitation. Chapter 39 §39.5 adds the part nobody prices: the same computation billed at $50 or $185,542 depending on the provider's counting.

🔬 Honest Assessment: the three surviving areas are the three with the longest timelines.

This is not a coincidence and it should be said plainly. Error correction, fault-tolerant chemistry, and quantum-data learning all survive scrutiny because their obstacles are engineering problems rather than structural ones — and engineering problems on this scale take a decade or more.

The applications available on a five-year horizon are the ones that failed the test.

That is an uncomfortable thing for a field that needs continuous funding, and it is the honest reading of forty chapters of measurement. A person who understands it is more useful than one who does not, including to the organizations doing the funding.

The fourth area, which this book does not endorse but should name

There is a candidate the three above leave out, and omitting it silently would be a kind of dishonesty: quantum simulation as a scientific instrument rather than as a computation.

The argument runs differently from the other three. It does not claim a speedup over classical methods on a well-posed problem. It claims that a programmable quantum system is a laboratory apparatus — that running a controlled Hamiltonian evolution on 50 qubits tells a physicist something about condensed-matter physics in the way a particle detector tells them something about particles, and that "is it faster than a classical simulation?" is the wrong question to ask an instrument.

Why it is not in §40.5's list: this book measures claims against baselines, and that framing does not produce a measurable claim. It may nonetheless be right, and several serious physicists hold it.

Why it is worth naming: because a reader who applies §40.4's eight questions to it will find that several do not apply, and should notice that this is a property of the claim's type rather than of its quality. A checklist built for comparative performance claims says nothing useful about an instrument.

The honest position: if you are drawn to this, the relevant literature is analog quantum simulation and quantum many-body physics, not the gate-model applications this book covers, and the career path runs through physics rather than through §40.1's engineering roles.

40.6 Telling a real opportunity from a well-funded one

Practical questions, all answerable before you take a job or sign a contract.

• What is the classical baseline, and who ran it? If nobody in the building can name it, that is the finding.
• What would falsify the thesis? A research programme with no failure condition is a marketing programme.
• Which of §40.1's roles is this actually? Most "quantum" jobs are excellent classical engineering jobs. That is good news — say so out loud and check that the description matches.
• How is progress measured? "Qubit count" is Chapter 30's mistake and Chapter 39's: capability is quoted in qubits, and Chapter 36 measured BeH₂ and H₂O at 14 qubits each differing by 420 Hamiltonian terms.
• Do they publish negative results? Chapter 35's reading list makes the point: the most valuable QML results — barren plateaus, the input problem, kernel concentration, dequantization — were all found by people trying to make it work and reporting that it did not.

Four questions to ask in an interview

These are diagnostic rather than adversarial, and each has a good answer as well as a bad one.

"What is your classical baseline, and who ran it?"

Good: a named solver, run by someone on the team, with numbers. Bad: "we're focused on the quantum side." Worst, and common: a baseline the team wrote themselves in an afternoon.

Case Study 37.1's analyst won an entire evaluation with the equivalent question, and the answer was sitting in a solver log nobody had read — a 0.046% optimality gap printed every day.

"What result would tell you this approach is not going to work?"

Good: a specific, measurable threshold with a date. Bad: anything that cannot come out negative. §40.6's formulation is that a research programme without a failure condition is a marketing programme, and this question tests it directly.

"How do you decide how many shots to use?"

Sounds technical and is a culture question. Good: derived from a target precision and a variance — Chapter 24 §24.3's $1/\epsilon^2$. Bad: "we use 1,024." A team that has never computed its own shot budget has never priced its own experiments, and Chapter 39 §39.5 showed what that costs.

"What is the most interesting negative result your team has produced?"

Good: an immediate specific answer. Bad: a pause. A team that has produced no negative results in a field where Part VI's entire literature is negative results has either been extraordinarily lucky or is not reporting them.

🔬 Honest Assessment: you are also being evaluated on which questions you ask.

Asking the four above signals that you can distinguish a research programme from a marketing one, and that is the scarce skill — Chapter 40 §40.1's five largest employment categories are all classical engineering, and the differentiator between candidates is quantum judgement rather than quantum knowledge.

A candidate who asks about the baseline is telling the interviewer they have read the literature the way §40.4 recommends. A candidate who asks how many qubits the device has is telling them something else — Chapter 36 measured BeH₂ and H₂O at 14 qubits each and 420 Hamiltonian terms apart.

The three-year and ten-year versions of the same choice

On a three-year horizon, the compiler, platform, and control-software roles are the safe ones. They produce transferable classical engineering skill, the work is needed whether or not any particular quantum thesis succeeds, and Chapter 39's measurements show substantial unclaimed headroom in all three.

On a ten-year horizon, the calculation changes. If fault tolerance arrives, decoder engineering and fault-tolerant algorithm design become the centre of the field, and the people who spent the intervening decade on them will be the only ones qualified. If it does not arrive, that decade produced real-time systems engineering and coding theory, which are not wasted.

The asymmetry worth noticing: the near-term applications roles — near-term optimization, near-term QML, quantum finance — are the ones where a thesis failure and a career are correlated. Case Study 40.1 is exactly this analysis, run by an engineer with three offers, and the conclusion was not that the risky option was wrong. It was that the risk should be taken knowingly, and a greedy baseline guarantees it is not.

40.7 What this book was actually teaching

The quantum content is real and it is not the point.

Every chapter ran the same loop: make a claim, measure it, and let the measurement win. That loop produced the T-gate cliff, the dynamical decoupling that made things worse, the optimization level that deleted the circuit, the active space that dominated the result, the certificate QAOA does not produce, and the seven separate occasions when this book's own author read a number off too small a sample and had to correct it in print.

None of those are quantum lessons. They are what it looks like to do technical work honestly in a field where the incentives point the other way — and quantum computing is an unusually good place to practise, because the hype is loud, the measurements are cheap, and the gap between them is wide enough to see.

If you take one thing from forty chapters: the number that is easy to get is not the number that answers the question, and the easy number is almost always the flattering one. That is not a coincidence. The flattering number is the one that stops the search.

The seven errors, as a single pattern

The book made the same statistical error seven times. Listing them is §40.4's job; the more useful exercise is asking why a person who knows better keeps doing it.

In every case, three things were true at once:

The cheap measurement was available and the expensive one was not. Two hundred runs instead of two thousand; two circuits instead of forty; one split instead of ten; one seed instead of eight. The correct measurement always cost roughly an order of magnitude more and was always affordable in hindsight.

The result was plausible. None of the seven produced an absurd number. A 1.0% flakiness rate is a reasonable-sounding rate. "Optimization levels 2 and 3 are identical" is a reasonable-sounding finding. $p=4$ performing worse than $p=3$ has a mechanism — barren plateaus — ready to explain it.

There was a story. This is the dangerous one. In each case the wrong number arrived attached to an explanation that made it feel understood rather than measured. Chapter 37's $p=4$ regression came with a plausible account of optimization landscapes degrading with depth, and the story was partly true — variance really does grow with $p$ — which is precisely what made the wrong conclusion survive.

Plausibility plus a story is what lets a bad measurement live. A surprising result gets checked. A result that confirms what you expected does not, and the seven errors are all in the second category.

What broke the pattern varied, and the variation is instructive:

Chapter 37's is the strongest and the most transferable. Every other row is a habit — re-run things, widen samples, be suspicious. Those are good habits and they are unreliable, because they compete with finite time and a plausible-looking number gives you no reason to spend it.

A structural argument is different in kind. $p=4 \supseteq p=3$ is available before any measurement, it names which specific number must be wrong, and it converts a vague unease into a definite claim. Chapter 25's impossible result works the same way — nothing about 0.0000 at $p = 0.60$ needs a statistical argument to be wrong.

⚠️ Common Pitfall: trusting a plausible result more than an impossible one.

The instinct runs backwards, and it costs time. An impossible result is a gift: it announces itself, and Chapter 25's took an afternoon to trace to optimization_level removing the id gates that were injecting the noise.

A merely-wrong result announces nothing. Chapter 27's 1.0% flakiness rate sat in a draft looking entirely reasonable, and it was off by a factor of 6.7.

Before reporting that more resources made something worse, check whether the larger configuration contains the smaller one. If it does, you are measuring your optimizer, not your method — and you now know exactly which number to re-run.

40.8 Where to go next

If you want to build the field: learn compilers, real-time systems, or decoding. Chapter 39 §39.3's utilization arithmetic and Chapter 15's overhead numbers are both engineering problems, and both are underserved.

If you want to use it: pick a domain you already know and learn enough quantum to price the claims honestly. Chapters 36–39 are the template — the valuable person is the one who can say why a proposal does not work, in the proposal's own units.

If you want to research it: the negative results are the contribution. Chapters 32–35 are a literature built almost entirely of people reporting that the thing did not work, and the field is better for every one of them.

And if you want to know whether any of this will matter: nobody does. What you can do — what forty chapters of measurement equip you to do — is tell the difference between a claim that has been checked and one that has not.

That skill outlasts every SDK in this book.

A last word on the discomfort

If you have read forty chapters and come away unsettled, that is the correct response and it is worth naming rather than resolving.

The field is simultaneously real — the physics works, the engineering is impressive, the open problems are genuine and well-defined — and oversold, by a margin this book measured repeatedly and in detail. Both facts are true at once, and most available positions require ignoring one of them.

People who ignore the first become the sort of critic who is reliably right about the present and learns nothing, because they stopped looking. People who ignore the second spend a decade on a thesis whose failure condition was never specified — and Case Study 40.1's engineer declined an offer for exactly that reason, while saying plainly that the team might be right.

Holding both is uncomfortable and it is what the evidence supports. It is also what makes someone useful. An organization deciding whether to fund quantum computing needs a person who can say "this proposal fails on the baseline and the shot budget; this other one is on the critical path and underfunded." Neither the enthusiast nor the sceptic can produce that sentence.

Forty chapters, 503 tests, seven errors corrected in print, and one habit worth keeping: make the claim, run the measurement, and let the measurement win.

A reading list for the next two years

Not sources — Chapter 40's further-reading.md has those. Habits, in the order they pay off.

Re-run one measurement from this book on hardware you have access to. Any of them. The number will differ, and diagnosing why is worth more than the next three papers you read. Chapter 39 §39.8 lists the nine fields to record.

Pick a claim a month and audit it. Ten minutes with vqelab.claims and Chapter 40 §40.4's eight questions. After a year you will read press releases the way §40.4's worked example reads them, which is quickly and without effort.

Run the classical baseline yourself, once, on something that matters to you. Install Gurobi or PySCF or scikit-learn and find out what the incumbent actually does. This is the single highest-value hour available, because Chapter 21 §21.7's error is committed almost entirely by people who have never run the thing they are comparing against.

Follow the people publishing negative results. Barren plateaus, dequantization, kernel concentration, the detector-blinding attacks on commercial QKD — the authors of those papers are the ones whose next result will change what you believe.

Watch the below-threshold error-correction numbers. Chapter 15's overhead is the quantity that gates everything in §40.5, and it is currently the only headline figure in the field that is moving for real reasons.

What this book will get wrong

Every technical book is wrong about something, and it is more useful to predict where than to pretend otherwise.

The API details will rot fastest. qiskit.pulse was removed in Qiskit 2.0 during this book's writing, taking add_calibration, backend.defaults, and instruction_schedule_map with it. Appendix C's version table is a snapshot. Assume anything with a version number attached has changed.

The prices will move. Chapter 39's $50 / $7,432 / $185,542 are published list rates with an as_of date, and PriceBook requires that date for exactly this reason. The structure — per-shot versus per-minute versus credits, and the fact that they cannot be compared without a circuit duration — will outlast the numbers.

Some scorecard entries will flip. §40.3 is a snapshot, and the honest expectation is that the cost block moves and the head-to-head block does not. If the head-to-head block moves, that is the interesting outcome and it is what Exercise 40.35 is for.

At least one measurement here is wrong. Seven were caught and corrected in print. The base rate does not suddenly go to zero at the end of a book, and Case Study 40.2 found two of four headline claims failing the book's own checklist on re-audit.

What should outlast all of it: the eight questions, the three formulas, and the habit of letting the measurement win. Those are not about quantum computing, which is why they will still be true when the SDK in Appendix A has been replaced twice.

What we measured, across forty chapters

• 280 chapter files, 264 Python files (41,427 lines), 503 checkpoint tests — every example executed
• Six head-to-head comparisons against tuned classical baselines: zero quantum wins. One exact tie (Ch.32, on a problem logistic regression already solves perfectly), four classical wins, and Ch.37's ten MaxCut instances at 0–6 with 4 ties
• Costs priced from $50 to $185,542 for the same 31.2 seconds of quantum processor time
• Seven published instances of a too-small measurement, corrected in print, in this book
• ★★ The techniques work, the physics is real, and the comparisons lose — and both halves have to be held at once

This is the end of the book. Fourteen appendices follow, and three of them are worth knowing about rather than merely having:

Appendix I lists all 29 vqelab modules alongside what each one refuses to do. That column is the real index to this book — every entry is a refusal a chapter earned by measuring something, and in seven cases by getting it wrong first.

Appendix G collects the hardware numbers in one place: gate durations, the calibration spreads, the 240 km QKD wall, and the three pricing structures. It is the reference you will actually reach for.

Appendix J is a timeline, and its last row is the one to sit with — qubit counts rose by an order of magnitude during this book's writing, and not one of §40.3's six head-to-head comparisons changed hands. Width was never the binding constraint.

The glossary, bibliography, and index were generated from the chapter files rather than written from memory, for the reason §40.4 gives: a summary written from recall produces numbers that are plausible and wrong.