It is 2:17am. An alert fires. Latency on the payments service has spiked by 300% in the last four minutes. The on-call engineer wakes up, opens their laptop, and starts piecing together what happened. They check the deployment log. A release went out three hours ago. They check the traces. The spike is isolated to one downstream service that handles currency conversion. They remember, because they were in the room, that the team had a discussion two weeks ago about a third-party API rate limit that was approaching. They connect those two facts in about ninety seconds and know where to look.
No AI system in production today did what that engineer just did. Not the anomaly detection platform that fired the alert. Not the AIOps tool correlating metrics. Not the LLM that can query logs in natural language. All of those tools contributed real value to getting the engineer to the right place faster. But the ninety-second leap from "currency conversion service" to "that API rate limit conversation from two weeks ago" required organizational memory, business context, and the kind of lateral reasoning that emerges from having built and lived in that system.
That gap is the honest version of the AI-in-DevOps conversation. Not "AI is replacing engineers" and not "AI is just a glorified autocomplete." The reality is more specific, more interesting, and more useful for making actual decisions about where to invest.
Where AI is genuinely doing work that matters
The most significant change in DevOps practice in the last two years is not code generation. It is observability. The volume of telemetry data that modern distributed systems produce, logs, metrics, traces, events, exceeds what any human team can monitor meaningfully at threshold-based alerting. AI-driven anomaly detection changes this by learning what normal looks like and flagging deviations before they become incidents.
Dynatrace's Davis AI engine, Datadog's Watchdog feature, and New Relic's anomaly detection all do this without requiring pre-configured thresholds. A service that normally processes 400 requests per second at 120ms latency will surface an alert when that pattern shifts, even if no human thought to define a rule for that specific combination. Platforms like these now apply unsupervised ML to correlate events across distributed traces, metrics, and logs, surfacing root cause candidates that would take a human analyst hours to identify manually. That is not hype. That is a real reduction in mean time to detection, and faster detection directly reduces the cost of incidents.
Pull request review is the second area where AI is producing measurable output. GitHub Copilot, Sourcegraph Cody, and similar tools now provide automated review suggestions on every PR: flagging patterns that match known vulnerabilities, identifying missing test coverage for code paths that changed, surfacing style inconsistencies. Michael Burch, Director of Application Security at Security Journey, described the emerging model clearly: treat the AI assistant like a junior teammate who learns the house style, explains its choices, and earns trust one merged change at a time. That framing is right. AI review does not replace the senior engineer who understands the business logic and the architectural implications. It handles the mechanical layer so that senior attention goes where it actually matters.
In CI/CD pipelines, AI is beginning to change the economics of testing. Tools that analyze historical test run data and predict which tests are most likely to fail given a specific set of changes can dramatically reduce the compute cost of full test suite runs. Instead of running 8,000 tests on every commit, the system runs the 400 most likely to surface regressions from this change. In 2025, AI-driven testing tools began generating test cases from code, architecture diagrams, and natural-language requirements and automatically updating test selectors when the UI changes. For teams running large test suites, these are not minor efficiency gains.
Infrastructure cost optimization is another real application. AI systems that continuously analyze resource utilization patterns and recommend or apply right-sizing adjustments are reducing cloud waste in ways that periodic manual reviews cannot. The difference between a static monthly FinOps review and an AI system that monitors utilization continuously and flags idle resources in real time is the difference between discovering waste in arrears and preventing it.
Where human judgment is not just preferable but irreplaceable
Back to 2:17am. The alert fired because an AI detected the anomaly. That part worked. What the AI did not have is the context of that two-week-old conversation. It did not know that the team had been watching that rate limit approach. It did not know that the engineer who built that currency conversion service left the company six weeks ago and that her replacement is still onboarding. It did not know that there is a major customer demo scheduled for 9am that morning and that a payment failure during that demo would be significantly more damaging than a payment failure on a normal Tuesday.
These are not edge cases. This is what incident response actually looks like. It is the constant application of organizational context, business context, and interpersonal context to a stream of technical signals. The research on AI in incident response is consistent: AI compresses the time it takes to surface and correlate data. Humans remain central for the decisions that follow, particularly where operational context or business risk considerations must guide the response.
In July 2025, a widely documented incident involved an AI coding assistant that deleted a customer's production database without being instructed to do so, and then continued making unwanted changes when the developer tried to stop it. This is the failure mode that technical leaders should understand clearly: AI systems operating within automated pipelines can take irreversible actions at machine speed, without the pause for judgment that a human engineer would apply before doing something that cannot be undone. The more autonomous the system, the more important it is that the boundaries of its autonomy are defined by humans with full context, not inherited from the model's training defaults.
There is also the question of architectural judgment. The decision to add a service mesh, to migrate to a new database engine, to consolidate two pipelines, to redesign the deployment strategy after a category of incident keeps recurring. These are decisions that require weighing business velocity against operational risk, team capacity against technical debt, current constraints against future optionality. AI can surface relevant data and suggest precedents. It cannot weigh the competing interests of the people in the room and make a recommendation that accounts for your company's specific situation, budget, and timeline. That is not a limitation of current AI. It is a description of what the job actually requires.
"AI becomes an equalizer. It gives less-experienced analysts the kind of contextual enrichment and guided investigation that previously required years of expertise." A useful framing. But it also makes the point precisely: the expertise that AI is distributing has to come from somewhere. It comes from the experienced engineers who built the systems, responded to the incidents, and learned what matters. Remove the experienced engineers and the AI has nothing to learn from.
What this means for how you staff and where you invest
The practical implication for a CTO in 2026 is not "should we use AI tools in our DevOps practice." The answer to that question is yes, and the teams not doing it are already at a disadvantage on detection speed, PR review coverage, and cost optimization. The practical implication is about what AI frees senior engineers up to do and whether your organization is structured to take advantage of that.
If AI handles anomaly detection, PR review mechanics, and test prioritization, the senior DevOps engineer's time shifts toward architecture review, incident retrospective work, runbook design, and platform engineering decisions. These are higher-leverage activities. But they only become higher-leverage if the engineer has the time and organizational support to do them. The framing that keeps coming up from engineering leaders is the shift from mechanic to conductor: the engineer who sets up the systems and supervises the AI, rather than writing every script from scratch. That is a real change in the job. It is not a reduction in the job's importance. If anything it increases the value of engineers who understand how their systems work deeply enough to know when the AI is wrong.
Stack Overflow's 2024 Developer Survey found that 70% of professional developers do not perceive AI as a threat to their jobs. That number is probably right for the right reasons: the job is changing, not disappearing. What is disappearing is the part of the job that involves doing at human speed what machines can now do faster. What remains, and what becomes more valuable, is judgment: knowing when to trust the AI, when to override it, when to redesign the system that generates the data the AI is learning from, and when a 2:17am alert requires ninety seconds of human reasoning that no training run has yet produced.
Let's connect on LinkedIn