AI Reliability Engineer (AIRE): The Highest-Paying Role Nobody's Training For

Anthropic posted a Staff Software Engineer role for AI Reliability at $485K. Postman is paying $250-270K for an MTS lead on AI reliability and monitoring. OpenAI has a Staff Security Reliability Engineer role at $293-385K. Anthropic's London office is offering £325-390K for the same kind of work. None of these are ML research roles. They're operations roles, dressed up for a world where the thing you're operating doesn't behave the same way twice.

That's the part worth sitting with before we get into skills and job titles: this isn't a new invention, it's the SRE job growing a new organ to deal with non-determinism.

What AI reliability engineering actually is

An AI Reliability Engineer (AIRE) does what a Site Reliability Engineer does — uptime, latency, throughput, incident response — except the system they're keeping alive doesn't fail the way normal software fails.

A Linux service is either up or down. There's no in-between state worth naming. An LLM-backed service can be fully "up" — 200 status codes across the board, GPUs healthy, latency within SLO — and still be quietly wrong. It hallucinates. It retrieves the wrong document while every health check passes. An agent loops through fourteen tool calls and burns your token budget to deliver a confidently incorrect answer. Standard infrastructure monitoring has no concept of "semantically wrong," and that gap is exactly the job.

If you want the compressed version: an AIRE detects failure your dashboards can't see, defends against it with guardrails and rollback, and delivers on the same uptime/latency/incident-response bar a classic SRE always has.

Is this a real role, or a title someone made up to sound cutting-edge

Real, but not new in the way it sounds. It's a lineage, and each step in it happened because the layer underneath the job changed.

System administrator in the 1990s became Site Reliability Engineer once Google decided in 2003 that keeping things up at scale required real programming chops on top of ops knowledge. SRE is now splitting into AIRE because the systems underneath have gone from deterministic to non-deterministic. Same evolutionary pressure, different decade.

You can see the same pattern from a completely different angle if you look at what job titles have actually been called over the last 25 years: build engineer, then DevOps once Patrick Debois coined the term in 2009, then DevSecOps around 2012 once security got folded in, then MLOps around 2015 as ML training pipelines needed their own ops discipline, then AIOps around 2019, then XOps around 2023 as a catch-all for the previous five acronyms. The job is basically the same job with a different adjective bolted onto the front, and the adjective changes every time the underlying technology stack does. What's changed recently is the speed — DevOps to DevSecOps took about three years, MLOps to AIOps took about four, and now the cycle's compressing further.

The market data backs up "real, still forming" rather than "hype." The AIOps market went from $8.91B in 2024 to $11.16B in 2026, and one forecast puts it at $32.56B by 2029 — a 30.7% compound annual growth rate. Job-posting analysis of SRE listings in 2026 found AI Agents experience is now the single most-requested explicit AI skill in SRE postings, ahead of MLOps and AIOps combined. That's a market reclassifying an existing job, not inventing one from scratch.

What the job description actually breaks down to

Three buckets, and none of them are exotic once you've done real production work.

Detect. Catch problems before the customer does. This means defining SLOs, SLIs, and error budgets like any SRE would — but also model quality signals specific to AI systems: drift detection, hallucination rate, retrieval accuracy, eval scores. Roughly 89% of teams running LLM systems in production now use some form of agent observability, but only 52.4% run offline evals and 37.3% run online evals — which tells you evals are still the part most teams haven't operationalized. That gap is where the job lives.

Defend. Guardrails, safe rollback, isolation between components, deployment policies that account for the fact that a "bad deploy" for an LLM system might mean the model got worse at a task nobody was testing for.

Deliver. The unglamorous, non-negotiable part — uptime, latency, capacity planning, incident command, the 2 AM page. GPU operations. Toil reduction. This is where classic SRE fundamentals carry over almost unchanged.

The skill that actually gets you hired (and it's not the one you'd guess)

Job-description analysis across 11 open AIRE-adjacent roles at companies including Anthropic, OpenAI, Postman, and Black Forest Labs found the top requirement, appearing in 9 out of 11 postings, wasn't Kubernetes or Golang. It was comfort with ambiguity and ownership. Communication and cross-team influence came right after it. Observability, AI/ML workload monitoring, and incident response experience rounded out the top tier.

Kubernetes, distributed systems, cloud platforms, Golang/C++/Python, infrastructure as code, Linux fundamentals, chaos engineering — all of it showed up too, but lower down the list. That's the uncomfortable finding here: past a certain seniority, the technical checklist is table stakes, not the differentiator. It gets you shortlisted. It doesn't get you the offer.

Here's the skill breakdown split by what's baseline versus what's the actual AI-specific layer:

Tooling-wise, the observability layer for AI systems has consolidated around a handful of platforms rather than being generic infra monitoring with AI bolted on. Langfuse leads on the open-source, self-hosted side — full tracing, prompt management, and evals, MIT-licensed core, recently acquired by ClickHouse. LangSmith is the default if you're already on LangChain or LangGraph. Arize Phoenix wins on eval rigor, particularly for RAG-specific checks like retrieval relevance and faithfulness. None of this replaces Datadog or Grafana — it sits on top, because standard APM genuinely can't see "the retrieval step returned the wrong document while every HTTP status read 200."

How to actually get there from where you are now

The advice from people already doing adjacent work is consistent, and it's simpler than it sounds: don't start a new track, add an AI layer to the track you're already on.

If you're doing DevOps work today, the question isn't "should I learn a new stack," it's "can AI auto-diagnose a pipeline failure and try a fix before paging a human." If you're already doing observability, the extension is self-healing with an AI component in the loop, not throwing out your existing tooling. If you've got a project you actually know deep down — not a tutorial project, one where you've hit real production edge cases — that's the one to bolt AI reliability practices onto, because credibility on a resume comes from depth on one thing, not breadth across five.

Concretely, that means:

• Learn evals properly — not "I tested it a few times," but structured eval sets, LLM-as-judge patterns, regression testing for non-deterministic output
• Pick one observability tool (Langfuse is the reasonable default for self-hosted, LangSmith if you're LangChain-native) and actually instrument a project with it
• If your current work touches RAG, agents, or any LLM-in-the-loop system, start tracking drift and hallucination rate as first-class metrics, the same way you'd track p99 latency
• If your org has any HPC or GPU infrastructure work, get close to it — the "deliver" bucket above assumes GPU operations familiarity, and it's the part fewer developers have hands-on time with

One honest caveat: an IBM Research benchmark (ITBench, ICML 2025) found current AI models autonomously resolved only 13.8% of real-world IT operations scenarios spanning SRE, FinOps, and CISO domains. AI is useful here as a correlation and triage assistant right now, not as a replacement for the judgment call an experienced engineer makes at 2 AM. That's worth knowing before you build a pitch around "AI will handle the incidents" — it won't, not yet, and the job exists precisely because it won't.

If you're coming from a RAG, agent-engineering, or general full-stack background with real DevOps exposure — Docker, Kubernetes, CI/CD, some Linux ops experience — you're not starting from zero on this. What's usually missing is the formal observability and SLO layer, and that's a few weeks of deliberate practice, not a career change.