For more than two decades, IT teams have been automating their work. Long before anyone talked about “self-driving” systems, sysadmins were writing scripts and building workflows to offload repetitive work.
That history matters because it explains why many technology leaders react cautiously to today’s promises around self-driving IT. The idea that systems can now be configured once and left alone doesn’t line up with how automation has ever behaved in real environments—even as “self-driving” has become a common shorthand in vendor messaging and industry discussions.
In real environments, automation has always depended on people to set it up, keep an eye on it, and step in when something didn’t go as planned. Today, humans remain central to how automation works, but the nature of that involvement is changing.
See also: On a Trust-Building Trajectory: AI in Network Automation
From rules to intent, not autonomy
Automation in IT didn’t arrive all at once. It started with manual work, moved into scripts to handle repeatable tasks, and eventually became rules that said, “If this happens, do that.” More recently, teams have begun defining higher-level objectives and letting tools surface recommendations based on what tends to work in similar environments.
Rule-based automation worked because you could see exactly what was going to happen. If the condition was met, the action followed. The problem was that the rules only covered what you thought to include. When something fell outside that, a person had to step in. And if no one was checking the results, it was easy to assume everything was fine when it wasn’t.
Now the shift is toward intent. Instead of specifying every condition, teams describe what they want to optimize for, often choosing between stability and speed, and let systems suggest or apply policies that align with that goal. In some cases, that means delaying change to avoid disruption. In others, it means acting immediately to shrink the window where a vulnerability is exposed.
That shift is appealing, especially for teams that are stretched thin. In the 2026 State of Sysadmin report, 52% of sysadmins say they’re constantly playing catch-up with technology changes, and automation is increasingly viewed less as optimization and more as survival. When human bandwidth is already spent, anything that reduces manual decision-making pressure is going to get attention.
But moving from rules to intent doesn’t eliminate the need for human involvement. It raises the bar for it.
See also: From Automation to Autonomy: Building the Architecture for Agentic AI
Why “set it and forget it” never really worked
The idea of set-and-forget automation assumes that once something is configured, it can run indefinitely without oversight. That’s never been how IT teams operate.
Even early automation required confirmation. When teams deployed applications at scale, no one assumed success until they saw logs proving the install actually completed. Validation wasn’t optional. It was part of the workflow.
That habit is still there, but there’s a lot more riding on it now. Automation isn’t just pushing out a package or running a script anymore. It’s making decisions that affect how quickly vulnerabilities are addressed or how much disruption a change might cause. When those calls are being made automatically, people want to slow down long enough to make sure the system is doing what they thought they asked it to do.
This is where the idea of “forget it” breaks down. Most IT leaders aren’t comfortable relying on automation they can’t see into or reason about, especially when the consequences involve risk lingering longer than intended or outages that ripple beyond IT. Given that security remains the top concern for sysadmins year after year, that hesitation is rational.
See also: RPA vs. AI Automation: Is Robotic Process Automation Being Replaced?
What modern automation has to get right
For automation to be usable at scale, people need to be able to follow what it’s doing and anticipate how it will behave.
If actions are being taken automatically, the logic behind them can’t be opaque. When teams don’t understand why something happened, frustration builds quickly—especially when they’re the ones expected to explain or fix the outcome.
Timing matters just as much. Automation that technically works but acts unpredictably makes teams less willing to rely on it. If people don’t know when something will run or how broadly it will apply, they hesitate to hand it control.
And once something runs, there has to be a way to check the result. If you can’t go back and confirm what happened—or see where it didn’t—you can’t safely give the system more responsibility.
These behaviors aren’t edge cases. They’re the norm for automation that’s meant to operate in real, hybrid environments where complexity isn’t temporary.
Where humans still do the critical work
As automation expands, people don’t disappear from the process. The work just changes.
People still define what success looks like. Systems can execute policies, but they don’t decide whether avoiding downtime matters more than closing a vulnerability quickly. Those choices depend on what the organization is trying to protect or move faster on at that moment.
Humans also interpret results. Automation can surface errors or deviations, but knowing which ones demand immediate attention and which can wait is experience-driven. Not every failure carries the same weight.
Exception handling remains firmly human. When something falls outside the rules, people step in. Automation can flag that something is wrong, but deciding what to do next still requires judgment.
Communication doesn’t just happen automatically. As automation reaches across more systems, IT teams spend more time explaining what they configured, why they chose that approach, and what it means for security or stability. The system can execute the policy, but it can’t explain it. That still falls to people.
How the role is changing
As automation moves from executing tasks to enforcing policy, accountability shifts upstream. Senior administrators often become the default escalation path—not because automation failed, but because it worked at scale. When a policy applies across more systems, a mistake affects more than just one machine. That concentrates responsibility around the people who define objectives, approve changes, and review outcomes.
The same shift expands IT’s influence. When automation enforces decisions about risk tolerance, timing, and trade-offs, IT is no longer just operating infrastructure. It is shaping how the organization balances stability and speed. That means more coordination across security, DevOps, and leadership.
It also changes how experience develops inside teams. In the past, expertise accumulated slowly through repetition and exposure. Today, recommendation engines and visibility into outcomes give sysadmins more feedback in less time. Junior team members see what works, what fails, and how decisions connect to results much faster than they used to. That doesn’t eliminate the need for senior judgment. It changes where that judgment is applied.
Automation hasn’t taken people out of the loop. If anything, it’s made their decisions more visible and easier to review.
The question CTOs should be asking
For technology leaders, the real question isn’t how autonomous a system claims to be. It’s whether it improves decision-making and makes outcomes easier to review. That means defining objectives up front and choosing tools that make validation and accountability straightforward, not adding another layer to manage.
Self-driving IT isn’t hands-off. It’s higher leverage: Automation handles scale, and people remain responsible for intent and outcomes.
The teams that get this right won’t chase autonomy for its own sake. They’ll pressure-test automation before trusting it and expect to look back and see exactly what happened. That’s what builds confidence over time—not promises of independence, but systems that make it easy to approve, verify, and adjust when reality doesn’t match the plan.
