Short answer: no, and the official projections show something more interesting than a simple yes or no. The occupations closest to DevOps are moving in opposite directions. Network and computer systems administrators are projected to decline 4 percent between 2025 and 2035, losing about 13,200 positions, while information security analysts grow 21 percent with 40,600 additional jobs and software developers, quality assurance analysts and testers grow 10 percent with 185,400 more. Against 3.5 percent projected across all employment, that spread tells you exactly which parts of infrastructure work are being absorbed.
The Divergence Is the Answer
Traditional systems administration, meaning maintaining servers, applying patches, managing accounts and responding to tickets, is declining. Cloud platforms absorbed most of it and configuration automation absorbed the rest. Generative tooling accelerates a trend that was already well underway.
Security engineering is growing sharply. Every new deployment surface, every automated pipeline and every model integration expands the attack surface, and someone has to defend it.
Software engineering broadly is growing. DevOps sits inside this, because modern infrastructure work is software: pipelines, infrastructure definitions, policies as code, and the platforms other engineers build on.
The practical reading is that the ticket-handling half of infrastructure work is disappearing and the engineering half is expanding. A DevOps engineer’s exposure depends entirely on which half describes their week.
Where Automation Bites and Where It Does Not
| Activity | Effect | What remains |
|---|---|---|
| Writing pipeline configuration | Much faster | Deciding what the pipeline should enforce |
| Infrastructure as code authoring | Much faster | Architecture and blast-radius decisions |
| Routine patching and updates | Largely automated | Judging what cannot be updated safely |
| Log analysis and anomaly detection | Genuinely improved | Deciding what an anomaly means |
| Incident response | Assisted | Diagnosis, coordination, judgement under pressure |
| Capacity and cost management | Assisted | Architecture and commercial trade-offs |
| Security policy | Assisted drafting | Threat modelling and enforcement decisions |
| Post-incident review | Drafting assisted | Honest root-cause analysis |
| On-call at 3am | Not automated | All of it |
The pattern is consistent with the rest of software engineering. Authoring is compressed. Operating a live system under uncertainty is not.
The incident that shows the boundary
Latency on a service triples. No deployment went out. No alert fired on any component. Error rates are normal. Users are complaining.
Automated tooling helps immediately and only partially. It surfaces the correlated metrics, retrieves the recent change log, and suggests plausible causes ranked by frequency in similar systems. That is genuinely a time saving, and it is not a diagnosis.
The engineer’s work is forming hypotheses that depend on knowing this system. A connection pool that has been marginal for months. A dependency whose owning team deploys on Thursdays without announcing it. A caching layer that degrades gracefully in a way that hides the real failure. A database that has been slowly approaching a threshold nobody set an alert on. A change in traffic pattern from one large customer.
Then there is the judgement about what to do while diagnosing. Roll back a deployment that probably is not the cause, because it is cheap and fast. Scale up to buy time at a known cost. Shed load from one customer to protect everyone else. Wake up the database team, or wait twenty minutes for more information.
Those decisions have commercial and organisational consequences and are made under time pressure with incomplete data. They are the job, and they are not close to automated.
The Review Problem Nobody Has Solved
There is a specific risk in this discipline that deserves more attention than it gets, because it is where generated code does the most damage.
Application code that is wrong usually fails visibly. A test breaks, an endpoint returns an error, a user reports something. Infrastructure code that is wrong frequently succeeds. The resources are created, the deployment completes, and everything works.
The problem surfaces later. A storage bucket was created without the intended access restriction. A security group allows a wider range than the author believed. A role was granted a broad permission because that was the pattern most represented in training data. A resource is configured so that a routine change will destroy and recreate it, taking the data with it.
None of these produces an error at apply time. All of them produce an incident eventually, and by then nobody remembers why the configuration looks like that.
The defence is unglamorous and effective: automated policy checks that reject non-compliant configuration before it is applied, mandatory review of anything touching identity or network exposure, and plan output that a human actually reads rather than skims. Teams that adopted generation aggressively without adding these controls are the ones now discovering the consequences.
This is also why the security projection is so strong. Faster infrastructure authoring without stronger guardrails produces exactly the class of misconfiguration that security engineers spend their time finding.
What to Know Before You Draw Conclusions
More automation means more systems to operate. Faster authoring produces more services, more pipelines and more infrastructure. The operational surface grows even as each piece takes less time to build.
Security is the fastest growing adjacent discipline. A 21 percent projection for information security analysts is among the strongest in the economy, and DevOps engineers are unusually well placed to move into it.
Generated infrastructure code carries real risk. Configuration that looks correct and quietly opens a permission, disables encryption or removes a constraint is the classic failure mode. These errors do not raise exceptions; they create incidents later.
Exposure measures are not employment forecasts. BLS published AI exposure categories with the 2025-35 projections and states plainly that exposure “does not imply job loss, productivity gains, automation probability, or wage effects.” Technical roles score high while the projections for engineering occupations point sharply up.
Platform engineering is where the work consolidated. Many organisations have moved from embedded DevOps engineers to platform teams building internal tooling with other engineers as their users. That is a software product role rather than an operations one, and it is growing while the operations-only version of the job contracts.
Where the Work Is Growing
- Platform engineering. Building the internal platform other engineers deploy on, treating it as a product with users.
- Security engineering. Supply chain security, secrets management, identity and workload isolation.
- Reliability engineering. Error budgets, incident practice, and the organisational discipline of running systems at scale without burning out the people on call.
- Cost engineering. Cloud and inference spend have become board-level concerns, and comparatively few engineers can genuinely reduce them without degrading the service.
- AI infrastructure. Serving models, managing accelerator capacity, and handling inference cost and latency at scale. A new specialism with very thin supply and unusually strong compensation as a result.
A Decision Framework for DevOps Engineers
- Mostly tickets, patching and account management. The most exposed position, and the one the declining projection describes. Move toward platform work or security within the year.
- Writing pipelines and infrastructure code. Moderately exposed on authoring, secure on judgement. Your differentiator is architecture and blast-radius thinking rather than syntax.
- Platform or reliability engineer. Strong position. The growth area is treating the platform as a product and reducing the cognitive load on other teams.
- Considering a specialism. Security and AI infrastructure are the two with the strongest demand and the thinnest supply.
The test that applies across all four: when something breaks in a way nobody anticipated, are you the person who fixes it? That is the durable part of this discipline and it is the part organisations pay most for.
Common mistakes right now
- Applying generated infrastructure code without reviewing permissions, network exposure and deletion behaviour.
- Measuring output in pipelines shipped rather than in incidents avoided and toil removed.
- Treating an automated root-cause suggestion as a conclusion rather than as a hypothesis.
- Neglecting security, which is both the fastest growing adjacent field and the most common way infrastructure work becomes a crisis.
Building the Fluency the New Infrastructure Work Requires
Infrastructure teams are increasingly asked to run AI workloads: serving models, managing accelerator capacity, controlling inference cost, and building the retrieval and evaluation infrastructure around them. That work sits naturally with DevOps engineers and requires understanding things the discipline has not traditionally covered.
Knowing why inference cost behaves the way it does, what determines latency, how model updates change behaviour downstream, and how to monitor a system whose output is probabilistic rather than deterministic is a distinct skill set. Learning it in a structured sequence gives you the concepts rather than one platform’s abstractions, which matters because this tooling is turning over faster than anything else in infrastructure. A certificate alongside your operational experience makes the capability visible when a company is staffing its AI platform team. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
FAQ
Is DevOps a dying career?
Will AI write all the infrastructure code?
What should a DevOps engineer learn next?
Are agentic tools going to run production systems?
Will platform teams shrink?
Does AI help with incidents?
Your Next Step
Look at your last five incidents and separate what a tool could have surfaced from what required knowing your systems. The second column is your actual value, and it is usually larger than expected. Then pick one of the two growth specialisms, security or AI infrastructure, and take ownership of something real in it this quarter, because both are hiring faster than the market can supply and your existing operational experience is most of what they need.