57. What AI Will Automate
57.1Boilerplate Quantum Code
Already automated in practice: the ceremony code — imports, register setup, standard circuit constructions, transpile-and-run harnesses, result parsing, histogram plotting. If a task appears in three of your past scripts, a model now writes the fourth unprompted. What this removes is not employment but friction — the cost of trying an idea dropped from an afternoon to minutes, which (second-order effect) raises the value of having ideas worth trying (Ch. 58's theme arriving early). What it does not remove: correctness ownership. Generated boilerplate still fails on API drift, subtle register mismatches, and version pinning — and the engineer who cannot read the boilerplate fluently cannot ship it responsibly. The line: generation is automated; accountability is not.
57.2Standard Circuit Construction
The specific, high-frequency case: textbook circuits — Bell, GHZ, QFT, adders, oracle constructions, ansatz families — are now one-prompt artifacts, and reference implementations from libraries (Qiskit's circuit library) cover the same ground with guarantees. Automated well, with the caveat that "standard" hides choices: which QFT variant (with or without swaps, approximation order), which adder (ripple-carry, Cuccaro, Draper — Part XII's tradeoffs), which ansatz initialization. The engineer's remaining job is exactly the choice: knowing that the standard object has variants and which one the experiment needs (Ch. 54.3's control discipline applies to library picks too). Skills displaced: writing them from memory. Skills promoted: specifying them precisely — a spec-first habit this book has been drilling since Ch. 17.10's parser.
57.3Documentation
Substantially automatable now: docstrings from code, README scaffolds, tutorial drafts from notebooks, API-reference prose. Quality is genuinely decent because documentation rewards exactly what models do well (fluent restatement of visible structure). The human remainder: the why — design rationale, the constraint that forced a weird choice, the "do not do this" warnings — which lives in the reasoning Ch. 52.10 classifies as judgment, not implementation. For your research repos, the pattern that works: AI drafts the reference layer, you write the deviations-and-decisions sections (Ch. 53.7's ledger!) yourself — those sections are the transferable knowledge, and outsourcing them outsources your differentiation. Documentation of failures especially: no model knows what you tried and why it failed; that ledger is authorship.
57.4Routine Optimization
Automatable: the mechanical optimization passes — gate cancellation, rotation merging, obvious peephole rules (Part XII's 46.4 class) — models can write, and classical tools already do better. Also automatable in practice: hyperparameter search for variational algorithms (optimizer settings, learning rates — Ch. 49.7's grid searches), benchmark generation harnesses, and standard transpiler configuration tuning. Not yet automatable: the strategic optimization decisions — which cost function reflects the real objective (Ch. 45.10's honest-metric problem), when a 20% gate-count win is worth a fidelity cliff, what the noise model is missing. The boundary is stable and instructive: routine optimization is local and verifiable (automatable); good optimization is knowing what to verify (human). Design your work to specify the first and own the second.
57.5Simple Proofs
The live frontier, moving fast. Automatable today: routine identities (Pauli commutation checks, small-circuit equivalences, Euler-angle manipulations) — verifiable by machine anyway (Ch. 46.4's Operator checks), so automation is safe and total. Substantially assisted: proof search in well-explored theory neighborhoods — Lean/Coq formalization with AI tactics has produced verified results in adjacent mathematics; quantum-relevant formal methods are young but real (verifiable compilation, Ch. 46's research seam). Not automatable: proofs requiring new ideas — and the taste to know which lemma is worth proving. Your positioning: treat formal verification tooling as a coming standard (learn Lean's basics if theory pulls you — the fault-tolerant era's correctness demands it, Ch. 46's research box), and keep your Ch. 56.2 verification discipline absolute: a proof you can't sketch wasn't verified, it was narrated.
57.6Experiment Setup
Automatable: the scaffold — config generation, sweep loops, seeds, logging (Ch. 54.10's tracking), figure code — Ch. 56.5's territory, already practical. Becoming automatable: experiment selection within a fixed frame ("run these five configurations next, given the results so far" — AutoML-style loops applied to quantum benchmarks work at toy scale). The durable human core: the Ch. 54.1 hypothesis and its pre-registration — deciding what question deserves the compute, what result would change your mind, and what would be a waste. That is design, not setup, and it is the difference between an automated pipeline producing knowledge and producing plots. Structural consequence: one engineer with judgment plus automation runs the experimental throughput of a small group a decade ago — leverage that makes judgment scarce and hands abundant.
57.7Benchmark Generation
Automatable: generating benchmark instances — random circuits with specified structure, scaled versions of standard families, noise-model grids (QASMBench-style corpora plus task-specific generation). Also automatable: the statistical harness — error bars, seed distributions, comparison tests per Ch. 46.8's protocol. The human remainder is the hard half: benchmark validity — which circuits actually represent the workload that matters, which metric resists gaming (Ch. 45.10's compilers-game-metrics law applies to benchmarks themselves), and whether the comparison is honest (Ch. 50.8's equal-compute-budget rule). The field's own benchmark crisis — quantum volume, clops, XEB each gamed or superseded within years — is the cautionary dataset. Automatable generation plus human validity judgment is the stable division; be the side that can tell the difference.
57.8Routine Literature Analysis
Automatable: the triage layer — scanning new arXiv listings for relevance, extracting claims matrices (Ch. 55.2) from papers, maintaining your reading log's index, drafting Ch. 52.2's abstract translations for your review. This is hours per week reclaimed, and it is safe because you verify the load-bearing parts (citations, the claims you rely on). Not automatable without losing the point: the deep read that builds your comprehension (Ch. 52's three passes), the taste formation that comes from struggling with a hard paper, and the synthesis — noticing that paper A's method breaks under paper B's noise model, which requires both papers in your head, not in a context window. Rule of thumb: AI reads for you; you read into yourself. The second is slower and is the entire point of Ch. XIV.