Keeping a quantum computer running still takes a lot of people. Calibration scripts handle the routine drift, but someone has to decide when routine isn't enough, which experiments get the machine this afternoon, and whether last night's jump in error rates came from the fridge, the control electronics, or a software change. That's workable for a machine in a lab. It won't work for a utility-scale quantum computer, and quantum computers aren't the only machines headed for this problem.
Autonomous labs, advanced chip fabs, and large robot installations are built the same way, as heterogeneous piles of subsystems tied together by feedback loops. In a quantum computer the pile includes chips, control electronics, cryogenics, networking, compilers, decoders, schedulers, and the people running all of it. Past a certain size and degree of coupling, people can't be the ones closing those loops anymore. They move up a level, to setting goals and approving policy, and something else has to do the operating. I think that something will be advanced AI, built into the machine as part of its control plane, and after enough years around quantum hardware, control stacks, and AI-driven scientific workflows, I don't see a realistic alternative.
What changes with scale
The public roadmaps already describe machines like this. IBM's plan for fault tolerance is modular, with multiple quantum processors linked in a data center and decoding done in real time, on the way to 200 logical qubits running 100 million gates by 2029.1 Google's Willow results get at the same thing from the error-correction side: useful applications will need billions of reliable operations, possibly trillions, and the latest error-correction results already depend on classical software built around machine learning, reinforcement learning, graph-based decoding, and real-time processing of measurements.2 Photonic roadmaps push the infrastructure further still, with foundry-scale wafer production, cryogenic cabinets designed to support hundreds of chips, and dedicated facilities for characterization and calibration.3 At that scale I'd count those facilities as part of the machine.
In all three plans, hitting a fidelity or throughput target on a single component is increasingly within reach. The harder job is keeping the whole machine inside a workable operating envelope as the hardware drifts, workloads change, and parts fail in correlated ways. That control problem cuts across layers of the stack that used to belong to separate disciplines.
I run into this constantly in my own work. Architecture, photonic design, calibration, error correction, compilation, and day-to-day operations keep collapsing into one optimization problem, because the machine doesn't respect the boundaries we draw between teams. A change to the device design changes how much calibration it needs. If the decoder gets slower, the depth of circuit you can usefully run goes down. A new scheduling policy reshapes the error budget. Tools built separately for each layer can't see those trade-offs.
Past a certain size and degree of coupling, people can't be the ones closing those loops anymore.
Where fixed automation runs out
We already automate the narrow loops, and we do it well. FPGAs, control firmware, recipe engines, advanced process control, and a lot of carefully tuned heuristics are what keep these machines alive today, and the lowest levels of control should stay as deterministic, testable, and boring as we can make them. The trouble is higher up. Fixed automation copes badly with systems that are high-dimensional, partially observed, changing over time, and safety-constrained, which describes every machine on my list. Hand-written rules hold until the machine reaches an operating point nobody wrote a rule for, or two subsystems interact in a way nobody thought to encode.
An AI layer can work above and across those loops. It can read many kinds of telemetry at once, learn surrogate models where first-principles simulation is too slow to run online, infer hidden state from messy measurements, rank possible interventions by expected value, and plan under uncertainty. In a quantum computer that means deciding what to recalibrate and when, routing work around a subsystem that's starting to drift, trading decoder latency against logical fidelity, and turning what applications ask for into live resource allocations. A fab needs the same kind of judgment to catch process excursions earlier across thousands of interacting variables, and a robot fleet needs it to coordinate planning and task allocation and to recover from failures without burying its operators in exceptions.
Early versions
Berkeley Lab built its A-Lab as a closed-loop system for discovering materials. The lab says it runs around the clock, handles 100 to 200 samples a day, and gets through on the order of 50 to 100 times as much work as a person could.4 The Nature paper describing it reported 41 new compounds made from 58 targets in 17 days of continuous operation.5 In chip manufacturing, Applied Materials describes platforms that take millions of measurements across wafers and individual chips and tune thousands of process variables in real time, from research through high-volume production.6
In both cases, how well the system performs depends as much on the orchestration and inference wrapped around the instruments as on the instruments themselves. The software decides which operating regimes the machine can reach, so I count it as part of the machine.
What the AI layer looks like
When I say advanced AI, I mean models that can read time series, logs, images, layouts, text, and simulator output together; agents that can propose actions and evaluate them; and a policy engine that checks hard constraints before anything reaches the hardware. In the design I have in mind, hard real-time control stays classical and safety interlocks stay explicit. The AI takes the slower work above them: orchestration, diagnosis, forecasting, searching design spaces, and making trade-offs between layers.
Some of that classical control can be learned. A lot of my work has been on neural decoders, which are trained networks, but by the time one runs on an FPGA or an ASIC its weights are frozen and it runs deterministically, like any other firmware. What stays out of the fast path is anything that learns or plans while the machine is running.
Where the AI layer sits
Adaptivelearns and plans, can be wrong
Fixeddeterministic, tested, boring on purpose
Only actions go through the policy check; telemetry goes straight back to the AI layer.
This only works if the AI layer is engineered like critical infrastructure. Every action should leave a record of what the system saw and why it acted, and the actions it's allowed to take at all should be on an explicit whitelist. Changes get tested against a simulator before they touch the machine, and any of them can be rolled back. The models need calibrated uncertainty and a defined way to hand a decision to a person when they're unsure, and the whole layer has to be benchmarked continuously against simple baselines, because a sophisticated controller that loses to a threshold rule isn't worth running. People still set the goals, define the invariants, approve the policy, and answer for the results, but asking them to be the real-time operating system for scientific infrastructure with a million components is pure nostalgia.
The same models are already useful before the machine exists. Architecture search, photonic inverse design, decoder search, compiler co-optimization, experiment planning, and resource estimation are all searches through enormous design spaces under hard physical constraints, and operating the machine is the same kind of problem. I expect the tools for designing these machines and the tools for running them to merge.
Building for it
Today AI mostly shows up in these machines as an optional accelerator for the decoder, the compiler, the lab notebook, or the operations dashboard. If we want machines like these working within the next decade, we should design it into the control plane from the start, the way we design the cryogenics and the control electronics. In practice that means instrumenting every subsystem so there's data to learn from, building simulators and digital twins alongside the hardware, exposing clean interfaces for operating each subsystem, and putting a policy engine between what people intend and what the machine does.
In experimental science the intelligence has mostly sat outside the machine, with the scientists, operators, and on-call engineers who run it. The machines being built now are too large and too tightly coupled for that, so they need an adaptive layer between the people and the hardware, and in practice that layer will be AI. For a utility-scale quantum computer especially, it will matter as much as the qubits themselves.