By Vicente Arteaga Gomez
MisLinux · Last updated: April 20, 2026
This is a standalone MisLinux article about production safety and AI-assisted operations. It reflects my own working rules and mistakes. I am not affiliated with GitHub, OpenAI, Anthropic, or any other AI vendor mentioned here.
I like AI coding agents, but I do not think "the agent can do it" is a deployment policy.
The question I care about is more specific:
> Under what conditions is an AI agent allowed to inspect, modify, or deploy something that touches production?
That answer should not depend on how impressive the last demo was. It should depend on the shape of the task, the reversibility of the action, the quality of the documentation, and the proof I expect before the change becomes real.
My default assumption
My default assumption is that an AI agent is good at speed, pattern matching, and synthesis, but dangerous when context is ambiguous and the blast radius is large.
That means I am comfortable letting an agent do more when:
- the task is well-bounded
- the workflow is reproducible
- the expected output can be validated clearly
- rollback is easy
I get much more conservative when any of those stop being true.
The first filter: read-only or mutating?
The first question I ask is whether the task is read-only or mutating.
Read-only work is the easiest place to gain value safely:
- investigate logs
- compare manifests
- trace where a metric comes from
- generate a report
- audit what changed
Mutation is a different category:
- editing a production manifest
- publishing a new image
- updating an ad server or video player config
- changing a live Blogger theme
- switching a mail relay
I do not treat those categories as morally different. I treat them as risk-different.
The second filter: can the agent explain the exact runtime contract?
One of my strongest rules is that I want the system to be documented well enough that the agent can explain what the change actually does, not merely what line it changed.
That is one reason I use Context / Intent / Rationale notes near the code and configuration. Good CIR is not there to make the repo look organized. It is there so the next change is grounded in the reason the current behavior exists.
If an agent cannot explain:
- why the current behavior was chosen
- what would break if it is reverted
- which constraints shaped the implementation
then I do not think it is ready to mutate that area safely.
The third filter: can I demand proof, not confidence?
This is the rule that matters most in practice.
I do not care whether the agent sounds confident. I care whether it can produce the right proof for the task.
The proof depends on the task:
| Task type | Minimum proof I want |
|---|---|
| Code-only local change | tests and a reproducible output or diff |
| Build/publish change | successful image build plus inspection of what was published |
| Production config mutation | before/after state, live status proof, and rollback artifact |
| Browser/UI automation | saved screenshots or structured artifacts from the real UI path |
| Report generation | saved raw inputs plus derived summary output |
This is where a lot of AI-agent workflows fail. They substitute explanation for proof. I want both, but if I have to choose, proof matters more.
The fourth filter: how reversible is the action?
The easiest production mutations to trust are the ones with:
- explicit backups
- narrow scope
- rollback instructions
- separate staging or test path
The hardest ones are the ones where:
- the live system is the only place to validate behavior
- the previous state was not captured
- rollback depends on memory or luck
- the action affects several systems at once
That is why I am much happier letting an agent update a test DaemonSet than directly change the only public hostPort DaemonSet serving real traffic.
The fifth filter: can the task be serialized?
One subtle production risk with AI agents is concurrency.
An agent can work very fast and in parallel, but some systems should not be mutated in parallel even if parallelism is technically possible. I care about that especially for:
- live browser editors
- production registry maintenance
- ad server and video player config changes on the same object
- migration flows where one save can overwrite another
So another rule I use is: the agent is allowed to move fast only where the workflow is safe to parallelize. Otherwise, the correct behavior is serialization.
What I let agents do comfortably today
I am fairly comfortable letting an agent:
- investigate a live issue in read-only mode
- prepare a deterministic config change with backups and proof steps
- update automation or tests in the repo
- generate reports, charts, or artifacts from saved data
- perform staged mutations when the rollback and validation path is already documented
That is a lot of useful work. It is also very different from saying "the agent can just operate production."
What I still treat cautiously
I get much more cautious when the task involves:
- ambiguous business logic
- undocumented production behavior
- irreversible live changes
- auth/session-sensitive browser flows
- destructive cleanup where the real state graph is not fully known
Those are the areas where the agent can still help, but usually as a prepared operator rather than an unsupervised one.
The working rule I come back to
My practical rule is this:
> An AI agent is allowed to touch production only when the task is documented well enough, bounded enough, and verifiable enough that the agent is not replacing judgment — it is executing a judgment-backed workflow.
That distinction matters a lot.
The goal is not to create a magical autonomous operator. The goal is to turn documented operational knowledge into a faster, more repeatable execution path without lowering the safety bar.
Final thought
The most dangerous mistake with AI agents is not overestimating their code skills. It is underestimating how much production safety depends on context, reversibility, and proof.
That is why my trust model is not based on whether the agent "feels smart." It is based on whether the workflow itself deserves automation.
If the system is well-documented, the action is bounded, the evidence is explicit, and rollback is real, I am happy to let the agent do a lot. If those things are missing, the right answer is not "trust the model more." The right answer is to improve the workflow first.
