I have written already about what AI is doing to attention and creativity. This one is narrower, and it is about work.
The question I keep getting is whether agentic tooling is a revolution or a threat to somebody's job. I think that framing misses it. In operations the thing at risk is not the role. It is the judgment inside the role, and judgment goes quietly.
The outage that was never happening
An automated monitor flagged a metric. It recommended a rollback. The on-call engineer read the recommendation and executed it.
The metric was a scheduled batch job. It ran at that time every night. The spike was normal, and anybody who had been on that system for a month would have recognized it in about four seconds.
The rollback broke a dependency chain. Three services went down behind it. Customer-facing errors, breached SLAs, and most of a day spent debugging a failure that did not exist until we caused it.
I want to be precise about the lesson, because it is easy to get wrong. The tool was not broken. It did exactly what it was built to do, which was surface an anomaly and suggest an action. It was never designed to be the last word.
We made it the last word. Nobody decided to. It happened by a hundred small moments of the recommendation being right, until checking it started to feel like wasted effort.
That is the actual failure mode. Not a bad model. An eroded habit.
Augmentation and replacement are not the same thing
I am not arguing against automation. I have built pipelines that would be irresponsible to run by hand, and I would not go back.
But there is a real line between a tool that gives you data, context, and a recommendation while you make the call, and a tool that makes the call while you provide a signature. Both feel identical on a good day. They only separate on the day the tool is wrong, and that is the worst possible moment to discover which one you have been running.
The tell is in the language. When a team stops asking "should we do this" and starts asking "did it approve it," the line has already moved. Nobody announced it.
The military version of this is old and well understood. A tool is only as good as the operator. We spent enormous effort on the operator precisely because the equipment was good. Confidence in the gear was never allowed to substitute for knowing what you were doing, because the day the gear is wrong is the day you need the operator most.
This one lands on leadership
I do not think this is mostly an individual discipline problem, and I want to say that plainly because the discourse tends to blame the person holding the keyboard.
Leaders set what gets rewarded. If the metric is throughput, and the fastest path is to accept whatever the tool proposes, then the people doing the careful thing are quietly punished for it. They ship slower. They get asked why. Nobody writes down "spent twenty minutes verifying a recommendation that turned out to be correct," so the work is invisible right up until the one time it saves you.
Three things I would ask of anyone running a team:
Say out loud where the human decision boundary is. Which actions can be automated end to end, and which require a person who can explain the reasoning afterward. If that has never been written down, the boundary is wherever the last tired engineer at 3am put it.
Make verification a visible part of the work rather than an overhead on it. If somebody catches a bad recommendation, that belongs in the incident review as a save, not as a delay.
Model it. If you accept AI-generated analysis in a meeting without asking anyone where it came from, you have taught the room what the standard is, whatever your policy document says.
What I actually want from these tools
I want them loud and I want them wrong sometimes, visibly.
A tool that is right 99 percent of the time and silent about its uncertainty is more dangerous in operations than one that is right 90 percent and tells you which case it is in. The first one trains you out of checking. The second keeps you in the loop, which is the only place your experience is worth anything.
So: revolution or dependency? Both are available. The difference is not in the tooling. It is whether the people using it still have to understand the system, and whether anybody in the organization is measuring that.
Keep the operator sharp. The gear is already good enough to hurt you.