In 2025, AI coding output across engineering teams rose by 59%. In the same period, the teams using AI tools most heavily shipped 7% less software than the year before.
That finding, buried in the 2026 Harness State of DevOps Modernization Report, is the most useful number for any engineering leader evaluating AI in their pipeline. More AI tool adoption does not automatically mean more delivery. What it means depends entirely on what the pipeline was capable of before the AI arrived.
This is the amplification problem. The 2025 DORA (DevOps Research and Assessment) report describes it directly: AI adoption positively correlates with throughput, but negatively correlates with stability. Organisations with mature pipelines, structured observability, and high test coverage add AI and accelerate. Organisations with flaky environments, noisy logs, and undocumented deployment processes add the same tools and accelerate their problems. The tool is identical. The outcome depends on the foundation.
This guide is for engineering leads and DevOps managers who want to use AI in their pipelines deliberately. It covers the 3 maturity stages for AI in DevOps, the lifecycle stages where AI creates the most value, the infrastructure prerequisites most teams skip, and a practical framework for evaluating AI tools against your real environment rather than a vendor’s benchmark.
Key takeaways
- AI coding output rose 59% in 2025 while heavily AI-assisted teams shipped 7% less — more AI tooling on an unstable pipeline produces worse outcomes, not better ones.
- There are 3 maturity stages for AI in DevOps: AI-assisted (generative tools that help engineers), AI-augmented (predictive models embedded in pipeline decisions), and AI-autonomous (self-healing systems). Most teams reach for stage 3 capabilities on stage 1 infrastructure.
- Generative AI in DevOps, including CI/CD (continuous integration/continuous delivery) config generation, infrastructure as code (IaC) scaffolding, and incident summarisation, is the lowest-risk, fastest entry point because it assists rather than decides.
- AIOps (artificial intelligence for IT operations) delivers measurable results in monitoring, anomaly detection, and root-cause analysis, but only when logs are structured and available at sufficient volume.
- The DevOps engineer’s role does not disappear with AI in the stack. It shifts from pipeline maintenance to model oversight, quality gate design, and evaluation of AI-generated outputs.
Why most AI DevOps investments underdeliver
The honest answer is not that the tools are bad. The tools, in many cases, are genuinely capable. The problem is sequencing: teams introduce AI into pipeline stages that are not stable or observable enough to benefit from it.
Consider what AI anomaly detection actually does. It learns from historical log data to establish a baseline and flags deviations. If your logs are unstructured, inconsistently formatted, or sparse, the model’s baseline is wrong from day one. Every alert it generates will be a combination of real anomalies and noise it cannot distinguish. Engineers learn quickly to ignore the alerts. The tool costs money for 6 months before anyone cancels the licence, and the only thing that changed is that the on-call engineers are more sceptical than they were before.
76% of DevOps teams now have AI embedded in their CI/CD pipelines. But having AI in a pipeline and having AI that improves the pipeline are different conditions. The teams getting measurable value from AI in DevOps — faster deployments, fewer regressions reaching production, reduced mean time to resolution — built the observability, data quality, and process stability first and introduced AI on top of something solid.
The DORA 2025 finding is blunt: “AI does not create elite organisations; it anoints them.” If your pipeline is already performing well, AI makes it perform better. If your pipeline has systemic weaknesses, AI will find them faster and make them more expensive. This is not a critique of the tools. It is the most important context for choosing when and where to introduce them.
What AI in DevOps actually means: 3 categories to distinguish
AI in DevOps is not a single capability. It is a family of capabilities with different prerequisites, different risk profiles, and different time-to-value expectations. Conflating them is where most adoption strategies go wrong.
Predictive AI uses machine learning (ML) models trained on historical pipeline data, build results, defect logs, and deployment records to forecast future events. Build failure prediction, test prioritisation, deployment risk scoring, and anomaly detection all belong to this category. Predictive AI requires structured historical data, a stable baseline, and ongoing model retraining as the codebase evolves. It is the most powerful category and the one with the highest infrastructure prerequisites.
Generative AI uses large language models (LLMs) to produce artefacts: CI/CD configuration files, Terraform scripts, incident summaries, pull request reviews, and documentation. A human describes what is needed; the AI produces a draft; the human reviews and approves. Generative AI does not require historical pipeline data or a stable baseline — it works from prompts and existing code. This makes it the most accessible entry point for teams at any maturity stage.
Autonomous AI combines predictive and generative capabilities into systems that detect problems and initiate remediation without human approval. Self-healing pipelines that detect an anomaly and trigger an automated rollback are autonomous AI in practice. This category requires the highest maturity across the other two: the predictive models must be reliable enough to act on, and the generative layer must produce remediations that are safe to execute without human review. Introducing autonomous AI before the predictive and generative foundations are in place is where the most expensive failures happen.
Most vendor conversations compress these 3 categories into “AI for DevOps” without distinguishing them. The practical result is that teams buy stage 3 capabilities to solve stage 1 and stage 2 problems, and discover they have added complexity rather than intelligence.
The 3-stage AI DevOps maturity model
Before selecting any AI DevOps tool, identify which maturity stage your pipeline can actually support. This is not a theoretical exercise; it determines which capabilities will deliver value and which will create problems.
Stage 1: AI-assisted
At this stage, AI tools help individual engineers work more effectively without making any autonomous decisions. A DevOps engineer uses GitHub Copilot to draft a CI/CD YAML file from a prompt. A developer uses Pulumi Neo to generate a Terraform module from a natural language description. An on-call engineer uses an LLM-based incident tool to turn a 3,000-line log dump into a readable summary with prioritised action items.
Human approval sits at the end of every AI output. The AI drafts; the engineer decides. This makes stage 1 the lowest-risk entry point: if the AI produces something wrong, the engineer catches it before it reaches production. Stage 1 can be introduced regardless of pipeline maturity, because the quality of the AI’s assistance does not depend on historical pipeline data.
A 31.8% reduction in pull request review cycle time was recorded in a 2025 field study after AI code-assist and automated review were rolled out at scale, working at the stage 1 level. The AI assists reviewers; the engineer still approves.
Stage 2: AI-augmented
At stage 2, ML models are embedded in pipeline decisions. Build failure prediction runs before the build executes and flags high-risk changes for closer review. Test prioritisation selects which tests to run first based on code change patterns and historical defect data. Deployment risk scoring evaluates a release against historical deployment outcomes and surfaces confidence levels that inform the deployment decision. Anomaly detection flags unusual patterns in logs and metrics in real time.
Stage 2 AI informs decisions; a human or a policy rule still makes them. But the model’s usefulness depends entirely on the quality and volume of the historical data it trains on. A new pipeline with 3 months of history, a Jira backlog full of inconsistently labelled tickets, or logs in a mix of formats will produce a model that generates more noise than signal. Stage 2 requires structured logs, stable baseline pipelines, and historical data that is consistent enough for a model to learn from.
Stage 3: AI-autonomous
Stage 3 systems detect problems and initiate remediation without human intervention. A deployment anomaly triggers an automated rollback. A performance degradation pattern triggers a resource reallocation. A security policy violation triggers an automated quarantine.
Stage 3 is where the highest ROI (return on investment) claims live in vendor marketing, and where the most implementation failures happen in practice. Autonomous action requires confidence in model accuracy that can only be built through stage 1 and stage 2 maturity. A team that cannot reliably read the output of its anomaly detection model should not be granting that model the ability to roll back production deployments.
The right sequencing: start at stage 1, build the data quality and observability that stage 2 requires, and earn stage 3 incrementally by extending autonomous action only to scenarios where model accuracy has been validated over time.
Where AI delivers measurable value across the DevOps lifecycle
AI adds different kinds of value at different stages of the DevOps lifecycle. Understanding which capability maps to which stage prevents teams from applying a monitoring tool to a CI problem, or a generative tool to an observability gap.
Planning and code analysis
AI-assisted code review tools like CodeRabbit and GitHub Copilot evaluate pull requests for security vulnerabilities, code quality issues, and compliance concerns before a human reviewer sees the change. In IaC workflows, AI analyses proposed infrastructure changes for cost implications, security misconfigurations, and drift from approved patterns. This stage is almost entirely stage 1: the AI flags, the human decides.
Continuous integration
Build failure prediction uses ML models trained on historical CI data to estimate the probability that a build will fail before it runs. Test prioritisation selects the highest-risk tests to run first so that critical regressions surface early in the pipeline rather than at the end of a 90-minute suite. Flaky test detection identifies tests with inconsistent pass/fail behaviour and quarantines them before they erode confidence in the test suite. All three capabilities are stage 2, requiring historical CI data to be useful.
Continuous delivery
Deployment risk scoring evaluates each release candidate against historical deployment outcomes, code change complexity, and test coverage, and generates a confidence level for the deployment team. Canary and blue-green release management with AI guardrails allows AI models to monitor early traffic on a canary release and trigger promotion or rollback based on error rates and performance patterns. Automated rollback triggers are the clearest stage 3 capability in this phase, and should be introduced only after the risk scoring model has been validated through months of human-reviewed deployment decisions.
Monitoring and observability (AIOps)
Log anomaly detection, root-cause correlation across distributed services, and predictive alerting are the most mature AI DevOps capabilities in production. AIOps tools like Datadog and Dynatrace use ML to correlate events across logs, metrics, and traces that no human can hold simultaneously, and surface the most likely root cause rather than a list of correlated alerts. This is where AI in DevOps earns its highest return in complex microservices architectures. The infrastructure requirement is significant: structured, consistently formatted logs at sufficient volume, with observability coverage across all services, not just the application layer.
Security (DevSecOps)
Container image scanning, API call anomaly detection, and compliance automation are the primary AI applications in DevSecOps. AI security tools are particularly valuable for detecting novel attack patterns that rule-based systems would not flag, because they identify behavioural deviations rather than known signatures. The Gartner forecast that 40% of enterprise applications will include AI agents by 2026, up from less than 5% in 2025, makes AI-integrated security monitoring increasingly non-optional for enterprise DevOps teams.
The 3 infrastructure prerequisites most teams skip
AI DevOps tools fail in production for the same reason AI testing tools fail: the foundations were not in place. Three infrastructure conditions must be assessed before any AI capability is introduced beyond stage 1.
Structured, consistent logs
Anomaly detection models learn from log data to establish what normal looks like. If your logs are unstructured, inconsistently formatted, or produced at different verbosity levels by different services, the model cannot establish a reliable baseline. Structured logging, JSON format with consistent schema and severity levels, is not optional for stage 2 anomaly detection. It is the minimum data quality requirement. Before introducing any ML-based observability tool, audit your logging output across all services and enforce a consistent format.
Stable baseline pipelines
A pipeline with chronic environment-related failures, builds that break for reasons unrelated to code changes, or test environments that differ from production in unpredictable ways cannot be a candidate for stage 2 or stage 3 AI. The model cannot distinguish a genuine production anomaly from a flaky staging environment. It learns from what it sees, which means it will learn to treat your infrastructure instability as normal and miss actual regressions. Fix the environment before adding the intelligence layer.
Observability coverage
AI cannot monitor what it cannot see. Before introducing ML-based anomaly detection, verify that metrics, traces, and logs are collected across all services, including the ones that were built by teams who have since moved on, and the ones that “never cause problems.” The services with no instrumentation are the ones producing dark matter in the AI model’s picture, confidence that is not earned and gaps that produce false security.
This readiness principle is consistent across the DevOps toolchain. The same 3 assessments that apply to AI in the testing layer apply here: data quality, infrastructure maturity, and skill readiness. Teams that have read our guide to AI in software testing will recognise the pattern.
Generative AI in DevOps: the fastest entry point
If you are introducing AI into a DevOps practice for the first time, start with generative AI. It assists engineers without making autonomous decisions, which means the downside risk is low and the time-to-value is immediate.
CI/CD configuration generation is the most accessible application. Tools like GitHub Copilot Agent Mode and Pulumi Neo generate pipeline YAML, Terraform modules, and Kubernetes manifests from natural language descriptions. An engineer describes what the deployment should do; the AI drafts the configuration; the engineer reviews, edits, and approves. Setup time for new pipelines is reduced significantly, and junior engineers can scaffold configurations that would previously have required a senior DevOps engineer to write from scratch.
Incident summarisation addresses one of the highest-cost problems in on-call engineering: the time between an alert firing and an engineer understanding what is happening. LLM-based incident tools, available as integrations in Datadog, PagerDuty, and several standalone tools, convert complex log dumps and alert stacks into prioritised, readable incident summaries. The on-call engineer still makes the remediation decision; the AI reduces the cognitive load of getting to that decision. This is stage 1 AI with measurable impact on mean time to understand (MTTU), which is the step that precedes mean time to resolve (MTTR).
AI-assisted IaC and code review reduces the burden on senior engineers during review cycles without removing them from the process. Tools like CodeRabbit analyse infrastructure-as-code pull requests for security misconfigurations, compliance drift, and cost implications before a human reviewer engages. The reviewer focuses their attention on the flagged items rather than scanning the entire diff. A 31.8% reduction in PR review cycle time has been recorded at teams using this approach at scale, and the reduction comes without reducing review quality — it comes from reducing the time reviewers spend on issues the AI can catch automatically.
The principle across all 3 generative AI applications: the engineer stays in the decision loop. The AI produces; the human evaluates. This is why stage 1 can be introduced on any pipeline at any maturity level, and why it delivers value faster than any other AI DevOps investment.
What AI-augmented DevOps looks like in production
The challenge of building AI into a DevOps pipeline is not usually the AI. It is making the pipeline visible and stable enough that AI-driven automation can be trusted to act on it.
When Spark Eighteen built the AI automation platform for Morfius, an enterprise AI and legacy modernisation business, the core engineering question was not “which AI tool should we use for deployment?” It was “how do we make multi-cloud deployments observable enough that we can progressively hand execution to AI without losing control?”
The answer was sequenced trust-building, not immediate autonomy. Every execution step was built with 100% traceable execution from day one: full audit trails, structured logging across all deployment stages, and human-in-the-loop verification gates at the points where autonomous action would carry the highest risk if the model was wrong. AI automation handled the repetitive, well-defined stages of the deployment process first, where the expected output was deterministic and the cost of an error was recoverable. The more complex, context-dependent stages were automated incrementally as the model demonstrated consistent performance.
The results were material: 3x faster multi-cloud deployments and a 40% reduction in build time, alongside full execution traceability that the enterprise clients required for governance and audit purposes.
The lesson is not “move fast and let AI decide.” It is: build the observability first, establish human review for the AI’s outputs before you grant it autonomous action, and expand that autonomy incrementally as accuracy is validated. This is the sequencing that produces the outcomes vendors advertise, rather than the false-positive alert storms and muted dashboards that result from skipping it.
How to evaluate AI DevOps tools without being misled by benchmarks
AI DevOps vendors publish benchmark results that reflect their optimal conditions, not your pipeline’s actual environment. Evaluating a tool against those benchmarks and extrapolating to your production context is one of the most reliable ways to make a bad procurement decision. Evaluate on 4 criteria instead.
Pipeline integration depth. A tool that requires custom middleware to connect to your version control, CI/CD orchestrator, and issue tracker introduces maintenance overhead that compounds over time and erodes the efficiency gains the tool claims to deliver. Before a proof of concept (PoC), verify that the integration is native, bidirectional, and requires no custom glue code. The tool should read from your pipeline and write results back to your issue tracker automatically, without an integration layer your team has to maintain.
Explainability. When the AI flags an anomaly, predicts a build failure, or scores a deployment risk, can it tell you why? A tool that produces decisions without surfacing its reasoning cannot be used at stage 2 or stage 3, because you cannot validate an output you cannot interrogate. Prioritise tools that surface confidence scores, contributing factors, and the data points that drove the prediction. During your PoC, specifically test whether the explanations make sense to your engineers, not just whether the predictions are statistically accurate.
Data requirements and lead time. What volume and format of historical data does the model need to establish a reliable baseline? For anomaly detection tools, ask how long the baseline period is, what log format the tool requires, and what happens during the baseline period before the model is ready. For build failure prediction, ask how many historical builds the model needs before predictions become useful. If the answers do not match your pipeline’s history and format, build time for remediation into the evaluation.
Graceful degradation. What does the tool do when the model is uncertain, when it encounters data outside its training distribution, or when a decision would have an irreversible consequence? The correct behaviour is to flag for human review and continue processing. The wrong behaviours are to fail open (silently pass uncertain items) or to fail closed (halt the pipeline). Test graceful degradation explicitly during your PoC by creating scenarios the model has not been trained on and observing how the tool responds.
Conclusion
The DevOps market is valued at $19.57 billion in 2026 and growing. AI is becoming part of every vendor’s pipeline story. That means the pressure to adopt AI DevOps tools is increasing independent of whether your pipeline is ready to benefit from them.
The teams that are building AI-augmented DevOps practices successfully in 2026 share a common discipline: they assessed their pipeline’s readiness before choosing a tool, built their observability and data quality foundations first, and introduced AI capabilities in order of increasing autonomy. They did not start with self-healing pipelines. They started with generative AI assistance, built structured logging, established baseline data, and earned stage 2 and stage 3 capabilities incrementally as the model demonstrated reliable performance under real conditions.
AI in DevOps does not make a pipeline intelligent. It makes the pipeline’s existing capabilities faster and, in some cases, more precise. The engineering investment that produces outsized outcomes from AI is the investment in what the pipeline can see, what data it produces, and how consistently it behaves before the AI arrives. Build that foundation, and the tools will have something worth running against.
If you are assessing where to introduce AI into your DevOps practice or working through what the right sequencing looks like for your pipeline’s current maturity, the team at Spark Eighteen is happy to think through it with you. Reach out at coffee@sparkeighteen.com with where you are starting from.
