Top DevOps Trends to Watch in 2026

How to Read a DevOps Trends List

Nearly every "DevOps trends" article you will read this year shares a structural problem: it cites predictions as though they were observations.

That distinction determines whether a trend belongs in your roadmap or your reading list, which makes it worth ten minutes.

Two habits follow from this table, and they are the only methodology this article uses.

First, check the edition, not just the source. Several 2026 articles cite "the 2026 Stack Overflow Developer Survey." No such thing has been published: the 2026 survey opened on 23 June 2026 and results are not out. Its current edition is the 2025 survey, published 29 December 2025. Anyone quoting "2026 Stack Overflow data" is quoting 2025 numbers under the wrong label.

Second, grade predictions when their year arrives. A 2023 forecast about 2026 is testable in 2026. Most trend articles quietly re-publish the forecast instead. Trend 3 below grades one.

Trend 1: AI Moved From an Adoption Question to a Stability Question

Nobody still needs convincing that teams use AI in the delivery pipeline. A better question has replaced it: what is AI doing to the things DevOps exists to protect?

What the largest survey found

DORA is DevOps Research and Assessment, a long-running research program now run by Google Cloud that measures software delivery performance across thousands of organizations each year. Its annual report is the closest thing the field has to an industry benchmark.

DORA's 2025 State of AI-assisted Software Development was published 24 September 2025 and surveyed nearly 5,000 technology professionals. It reports 90% of respondents using AI at work, up 14 points year over year, with a median of about two hours a day. Over 80% say it increased their productivity.

Then the same report records that 30% have little or no trust in AI-generated code.

Worth noting who is asking: DORA is Google Cloud research, and Google sells AI coding tools. That does not invalidate a ~5,000-respondent survey, but it is the largest vendor-adjacent dataset in this article and the one most quoted without that context.

The finding that should actually change your engineering plan is a reversal. In Google's own words: "Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance. However, AI adoption does continue to have a negative relationship with software delivery stability." DORA states this directionally rather than as a coefficient, so no percentage is quoted here.

DORA's explanation of the mechanism is the part worth acting on. "Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

In plain terms: AI is helping teams ship more, and it is still helping them break things.

The controlled trial that complicates the survey

Surveys measure what people believe about their own productivity. Belief is a notoriously unreliable instrument, and one well-designed study now shows exactly how unreliable.

METR's randomized controlled trial was published 10 July 2025. It took 16 experienced open-source developers working on repositories they had contributed to for about five years on average. These were mature codebases: 22,000+ stars, over a million lines. The trial then randomized 246 real tasks to allow or disallow AI tooling.

Developers were 19% slower when allowed to use AI.

The perception gap is the part worth pinning to a wall:

Developers did not merely mispredict beforehand. After finishing the work, they still believed they had been 20% faster. They were 19% slower.

Three caveats belong with this result, and METR states them plainly rather than waiting to be pushed. Sixteen developers is a small sample. Its tooling was early-2025 frontier, primarily Cursor Pro with Claude 3.5 and 3.7 Sonnet, which is materially older than what your team uses today. And METR explicitly does not claim that AI fails to speed up most developers, that the result generalizes past software, or that better usage patterns do not exist.

What survives those caveats is narrower and still important: self-reported AI productivity gains are weak evidence, and in the one population measured directly they pointed the wrong way. Those developers were confidently wrong about their own experience, in the same direction the surveys point.

Developers agree, when you ask them precisely

The 2025 Stack Overflow Developer Survey (published 29 December 2025, 49,000+ respondents across 177 countries, read 17 September 2026) shows the same tension inside a much larger sample. 84% use or plan to use AI tools. Note that phrasing, which is not the same as 84% active daily use. On accuracy, 46% distrust AI output against 33% who somewhat or highly trust it. Only 3.1% highly trust it.

Its most operationally useful numbers are the frustrations. 66% cite "AI solutions that are almost right, but not quite" as their top frustration, and 45.2% say debugging AI-generated code is more time-consuming than writing it themselves.

A sourcing note, because this one is genuinely confusing: Stack Overflow's own blog post announcing these results transposes the two figures, stating "the number-one frustration, cited by 45% of respondents" and separately that "66% of developers say they are spending more time fixing 'almost-right' AI-generated code." The survey data itself reports the reverse, and most secondary coverage copied the blog's version. Figures above follow the survey data.

And the security bill has not moved

Veracode's Spring 2026 GenAI Code Security Update, published 24 March 2026, evaluated over 150 large language models across 80 coding tasks in four languages. Only 55% of AI-generated code passed security checks when the model was given no explicit security guidance. Veracode sells application security testing, so treat the framing as interested — but the methodology is stated and the result is unflattering to a market Veracode also wants to sell into.

Veracode's own framing does the damage: that number is "virtually identical to where it stood two years ago." Model capability improved enormously between 2024 and 2026. Security pass rates did not move.

What to do about it: treat AI-generated code as untrusted input to your pipeline, not as a trusted contributor. In practice that means three things. Static analysis and dependency scanning run on every AI-assisted PR, without exception. Review policy does not let AI-generated diffs skip human review just because they look clean. And Java services are held to a stricter gate than the rest, given the pass rate above.

Trend 2: The DORA Metrics Changed, and Most Teams Are Still Measuring Four

This change is quiet, free to act on, and almost universally missed.

We covered the tooling side of DevOps in our guide to the five tools worth knowing in 2026; this is the measurement side, and it has moved more than the toolchain has.

If your dashboard tracks deployment frequency, lead time for changes, change failure rate and time to restore service, you are measuring the 2018 framework. DORA's own metrics history page, last updated 2 January 2026, documents two structural changes.

The four keys became five, in two groups.

Rework rate is the addition that matters. It captures deployments that required unplanned work afterward but did not constitute an outright failure: the hotfix that was not quite an incident. If you are shipping more AI-assisted code, this is precisely the metric that will move first, and precisely the one your current dashboard does not have.

Elite/High/Medium/Low is gone. The 2025 report replaced the four performance clusters with seven team profiles: Harmonious high-achievers, Pragmatic performers, Constrained by process, Stable and methodical, Legacy bottleneck, High impact / low cadence, and Foundational challenges.

Calling that a rename undersells it. Four tiers implied a single ladder every team climbed. Seven profiles concede that a team can be genuinely healthy on one axis and genuinely stuck on another, and that "elite" flattened those cases into one score. If you have ever had to explain to a board why a team with excellent delivery numbers felt terrible to work on, the new model has a name for that team.

One caveat on this: the percentage distribution across the seven profiles circulates widely but is not stated on DORA's public summary pages. The profile names are verified; treat any specific split you see quoted as unconfirmed unless it cites the report PDF directly.

What to do about it: add rework rate to your delivery dashboard this quarter. It requires no new tooling — it is derivable from the deployment and incident data you already collect — and it is the single best early-warning signal for the AI stability trade-off described in Trend 1.

Trend 3: Platform Engineering's Big Prediction Came Due. The Data Disagrees With Itself.

Platform engineering is the practice of building an internal developer platform: a self-service layer over infrastructure, CI/CD and environments that application teams use directly, instead of filing tickets with an operations team. An internal developer platform (IDP) is the product that practice produces.

In November 2023, Gartner's Hype Cycle for Software Engineering press release predicted that by 2026, 80% of large software engineering organizations would establish platform engineering teams, up from 45% in 2022.

One sourcing caveat, stated up front. Gartner's newsroom blocks automated retrieval, so this is the single figure in this article we could not pull directly from the publisher's own page. The wording above (including "large," which most retellings drop) is the version Gartner carries on its own platform engineering topic page and is consistent across every secondary source we checked. The link points at Gartner's release so you can open it yourself. Everything else here was read at its primary.

2026 is here. Let us grade it.

Two credible measurements exist, and they do not agree.

DORA's platform engineering capability page, last updated 12 January 2026 and drawing on the ~5,000-respondent 2025 research, reports 90% of organizations using an internal developer platform and 76% with dedicated platform teams.

CNCF and SlashData's Technology Landscape Radar was published 24 March 2026, surveying 400+ professional cloud-native developers in Q4 2025. It reports 28% with a dedicated platform engineering team, 41% using a multi-team approach, and 31% with no formal approach at all.

Seventy-six percent against twenty-eight percent is a nearly threefold gap rather than a rounding difference, and working out which one describes you tells you more than either number alone.

The most plausible explanation is population rather than error. The two studies surveyed different people. DORA's is a broad technology-professional panel. CNCF and SlashData sampled working cloud-native developers across a wide range of company sizes, including the small teams where "the platform" is one senior engineer and a Terraform repository. Neither publishes a size breakdown detailed enough to prove this, so treat it as the likeliest reading rather than a settled one.

What can be said cleanly is that no single number here supports the claim as it is usually quoted. DORA's 76% sits just below Gartner's 80% forecast; CNCF's 28% is nowhere near it. Which brings up the other problem with that statistic — the version circulating online has quietly dropped the word "large." Gartner forecast 80% of large software engineering organizations. If you run a 30-person engineering team and someone tells you 80% of companies like yours have a platform team, that is not what Gartner said, and CNCF's 28% is the number that describes your world.

The counter-evidence comes from the pro-platform camp

The most credible criticism of platform engineering comes from the pro-platform camp, and sits on DORA's own page.

DORA documents a J-curve: organizations see early gains, then a dip in performance as platform complexity rises, before stabilizing at a higher level. And directly: platforms "can sometimes lead to a decrease in throughput and change stability if not carefully managed."

One more thing is worth noting. The only platform-related effect size DORA publishes on that page is modest. Developer independence produced a 5% productivity improvement at both team and individual levels in its 2024 research.

One conditional finding in DORA's 2025 research is genuinely strong, and it is why platform engineering belongs on a 2026 list rather than a 2023 one. Where platform quality is high, AI adoption has a strong positive effect on organizational performance. Where platform quality is low, the effect is negligible. This is correlational rather than experimental. It still reframes the investment case: platform quality is what determines whether AI spend converts into anything.

Thoughtworks has had platform engineering product teams in the "Adopt" ring of its Technology Radar since 2021. It still warns about the common failure mode: layered platform teams that preserve existing silos under a new label, ticket-driven operating models, and renaming internal teams without changing how they work.

What to do about it: score your platform's quality before you expand AI tooling on top of it, because the DORA finding above says the second investment depends on the first. A blunt proxy works: how long does it take a new engineer to deploy a change to production on their first day, and how many people do they have to ask?

Trend 4: Supply Chain Security Stopped Being Advice and Became a Deadline

Every DevOps trends list for the last four years has said "software supply chain security is increasingly important." In 2026 that sentence acquired dates. If you sell software into Europe, one of them has already passed.

The date that just landed

An SBOM is a software bill of materials: a machine-readable inventory of every component and dependency shipped inside a piece of software. It exists to answer one question fast: are we affected? The Cyber Resilience Act (CRA) is EU legislation setting cybersecurity requirements for products with digital elements sold in the European Union.

Per the European Commission's own Cyber Resilience Act reporting page, CRA reporting obligations took effect on 11 September 2026. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents through the CRA Single Reporting Platform to the relevant CSIRT and ENISA.

Two things teams routinely get wrong here. First, the September 2026 tranche covers reporting only. SBOM generation and CE marking sit in the December 2027 tranche, and plenty of articles collapse the two into one deadline. Second, a 24-hour early-warning clock is an incident response requirement before it is a documentation requirement. If your on-call runbook has no step that says "assess EU reporting obligation," you have a gap, regardless of how good your SBOM tooling is.

This is an engineering summary, not legal advice. CRA scope, exemptions and conformity routes vary by product and business model. Take the dates above as a prompt to talk to counsel, not as a determination of your obligations.

Meanwhile, the US moved the other way

Almost no trend article covers this, and it matters if you sell into both markets.

On 23 January 2026, OMB issued memorandum M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security". It rescinded M-22-18 and M-23-16, the memoranda that had required federal agencies to obtain secure software development attestations before deploying third-party software. The memo states that M-22-18 "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments."

Under M-26-05, agencies "may choose" to use the Secure Software Development Attestation Form. They "may also choose to adopt contractual terms that require a software producer to provide a current software bill of materials (SBOM) upon request."

May, not must. Federal SBOM requirements became discretionary in January, while EU reporting requirements became mandatory in September. If your compliance roadmap was built around US federal pressure, the pressure moved continents.

Separately, CISA published 2026 Minimum Elements for an SBOM on 29 July 2026, jointly with NSA, FBI and international partners, updating and replacing the 2021 NTIA elements. So the technical standard got better while the mandate to use it got weaker.

The attacks are real, but the famous number is not

Sonatype's 2026 State of the Software Supply Chain, published 28 January 2026, counted 454,600 new malicious open-source packages during 2025, a 75% year-over-year increase. Cumulative detections reached 1.233 million, with over 99% of them appearing on npm. Sonatype sells software supply chain security tooling, and the detections come from its own telemetry.

Use that number carefully. About 169,538 of the 454,600 came from a single spam campaign (IndonesianFoods), so the headline is inflated by one actor, and it counts detections, not successful compromises.

The named incidents tell the story better than the aggregate. Shai-Hulud, in September 2025, was the first self-replicating npm worm; GitHub reported removing 500+ compromised packages after being notified on 14 September 2025. A second wave followed in November. Earlier, in March 2025, the tj-actions/changed-files compromise (CVE-2025-30066, CISA alert 18 March 2025, read 17 September 2026) saw version tags repointed to a malicious commit. That commit scraped CI runner memory for secrets and printed them into public build logs. Tens of thousands of repositories referenced the action.

That last incident should change how you write CI configuration, and the fix costs one line per action.

What actually changed in your tooling

The registries responded, and the defaults moved in your favor:

• npm classic tokens were permanently revoked on 9 December 2025. npm login now issues a short-lived session token. If a pipeline of yours still fails mysteriously on publish, this is why.
• Trusted publishing from GitHub Actions and GitLab CI now generates provenance attestations automatically, with no --provenance flag required (npm CLI 11.5.1 or later).
• GitHub Artifact Attestations, GA since June 2024 and built on Sigstore, produce signed build provenance verifiable outside GitHub.
• SLSA v1.2 became the current approved specification on 24 November 2025, adding a Source Track alongside the existing Build Track. SLSA is Supply-chain Levels for Software Artifacts, a graded framework for proving how a build artifact was produced. If a vendor tells you they are "SLSA compliant," ask which track and which level. Any article telling you v1.0 is current is at least two revisions out of date.

What to do about it, in priority order: pin every third-party GitHub Action to a full commit SHA rather than a tag. That single change would have blunted tj-actions entirely. Turn on trusted publishing for anything you publish to npm. Add an EU CRA reporting assessment step to your incident runbook if you ship into Europe. Then generate SBOMs, which is the step most teams do first and which protects you least on its own.

Trend 5: FinOps Absorbed AI Spend, and Estimated Cloud Waste Ticked Up

Cost discipline is the least glamorous trend on this list and the one most likely to affect your budget conversation this quarter.

FinOps is the discipline of managing variable cloud spend as an engineering concern rather than a procurement one, giving teams cost visibility and accountability for the infrastructure they provision.

The State of FinOps 2026 was published by the FinOps Foundation on 19 February 2026, with 1,192 respondents representing over $83 billion in annual cloud spend. It records a scope change that happened remarkably fast: 98% of FinOps practitioners now manage AI spend, up from 31% two years earlier. One structural caveat on a 67-point jump: the sampling frame is self-identified FinOps practitioners, so the number describes how the discipline's remit expanded, not what share of all companies govern AI spend. Alongside that, 90% manage SaaS, 64% licensing and 48% data center costs.

"FinOps for AI" is now the top forward-looking priority, and AI value management the most-wanted skill — while workload optimization and waste reduction remain the top current priority. Those two statements get conflated constantly; they are both true and they describe different time horizons.

Meanwhile Flexera's 2026 State of the Cloud Report, published 18 March 2026 from 753 cloud decision-makers, puts self-estimated wasted cloud spend at 29%. That is up from 27% in both 2025 and 2024, and the first increase in five years. Flexera attributes the reversal to AI and GPU workloads plus rising IaaS-to-PaaS cost complexity.

Be precise about what that 29% is. It is a self-reported estimate rather than a measurement: respondents estimate their own waste, bounded by what their tooling already surfaces. Treat it as a floor. The widely repeated "studies show 30% of cloud spend is wasted" framing treats a survey estimate as an observation, and Flexera's own year-by-year series has drifted between 27% and 32% since 2019 without the underlying figure ever being measured.

What stays useful is the trend line: five consecutive years of improvement reversed in the first year of serious AI workloads.

What to do about it: separate AI and GPU line items from general cloud spend in your reporting before the next budget cycle. You cannot manage the fastest-growing category in your bill while it is bundled into "compute." Treat accelerator commitments as shorter-horizon decisions than general compute, too, because a reservation outlives most model choices. Where the arithmetic gets genuinely difficult is blended teams across time zones, which we broke down separately in our look at what DevOps services in India actually cost.

Trend 6: OpenTelemetry Graduated, Which Settles the Instrumentation Question

OpenTelemetry is a vendor-neutral standard and set of SDKs for generating traces, metrics and logs, so that instrumentation written once can be sent to any compatible backend.

On 21 May 2026, OpenTelemetry graduated from the CNCF, reaching the foundation's highest maturity tier alongside Kubernetes and Prometheus. CNCF reports it as the second-highest-velocity project of its 240+, behind only Kubernetes, with over 12,000 contributors from more than 2,800 companies.

For a practitioner, graduation matters less as a milestone than as a signal: the standards question is settled even where adoption is not, and writing vendor-specific instrumentation in 2026 now means choosing future migration work.

Signal maturity is uneven, though, and worth knowing before you plan:

Continuous profiling is the genuinely new capability here, and it is the one to pilot rather than standardize on. Roughly 20% of respondents to the CNCF 2025 Annual Survey (published 20 January 2026, read 17 September 2026) report using profiling in their stack.

That same survey found Kubernetes in production at 82% of container users, up from 66% in 2023, and 66% of organizations hosting generative AI models using Kubernetes for inference. Kubernetes has become the substrate the AI workloads land on, which is why the platform quality finding in Trend 3 compounds.

On the eBPF side, Cilium graduated in October 2023 and remains the reference implementation, with Hubble providing L3–L7 network observability and Tetragon covering runtime security observability and enforcement. Its practical appeal is unchanged: kernel-level visibility without modifying or redeploying application code.

One caveat on the observability cost narrative

You will read a great deal in 2026 about observability costs spiraling. The claim is probably directionally right, and the evidence behind it is weaker than the confidence with which it is usually stated.

Best-sourced on this is Dimensional Research's study sponsored by Elastic, published 10 December 2025 across 500+ IT decision-makers: 97% report having experienced observability cost surprises, and 67% experience them regularly. Note that Elastic sells observability tooling and benefits commercially from that narrative. This is real research with a named sample and an interested sponsor.

The more specific figures circulating, such as "observability is 15–25% of cloud spend" and "84% of users struggling with cost," appear only on affiliate and SEO sites with no traceable primary source. We could not verify any of them, so they are not quoted here as fact.

What to do about it: instrument new services with OpenTelemetry rather than a vendor SDK, and treat profiles as a pilot rather than a standard until it leaves alpha. If you are already on vendor-specific instrumentation, migrate at the next service rewrite instead of running a migration project.

Four Numbers You Will Be Quoted This Year. None Survives a Source Check.

Each of these appears in multiple 2026 DevOps trend articles. Each is wrong in a specific, checkable way.

"Software supply chain attacks rose 742%"

Still circulating in 2026. It comes from Sonatype's 8th Annual State of the Software Supply Chain, published October 2022, and it described a three-year average annual increase measured from 2019 to 2022. It is four editions out of date and was never an annual figure.

The closest current replacement is Sonatype's 2026 edition: 75% year-over-year growth in open-source malware detections, published 28 January 2026. Quote it with the caveat attached, though — as noted above, roughly 37% of that year's detections came from a single spam campaign. Strip those 169,538 packages out and the year-over-year growth in everything else falls to roughly 10%, an order of magnitude below the headline. If you want one honest sentence: malicious package detections are rising fast, and nobody publishes a clean de-duplicated growth rate.

"AI-generated code contains 2.74x more vulnerabilities than human-written code"

Usually attributed to Veracode. We read Veracode's published Spring 2026 update and found no comparison to human-written code in it at all — the study measures pass rates for AI-generated code, not a human baseline. The 2.74x figure appears only on low-tier aggregator sites.

The real, sourced finding is the one in Trend 1: 55% of AI-generated code passes security checks, and that rate has not improved in two years. That is a serious result. It does not need embellishment, and the embellished version is the one that will get you corrected in a technical review.

"90% of developers use AI daily"

DORA's 2025 report says 90% use AI at work, with a median of about two hours a day among those who do. "At work" and "daily" are different claims, and the substitution consistently runs in the direction of overstating adoption.

"80% of organizations will have platform teams by 2026"

Gartner's line has quietly lost the word "large" in most retellings, along with its 45% baseline. As Trend 3 shows, that single dropped adjective is the difference between a prediction that roughly held for big enterprises and one flatly contradicted by measurement among everyone else.

What to Actually Do in the Next Two Quarters

Ranked by return on effort, using only the evidence above.

Notice that the first five take hours or days rather than a transformation program. Conveniently, the 2026 trends with the best evidence behind them are also the cheap ones.

If you want a second opinion on where your pipeline stands against this list, talk to our DevOps team — we are happy to walk through which of the eight above you have already covered.

The Bottom Line

The through-line across all six trends is that 2026 is the year DevOps got measured rather than predicted, and measurement has been unkind to the consensus.

AI adoption is universal and its effect on stability is negative. A metrics framework changed underneath teams who never updated their dashboards. Platform engineering's flagship prediction is simultaneously vindicated and contradicted depending on company size. Supply chain security acquired a real deadline in Europe while the US requirement loosened. Cloud waste rose for the first time in five years. And the instrumentation debate quietly ended.

None of that requires a transformation program. The first five actions above take hours or days. The two highest-return items, pinning your GitHub Actions to commit SHAs and adding rework rate to your dashboard, can be done this week by one engineer.

One habit worth keeping past this article is the one in the second section: when someone hands you a number about DevOps, ask which edition it came from and whether it was measured or predicted. In researching this piece, four of the most-quoted statistics in the field failed that test. Yours will too.

If you would rather not audit your own pipeline, that is what we do. See how we run DevOps engagements.

How This Article Was Verified

Every statistic above was read at its primary source — the publishing organization's own report page, press release, changelog, standard, or regulatory text — on 17 September 2026, not taken from secondary coverage. Where only a vendor-published or vendor-sponsored figure existed, that commercial interest is stated inline rather than left for the reader to discover.

Four specific checks shaped the final text. DORA's publications index was checked directly to confirm no 2026 edition exists yet, so the 2025 report is correctly described as current. The OMB memorandum was read as the published PDF, and its "may choose" wording is quoted verbatim from it. The Cyber Resilience Act dates and the Article 24(3) reference come from the European Commission's own reporting page, not from a secondary summary. And the Stack Overflow figures were taken from the survey data rather than the announcement blog post, because the two disagree.

Several widely-circulated figures were deliberately excluded for want of a traceable primary: observability as a share of cloud spend, cloud repatriation percentages, any "share of code written by AI" figure, and Sigstore adoption totals. Where a number could not be verified, it was left out and named as unverifiable rather than repeated.