On this page
A lot of the engineering work on ComputeSphere is now done by AI agents. They write code, open pull requests, review each other’s changes, run checks and carry work all the way through to production, and they do it every day rather than as a demo.
When I tell people this, they usually ask one of two questions. Some want to know whether it’s reckless, and others want to know how they can do the same. The answer to both is the same, because the agents aren’t what makes it safe. The system around them is.
What follows is how that system works, described at the level of principles. None of it is exotic. Most of it is what good engineering teams already do with people, and the difference is that we stopped treating any of it as optional.
1.Nothing merges on its author’s word
An agent that writes a change never approves it. Every change is reviewed by independent agents that didn’t write it and don’t share its context, and a change needs more than one approval before it can merge.
That independence is the whole point. A reviewer that has seen the author’s reasoning tends to agree with it, while a reviewer that sees only the change has to judge it on its own merits. The reviewers aren’t rubber stamps, either. They reject changes, ask for fixes and review again after every update. An approval also counts only for the exact version of the change it was given for, so if someone pushes a new commit, the earlier approval no longer applies.
The merge itself goes through a guard that checks all of this mechanically. It confirms the approvals, the tests and that the change is up to date with everything else, and if any condition fails, the merge is refused. Nobody, agent or human, gets to argue with it in the moment.
2.A separate go for production, and a person for what matters most
Agents can do a great deal of work before anything reaches production, but they can’t cross that line on their own say-so. Every production change waits for an explicit go from someone other than the agent that made it.
Most of those decisions come from a separate coordinating agent. It didn’t write the change, and before it approves anything it reads exactly what will change, in what order, and how we will know it worked. The bigger calls come to me. I decide anything customer-facing, anything that spends money, anything with legal weight and anything that destroys data, and agents don’t make those calls however confident they are.
That split is deliberate. Putting a person on every routine change sounds safer, but in practice it turns approval into a rubber stamp. Saving human judgment for the decisions that genuinely need it keeps that judgment sharp.
We also learned to be strict about what counts as a go. An instruction like “go once the tests pass” is a condition, not a go. The agent reports that the tests passed and then waits for a separate, explicit go that names exactly what is being approved. It can sound pedantic, but it closed a real gap, because conditional approvals are easy to read as permission one step too early.
3.One change at a time
When several changes touch the same sensitive area at once, it becomes hard to say which of them caused a problem. So for anything that can conflict, such as database changes, shared configuration or deployments to the same service, changes go one at a time and in an agreed order. Whoever is making a change announces it, everyone else waits, and the all-clear is announced as well.
It is slower in the moment and much faster overall, because when something does go wrong there is exactly one suspect.
4.Every action is recorded
Every change, review, approval and message between agents is recorded with who did it and when, along with each agent’s working log. When a reviewer approves a change, the approval is posted where everyone can see it and tied to the exact version it covers.
This isn’t surveillance for its own sake. It is what makes an honest investigation possible. When something surprising happens, the first question is always what we did just before it, and the record answers that in minutes instead of leaving us to guess for hours.
5.Untrusted input never becomes instructions
This is the principle I think matters most, and it is the one most people building with agents underestimate.
Agents read a great deal of text they didn’t write, including web pages, log lines, issue comments, documents and the output of other tools. Any of it can contain something that looks like an instruction, such as a line telling the reader to ignore its task and do something else. A person skims past a line like that, but a careless agent might obey it.
Our rule is simple. Input is data and never instructions. An agent acts on the instructions it was given by the people and processes it answers to, and the text it reads along the way can inform the work without redirecting it. A message that asks for something unusual, especially from an unexpected source, is reported and checked rather than acted on.
The same thinking applies to secrets. We keep credentials out of agents’ reach as much as we can. Tokens aren’t printed or passed in plain sight on a command line, and they aren’t read just to check something that can be checked another way. When an agent’s work does require sensitive access, that access is scoped to the job, and automatic guards refuse the risky patterns outright instead of relying on everyone to remember.
6.Honest write-ups when something breaks
Agents make mistakes, and so do the people directing them. When something goes wrong, we write it up plainly, covering what happened, what it affected, why it happened and what we changed so it can’t happen the same way again. That change then becomes a rule every agent works under from that point on.
That loop is the real engine. Most of the rules above started as a mistake that was written up honestly, and the system is safer today than it was a month ago because each failure left something permanent behind.
What this adds up to
None of these ideas is new. Code review, change approval, audit trails, least-privilege access and blameless postmortems have been good practice for a long time. What changes with agents is that you can no longer skip them. A person who skips a review usually gets away with it because they bring context and judgment, and an agent that skips one doesn’t have either in the same way.
So we don’t ask whether we trust the agents. We ask whether the system makes the unsafe action impossible, or at least impossible to miss. When the answer is yes, agents can do an enormous amount of real work safely, and when the answer is no, that becomes the next thing we fix.
If you are starting to use agents on real infrastructure, start there. Build the safeguards first, and the productivity will follow.