AI coding agents have become quite good at generating code, and their use in complex, real-world repositories is increasingly common. At QuEra, we have been looking to adopt this workflow. But we work in a young, fast-moving industry where precision is not optional. So the question we had to answer was not whether to use AI, but how to lean on it without lowering our standard.

This post walks through how we answer that question: the guardrails we've built, the principles behind them, and what changed once we wrote them down.

Context Before Access

At QuEra, the real question about AI is not whether an agent can write code. It can. The real question is what should happen before it touches a codebase that controls neutral-atom quantum computers.

We treat an AI agent the way we treat a strong engineer joining our team. The issue is never talent; it is proper onboarding and context. A new engineer gets context, ownership boundaries, test expectations, review gates, and a clear rule for when to stop and ask. Gaining trust and responsibility over a codebase such as our own takes more than the ability to write good code, and merge access is a privilege everyone grows into. We are building the same structure for agents.

A neutral-atom quantum computer is a lot of machinery pointed at a very small target. We hold atoms in an ultra-high vacuum chamber and cool them to a few microkelvin. Focused laser beams act as optical tweezers, trapping individual atoms and arranging them into arrays. Acousto-optic and electro-optic modulators shape and switch the light, and more lasers drive the gates. Underneath sits a control stack of FPGAs and DACs sequencing pulses with sub-nanosecond timing, calibration routines that keep laser power and frequency aligned, and error-correction software on top. The success of our systems depends on every element in the stack behaving the same way, over and over, millions and billions of times.

Holding that consistency together is code, and lots of it. It reaches from hardware-adjacent firmware, through message schemas and serialization formats, calibration flows, C++ and Python services, up to the operator workflows people rely on during a run. A bug in the wrong layer of code does not just fail a unit test. It can shift how an experiment behaves on real atoms, and the failure may not surface until the run comes back wrong.

That environment rewards discipline and punishes plausible improvisation. An agent can be excellent at pattern-matching across a repo and still rewrite a calibration path with total confidence, ignorant of its fragility or significance. It sees a message schema or a timing assumption and treats it like ordinary software. It is not ordinary software. The risk is not that the agent is malicious; it is that the change looks reasonable and was never checked against the real constraints of the system. Plausible-but-unverified is the dangerous category. And it is exactly what you want to keep away from delicate components.

So the question is not "can AI write quantum control code?" It is "how do we let AI help while keeping the engineering process tight?"

Our answer is to keep the guidance in the repository, next to the code it governs. Not on a wiki page nobody opens during a busy week, and not in the head of the one person who remembers how a subsystem really works. A root guidance file sets the broad policy: which code is sensitive and who owns it, how secrets are handled, what requires human approval, what network access an agent can assume, which commands validate a change, and what evidence a pull request has to carry. Directories closer to the hardware, or to the fragile subsystems, tighten those rules for their own corner of the tree. Editing a README and touching a serialization schema are not the same operation, and the repository makes that difference explicit. An agent working deep in the schema code sees stricter constraints automatically, without anyone remembering to mention them. We also give agents reusable playbooks for the workflows we repeat: implementing from a ticket checklist, writing a requirements doc, keeping the guidance files current, running the safety harness, and preparing review evidence. The process belongs to the team that argued it out, not to whatever the model invents on the spot.

Two Principles do Most of the Work

Evidence means the agent shows what it did. A pull request is not finished because the diff looks plausible. It is finished when the agent can say which commands ran, what passed, what failed, what went unchecked, and which lines are the agent's work versus a person's. Small work items, targeted tests, clean commits, and a final quality gate before a human opens the diff are not AI-specific ideas. They are ordinary engineering practice, written down.

Restraint means some actions are simply not available without a human in the loop. No direct pushes to protected branches. No bypassing the hooks. No casual handling of secrets. No trusting an external ticket, a web page, or a pasted prompt just because it arrived with the request. And extra caution around anything close to the hardware. The agent can help; it does not get an exemption from the process.

The right guardrails turn out to be ordinary. They look like good engineering discipline written down and made hard to skip. Writing them down was useful on its own. When we reviewed the first version of the harness, the feedback was not about abstract AI policy, it was about specifics. Test markers had to match how the tests actually run. Serialization schema locations had to be correct. A reference to a file that lived on only one machine had to go. Requirement labels had to be standardized so we could trace them. Existing safety wording had to be preserved exactly. Vague rules produce vague behavior, whether the reader is a person or a model. The verification itself was dull, which was the point. Harness checks passed. No scratch files leaked into the commit. Static analysis found nothing new. One test failed, then failed the same way on main: the change had not caused it. We were happy to be bored.

In the end, we do not make AI safe for quantum engineers by trusting it more, and we do not make it useful by trusting it less. We make it useful by giving it context, boundaries, review gates, and a paper trail. And safe by requiring evidence before the work is accepted. For us, teaching agents the house rules is not a side project. If an AI helper is going to work near a demanding system, it needs to know where it is, what it may touch, what it must prove, and when to stop. That is not glamorous infrastructure. It is the infrastructure that lets us lean on AI without lowering the standard.