DevOps is dead!
Really? This is admittedly provocative, but technology is moving on rapidly. Can it be true?
To conduct this alleged post-mortem, from the perspective of business leadership and the investment case, rather than technical detail, let’s consider:
- What problems DevOps solved in the first place;
- Whether it solved them;
- Whether those problems still exist, today.
What did DevOps solve?
If you ask a technical leader, you’ll get an answer around organisational silos, slow deployment cycles, and poor feedback loops. These are correct. But what about the business case? What did DevOps solve, from a strategy and “investment case” perspective?
Speed of response to market opportunities
Companies couldn’t release new features or respond to competitors quickly enough. If a release cycle took three months, any strategic pivot or customer demand took at least that long to address. This created competitive disadvantage in fast-moving markets.
Moreover, failed deployments frequently caused outages. When releases happened infrequently (say, quarterly), each deployment carried enormous risk. A failed release could mean days or weeks of degraded service whilst teams scrambled to fix issues or roll back changes. The revenue and reputational costs were substantial.
Cost of change, inability to scale
Making changes to software products was expensive because of the labour-intensive deployment process and high failure rates. Each release required substantial operations team involvement, limiting how many changes the business could afford to make.
As the business grew and needed more frequent releases, the operations bottleneck became acute. Hiring more operations staff provided poor returns because the manual processes didn’t scale linearly. The business faced a choice between constraining growth or accepting exponentially increasing operational costs.
Poor return on development investment
Development teams spent significant time on work that never reached customers. Features sat in queues waiting for deployment windows, or failed during deployment and required rework (and the next deployment window). This meant development capacity wasn’t translating efficiently into customer value.
Did DevOps work?
Ultimately, strategic decisions about product direction took months to implement and validate. This made it difficult to test hypotheses, learn from customer behaviour, or pivot based on market feedback. The business was operating with delayed and limited information about what actually worked.
The investment case for DevOps rested on reducing time-to-market, improving the return on development spend, and creating operational leverage that scaled with the business rather than against it.
These have been measured consistently over the years through the Annual State of DevOps report, and exhaustively examined in best-selling books such as Accelerate and indeed, market performance is strongly correlated with meaningful adoption of DevOps principles.
Fast-forward to today (and looking a little further into the future). Let’s consider the two halves of “DevOps”:
- Dev: Increasingly, development (at least from the perspective of raw code creation, but also expanding to other fields such as the broad spectrum of design and rapid product iteration) is falling within the competence of generative AI. Are the things that made development teams (in the broadest sense, i.e. product development including engineering) successful through DevOps adoption still relevant benefits going forward? Does AI shift entirely the way that we bring products to market, and therefore our decision-making around investment strategy?
- Ops: Coupled with the rise in AI, cloud-based infrastructure ecosystems have evolved into extremely capable platform-as-a-service offerings. Once the domain of low-budget operators, these PaaS solutions have matured to provide extremely sophisticated, stable, secure, and high-scale cloud environments. It no longer makes sense, in most cases, unless actually creating fundamental infrastructure at scale, to invest directly in cloud infrastructure. PaaS offerings encompass the full range of “Ops”, from pipeline automation to edge compute and edge storage, to a level of sophistication (and economy) that it would be prohibitive to build bespoke using primitive hyperscale services.
Given the above, in most enterprise-scale scenarios (and I reiterate: this is somewhat less true in the rare case of providing fundamental global infrastructure), neither the traditional “Dev” nor “Ops” are what they were, even five years ago.
Is DevOps still relevant?
Why do we need to ask this question? What we are concerned about is whether the underlying business problems that DevOps addresses are actually likely to be solved by a combination of AI and PaaS. So let’s explore that.
PaaS Providers have absorbed much of the operational complexity inherent in cloud (let alone on-prem). A business no longer needs deep expertise in server configuration, network topology, or infrastructure scaling, and any time previously spent on building and maintaining infrastructure can now be redeployed. Deployment bottlenecks and manual process problems largely disappear. It becomes straightforward, for example, to release as often as you like, with low risk. From a strategic perspective, modern PaaS is genuinely transformative because operational costs now scale more linearly with usage rather than requiring upfront capacity planning and specialist teams.
On the other hand, the strategic problems around speed-to-market and cost of change depend on more than just infrastructure deployment. Even with AI generating code and PaaS handling deployment, someone still needs to define what to build, validate that it works as intended, monitor how it performs in production, and understand why things fail. The feedback loop problem that DevOps addresses hasn’t disappeared; it has shifted to understanding whether AI-generated solutions meet business requirements and perform acceptably under real conditions.
If AI generates code that the business doesn’t fully understand, and PaaS abstracts the runtime environment, the organisation loses detailed knowledge of its own systems. Arguably, this creates strategic risk. I say “arguably” because, for example, diagnosis of the internals of PaaS systems is not a relevant capability. Good PaaS providers are extremely adept at fixing issues in their platforms, so much so that I have witnessed one platform recovering faster from an AWS outage than AWS themselves. Diagnosis of the internals of AI-generated software is similar, as is the fear of risk around its “black box” nature. Without going too far into the technical details of either platforms or AI-generated code, the important factor is for technical teams to be able to understand in detail what the code and platform are doing, but less how they do it.
From a business strategy perspective, dependencies on external providers increase. The business may discover it has less ability to differentiate or optimise based purely on technical quality factors. If there’s a high quality foundational LLM, and a high quality PaaS (which there is, in both cases), everyone at a given level of the market will take advantage – there are no barriers other than the usual factors of organisational transformation and investment case.
Where there is an important differentiation in business strategy is in understanding the critical path between idea and customer value. This critical path is more easily travelled, more efficiently, through these new technologies.
What next for DevOps, then?
DevOps represented an organisational capability: the ability to move from concept to production quickly and reliably. If that capability is now outsourced to AI and PaaS providers, what does the business retain? Perhaps just product definition and business logic. But the word “just” is doing a lot of heavy lifting – effective product definition and business logic have always been hard to get right, and that hasn’t changed. We are now, though, more able to focus on those hard aspects of business strategy.
The original problems DevOps addressed were symptoms of a more fundamental issue – the gap between strategic intent and operational execution. DevOps closed that gap by integrating the teams responsible for building and running software. If AI and PaaS genuinely eliminate that gap, DevOps becomes irrelevant. But if they simply relocate it – for instance, creating a new gap between business requirements and AI interpretation, or between application behaviour and platform constraints – then similar integration challenges resurface, but with different participants.
DevOps as a set of practices (continuous integration pipelines, infrastructure as code, containerisation) is largely obsolete. AI and PaaS providers have absorbed most of that technical work. In that sense, DevOps is dead.
What remains alive is the strategic capability DevOps represented: the ability to move quickly from business decision to customer outcome with high reliability and low coordination cost. That capability still requires deliberate organisational design.
With AI and PaaS, the coordination problem shifts rather than disappears. Someone must still:
- Translate business requirements into constraints that AI can work within
- Validate that generated solutions meet actual needs, not just stated specifications
- Understand system behaviour well enough to diagnose failures and optimise performance
- Maintain sufficient platform knowledge to avoid unacceptable lock-in or capability gaps
- Integrate monitoring and feedback so the business learns what actually works
If these responsibilities fragment across business analysts, AI prompt engineers, platform specialists, and product managers with no shared ownership of outcomes, you recreate the original DevOps problem. The silos just have different names.
I’m proposing that the organisations that succeed will be those that deliberately design for integration between business intent, AI-generated implementation, and platform execution. They’ll ensure someone owns the complete path from decision to customer value, with the authority and capability to intervene anywhere along it.
So – call it what you like, but that’s the same integration challenge DevOps originally solved. Different tools, same strategic requirement. DevOps is dead. Long live DevOps.
