LO
Get told when a verified record lands on this occupation →
DevOps / platform / SRE engineer
Keeps the thing running and makes it possible for others to ship: builds the pipelines and the infrastructure, and is who gets woken up when production breaks.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Covers infrastructure, delivery pipelines and production reliability. It does not cover desktop and end-user support, which is a separate occupation here, and it does not cover security operations. The single biggest variable is whether you operate systems somebody else designed or design the systems others operate, because the exposure of those two is not the same.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Writing the configuration
Automating≈ Platform inferenceInfrastructure as code, pipeline definitions, manifests — the large volume of structured text that describes what should exist.
This is code with a machine-checkable outcome — it applies cleanly or it errors — which is the property that lets a model try, fail and retry without supervision. It is also famously verbose and repetitive, so the volume being drafted is large and the review is quick.
Faster configuration means more configuration, not less work: every resource created is a resource somebody has to keep, secure and eventually delete, and the hours move from writing to untangling. Untangling is invisible on a roadmap, which is why this is the task most likely to look like a saving and behave like a debt.
Being woken up
Still human-led≈ Platform inferenceDeciding at 3 a.m., under time pressure and with partial information, what to roll back, what to degrade and what to tell people while it is still broken.
Automated remediation exists and handles the failures somebody anticipated; an incident is by definition the one nobody did. The decision is about acceptable damage rather than correct answers — which customer-facing degradation is tolerable for twenty minutes — and that is a business judgement carried by a person who will be asked about it afterwards.
The decision staying human says nothing about how many people are on the rota. The common design is fewer engineers covering more services with better automation, which keeps every task intact and makes the on-call worse — and the sustainability of that is a staffing question that no automation metric captures.
What it costs and why
Being augmented≈ Platform inferenceExplaining a cloud bill, finding the thing that tripled it, and deciding which inefficiency is worth an engineer's week to fix.
Finding the anomaly is analysis and tools do it well; deciding what to do about it is a trade-off between engineering time, risk and money that depends on what the company is trying to do this quarter. The first half has got much cheaper and the second has not.
Cheap analysis raises the expectation rather than lowering the work: once a dashboard can name the top ten wasteful resources, somebody has to justify each one that is still there. The task shifts from investigation to explanation, and explanation is a meeting.
Deciding how it should be built
Still human-led≈ Platform inferenceChoosing the architecture, the failure modes you are willing to have, and what the team will still be able to operate in two years.
This is the task with no automatic referee in the whole occupation: whether a design was right is discovered eighteen months later, by which time the person who chose has usually left. It depends on knowing this team's capacity and this company's tolerance, neither of which is in any repository.
Being the safest task is also being the smallest: in most teams design decisions are a few days a quarter, and the rest of the week is the work that is being drafted for you. A role can be secure in its most senior task and still lose most of its hours.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
The climb is configuration: infrastructure code either applies cleanly or errors, and a machine-checkable outcome is what lets a model try, fail and retry unattended. It is also verbose and repetitive, so the volume drafted is large and the review is quick. The curve flattens at the on-call, which has no mechanism to move — an incident is by definition the failure nobody anticipated, and the call is about acceptable damage rather than a correct answer. Two things the height hides: faster configuration produces more configuration, so hours move from writing to untangling, which is invisible on a roadmap; and the change that reaches people here is services-per-engineer, which thins the rota without removing a single task.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
The rung that used to hire juniors — writing and wiring configuration — is the one with the clearest mechanism pointed at it, because it is code with a machine-checkable outcome. What that leaves for a beginner is the on-call, which is the hardest part and the one you were supposed to earn. Push to be in incident reviews long before you are on the rota.
Your leverage is the design decision and the incident call, and both are small slices of the week. The risk is not that they get automated, it is that the hours around them get thinned until one engineer covers services no one person can hold in their head. Watch services-per-engineer the way a waiter watches covers-per-server.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Move toward design and away from wiring
The design decision has no automatic referee, which is exactly why no tool can close the loop on it — and it is the part of the job that compounds.
It needs scar tissue: nobody is given architecture decisions without having operated something through a bad year.
Count the hours you spent this week on work where applying it either succeeded or errored. That is the share a loop can already run.
Own the operability of what others build
More configuration being generated means more systems nobody is accountable for, and somebody has to hold the standard for what may be run in production.
It is a standards role, which means saying no to colleagues, and it is only funded after something has already gone wrong.
Pick one service you did not build and try to find who would be paged for it. The time that takes is the size of the problem.
Common questions#
The configuration half is moving and moving fast, because infrastructure code either applies cleanly or errors — a machine-checkable outcome is what lets a model retry unattended. The on-call is not, because an incident is by definition the failure nobody anticipated and the call is about acceptable damage rather than a correct answer. The likely shape is not removal but thinning: fewer engineers covering more services, which keeps every task and makes the rota worse.
No date. Two numbers you can produce yourself say more than any forecast: what share of your week goes to work where applying it either succeeds or errors, and how many services each engineer on your rota is now responsible for. The first is your task exposure; the second is the change that actually reaches people in this job, and it moves quietly a couple of quarters after any tooling lands.
Not usually, and this is the clearest case on the site of a tool that looks like a saving and behaves like a debt. Every resource created is a resource somebody has to keep, secure and eventually delete, so faster configuration produces more configuration rather than less work — the hours move from writing to untangling. Untangling is invisible on a roadmap, which is exactly why it gets budgeted as a saving.
It is the safest task in the occupation and also the smallest. Whether a design was right is discovered eighteen months later, which means there is no automatic referee and therefore no loop a tool can close — but in most teams design decisions are a few days a quarter. A role can be secure in its most senior task and still lose most of its hours, and that gap is the thing to plan around.
Method and sources#
- Assessment date
- 2026-09-14
- Basis of the task judgements
- 0 evidence-backed · 4 platform inference · 0 not enough evidence
- Verified events
- 0