AI agents write, test and review much of our code. One of our products will soon draft orders from emails with AI. So the obvious question is fair: where are the people?
The short answer: wherever a mistake would be expensive, hard to undo, or about someone else’s money or data. This post lists those places exactly, because “a human is in the loop” means nothing until you say where the loop is.
What we do not claim
We do not claim that a person reads every line of code. That would be slow, and it would also be a little dishonest, because a tired person skimming a long diff is not much of a check.
Instead, every change goes through checks that do not get tired: tests written before the code, a green build, an independent review whose findings are verified. People sit at the points where judgment matters more than thoroughness.
Where a person decides in our engineering
Anything uncertain at the merge gate
A change merges on its own only when every rule holds: review approved, every verified finding fixed, the build green on the latest code, and nothing in the change that could break the running environment. If any of those is unsure, the agent opens the pull request, asks a person, and moves on to something else.
“Unsure” is meant to trigger often. A false alarm costs a person a few minutes. A wrong merge can cost a customer a day.
Credentials and access
Agents never handle passwords or keys, never approve access for a person or an application, and never sign in to vendor consoles. People do that, every time.
Money
Agents do not change billing, top up credit, or create paid cloud resources. Test runs that cost money have a budget stated before they start, and going over it needs a person’s sign-off.
Destructive steps
Cleaning up temporary environments, test databases and test accounts runs only when a safety check passes. Anything that would delete something not clearly temporary is asked about first.
What gets built
Agents can draft designs and point out options. Deciding what a customer actually needs, and in what order, stays with people who have talked to that customer.
Where a person decides in our products
The same rule applies to AI inside the software we sell.
UTX Freight’s email-to-order feature, coming soon, reads order emails and their attachments and drafts orders. It does not create them. A dispatcher sees the email and the document beside the draft, with missing fields highlighted, and approves each order, one at a time or in a batch.
Before a draft can even be approved, a check holds it back if the customer contact is missing, the container or reference is missing or already exists, or the job type is unclear. When the system cannot match a terminal or a customer with confidence, it leaves the field empty. A blank field is a small cost. A confidently wrong one is a truck at the wrong terminal.
Our planned features follow the same pattern: replies to customer questions drafted for a person to edit and send, and technician notes cleaned up for a person to accept, edit or discard. Nothing sends or saves on its own.
Why we draw the lines here
AI tools make a particular kind of mistake. They are rarely obviously wrong. They are wrong in a way that sounds right. That kind of mistake slips past a quick look, so the answer is not “look at everything”. It is to put hard checks everywhere, and people where judgment and accountability matter.
There is also a simpler reason. When something goes wrong with a customer’s data or money, the customer should be able to talk to the person who made the call. Keeping those calls with people keeps that promise true.
The cost
This is slower than letting the machines decide everything. Some changes wait for an answer. Some drafts wait for a dispatcher. We think that is the right trade, and we would rather say so plainly than pretend the loop is free.
If you are setting rules like these for your own team, our How we work page has the short version, and we are happy to talk through the long one.