The applied AI engineer is a reliability engineer

What is an applied AI engineer? The title shows up in job postings everywhere now, often beside or instead of “AI engineer” and “LLM engineer,” and the first answer is that the market has not fully settled the words. But the role underneath the words is real and it is specific, and here is the sharpest one-line version: an applied AI engineer builds reliable production systems on top of foundation models they did not train.

Every part of that sentence is doing work. Builds: this is an engineering job, shipping software, not research. Production systems: the output is something real users depend on, not a notebook or a demo. On top of foundation models they did not train: the model, Claude or another, is a given, a component, not the thing being created. The applied AI engineer’s craft is everything around the model, the system that turns a capable but unpredictable component into something dependable.

That description, model as component, raises the real question this post is about. If the model is a given, what exactly is the engineer building, and what makes one good at it. Those have answers.

What an applied AI engineer does

Take the role apart into the actual work, because the day-to-day is concrete. An applied AI engineer wires a foundation model into a product: the API calls, the prompts, the handling of the model’s output. They build retrieval, so the model can answer from a company’s own data rather than only its training. They build agents, systems where the model plans and calls tools to get something done, work Anthropic documents in depth in its guide to building effective agents. They build evaluations, the test suites that measure whether the AI system is getting better or quietly getting worse. And they own the unglamorous production concerns, latency, cost, error handling, the behavior of the thing at three in the morning. None of that is model research. All of it is software engineering with a probabilistic component at the center, and that probabilistic component is precisely what makes it a distinct discipline rather than ordinary backend work.

The probabilistic part deserves a sentence on its own, because it is the whole reason the role exists. Ordinary software is deterministic: the same input gives the same output, and a test that passes today passes tomorrow. A foundation model is not like that. The same prompt can give different answers, a system that worked on a hundred examples can fail on the hundred-and-first, and “correct” becomes a distribution rather than a guarantee. An applied AI engineer is, more than anything, a software engineer who has learned to build dependable things out of a component that does not behave deterministically. That is a real and learnable craft, and it is not the craft that ordinary backend engineering teaches.

Treating the model as a given changes the work in a way worth making explicit. You do not control the model’s weights, its training, or, mostly, its quirks. You control everything else: what context it receives, what tools it can call, how its output is checked, what happens when it returns something unusable. So the applied AI engineer’s influence is all in the wrapper, the layer of software and prompts and checks around the model. A great applied AI engineer can make a mid-tier model dependable through good wrapping. A weak one can make a frontier model flaky through bad wrapping. The component is fixed; the engineering around it is where the quality is won or lost.

Not an ML engineer, not a researcher

The clearest way to fix the role is by contrast with the two it gets confused with. An AI researcher pushes the frontier: new architectures, new training methods, the science of making models more capable. A machine-learning engineer works at the model layer, training and tuning and deploying models, often on a company’s proprietary data. The applied AI engineer works at the application layer, above both: the models already exist, and the job is to build dependable systems with them. A useful shorthand is that the ML engineer’s deliverable is a model and the applied AI engineer’s deliverable is a system. There is a fourth role nearby, the forward-deployed engineer, who does similar building but embedded directly with a customer. These are not a ranking, and an AI-era career can move between them. They are different jobs, and a company that hires for one expecting another is setting up a bad fit.

The confusion is not harmless, which is why the distinction is worth this much care. A company that needs LLM features shipped into its product, and hires a research-minded ML specialist for it, often gets someone who wants to fine-tune a model when an afternoon of prompt and retrieval work would have done the job. A company that needs a model trained on its proprietary data, and hires an applied AI engineer for it, gets someone strong at systems and light on the statistics the task actually needs. Neither hire is bad. Both are misfiled. The titles overlap enough in job postings that matching the person to the layer, model layer or application layer, is the part a hiring manager has to get right by reading past the title.

It is worth noticing why this role appeared at all, because it explains the shape of it. For most of machine learning’s history, using AI meant building a model, which meant ML engineers and researchers, because there was no model until you made one. Foundation models broke that. Once a capable general model exists behind an API, the scarce skill is no longer training one; it is building well with one. The applied AI engineer is the role that scarcity created. That also explains why the title is unsettled: the job is only a few years old as a distinct thing, younger than the people doing it, and the labels are still catching up to a role the work invented before the market named it.

The skill cluster

The skills follow from the work, and they cluster into four. Prompt engineering: not the trivial version, but the disciplined kind, getting reliable behavior out of a model through careful instruction and structure. Retrieval: building the systems that feed a model the right context from a body of data at the right moment. Agents: composing models, tools, and control flow into something that completes multi-step tasks, the territory of the Claude Agent SDK and similar tooling. And evaluation: building the tests and eval harnesses that turn a vague sense of whether the AI is working into a measured one. Underneath all four sits ordinary software competence: an applied AI engineer is a software engineer first, usually fluent in Python, comfortable with APIs and production systems. The four AI-specific skills are what they add on top of that base, not a replacement for it.

Of the four, evaluation is the one most teams underrate and the one that most reliably marks a serious applied AI engineer. Anyone can wire a model into a product and watch it work in a demo. Knowing whether it still works, across the messy range of real inputs, after the prompt was changed last week, is a measurement problem, and measurement is engineering. An applied AI engineer who builds real eval suites is an engineer who can tell you, with evidence, whether the system is improving. One who does not is flying on impressions. That single habit separates a lot of the field.

One warning belongs with the skill cluster. The four AI skills are visible and fashionable, and it is possible to hire someone who has them and cannot really engineer, who can prompt and wire and demo but writes software that does not hold up. That is the worst version of an applied AI engineer, because the AI part was always the smaller half. The systems an applied AI engineer ships still need sound structure, error handling, tests, and observability, the ordinary disciplines, and a probabilistic component makes those more important, not less. When the AI skills look strong but the underlying software craft is thin, that is a red flag, not a near miss. The base is not optional.

The trait that separates the good ones

Skills can be listed and learned. The trait that separates a good applied AI engineer from a merely trained one cannot be put on a checklist as easily, and it is the deeper answer this post has been building toward. It is failure-mode thinking. A foundation model is a probabilistic component: capable, and also capable of being wrong in ways ordinary software is not. It hallucinates. It can be steered by hostile input it reads. It behaves differently on the input you never tested. An engineer who has actually shipped and operated AI systems reasons about those failure modes first, before the capabilities. They ask how does this break before they ask what can this do. That instinct is why Anthropic’s own guidance on building agents keeps returning to simplicity and to starting with the least complex thing that works. The good applied AI engineer treats the model’s unreliability as the central design problem, not an edge case to patch later.

This is the thing I watch for, both when I am teaching this material and when a hiring conversation turns to who can actually do the job. A candidate who opens with everything the model can do is describing a demo. A candidate who opens with how they would catch the model being wrong is describing a production system. The second mindset is rarer, it is harder to teach than any of the four skills, and it is the one that correlates with AI systems that survive contact with real users. If you are building an AI team and want help telling those two candidates apart, Blue Sheen works with companies on exactly that.

A concrete picture helps. Suppose the task is an AI feature that answers customer questions from a company’s help docs. The capabilities-first engineer builds it, sees it answer ten questions well, and ships. The failure-mode-first engineer builds the same thing and then asks a different set of questions. What happens when the docs do not contain the answer, does it say so or invent one? What happens when the question is hostile, an attempt to make it reveal something it should not? What happens at the volume of a real launch day? Same feature, same model, same four skills. The difference is in which questions the engineer asked before shipping, and that difference is what separates a feature that survives from one that becomes an incident.

Spotting and growing one

So how do you find or grow one? Spotting an applied AI engineer is less about a credential than about evidence of shipped, operated systems. The strongest signal is a candidate who can talk concretely about something they built that ran in production and what went wrong with it, because failure-mode thinking is mostly scar tissue from having been burned. A polished demo proves far less. Growing one is possible and worth doing: a strong software engineer with real curiosity can learn the four skills, and the failure-mode instinct develops fastest by giving people real systems to operate, not just to build, so they feel the 3 a.m. behavior themselves. That instinct grows alongside the kind of disciplined practice Anthropic distills in its Claude Code best practices. For a company assembling this capability, the head-of-AI hiring decision sets the tone, because the person leading the function decides whether the org rewards demos or rewards systems that hold up.

Who actually becomes a strong applied AI engineer? In practice, most arrive from software engineering rather than from data science, which surprises people who assume AI work starts with statistics. It makes sense once you see the role clearly: the job is dependable systems, and a backend engineer already knows how to build dependable systems, so they are adding a probabilistic component to a craft they have. The data scientist is often adding the systems craft to statistical knowledge, a longer path for this particular job. Neither origin is required. But if you are a software engineer wondering whether this role is reachable, it is closer than it looks, and the four skills are the visible, learnable part of the gap.

Step back to the question this started with. What is an applied AI engineer? The shortest true answer is the one to keep: a software engineer who builds reliable systems on models they did not train, and whose defining skill is thinking about how those systems fail. The title will keep shifting, AI engineer, LLM engineer, applied AI engineer, the labels are not settled and may not settle soon. The role under the labels is settling, though, and it is one of the most in-demand and best-paid jobs in software right now for a plain reason. Turning a brilliant, unreliable model into something a business can depend on is hard, specific work, and the people who can do it well are still rare.