What Is an AI Engineer?

An AI engineer builds software products whose core behavior comes from a model somebody else trained. You do not own the weights. You own everything that decides whether the weights produce something a user can rely on: the context you assemble, the retrieval that finds it, the tools the model is allowed to call, the evaluation that tells you if a change helped, and the serving path that keeps it fast and affordable.

The compressed version: the model is a component, and the job is the system around it. A frontier model is roughly the same for you and your competitor. The retrieval quality, the eval harness, the guardrails, and the cost per resolved task are not. That is where the engineering lives, and that is what the title describes.

Every serious AI feature runs into the same wall. The demo works. Then real inputs arrive and the failure modes are not the ones the model card warned you about: the retrieved chunks are technically relevant and practically useless, the agent loops, the JSON is malformed once every four hundred calls, the p95 latency triples when the context window fills, and nobody can say whether last week's prompt change made things better or just different.

Closing that gap is the AI engineer's actual work. It means treating the model as a probabilistic dependency and engineering around it: retrieval that is measured with recall@k rather than guessed at, structured output enforced with constrained decoding or schema validation and a retry path, a golden set with labeled failures that you run before every merge, caching and prompt compaction because tokens are money, and a fallback for when the provider degrades.

The distinguishing habit of a good AI engineer is measurement. Most people ship prompts by vibes. The engineers who get promoted ship them against a suite, know their offline metrics correlate (or do not) with the online outcome they care about, and can name the number that moved.

An ML engineer builds models from data. Features, training runs, loss curves, offline metrics, distribution shift, retraining pipelines. The center of gravity is the dataset and the training loop. An AI engineer builds products from models. The center of gravity is the application boundary: what goes into the context window, what comes out, what happens when the output is wrong.

A software engineer builds deterministic systems. Given the same input, the same output, and the test suite tells you if you broke something. The AI engineer's system is not deterministic, so the safety net has to change shape: not unit tests alone but evals, not a pass/fail assertion but a distribution of scores, not a stack trace but a trace of the whole chain with the retrieved documents and tool calls attached.

The line blurs at the edges, and it should. Plenty of AI engineers fine-tune. Plenty of ML engineers ship LLM features. Titles vary company to company, so read the responsibilities, not the header. But if the posting spends its bullets on RAG, agents, evals, and latency, you are looking at an AI engineering role even if it says ML engineer on the door.

Not a researcher. You will read papers and you will steal ideas from them, but you are not going to publish, and the interview will not test whether you can derive an attention gradient by hand.

Not a prompt engineer. Prompting is a technique inside the job, roughly the way SQL is a technique inside data engineering. If prompting is all you do, you are not doing the part of the role that pays, which is the system that keeps the prompt honest in production.

Not a wrapper builder, whatever the internet says. The commodity part is the API call. The non-commodity part is the data pipeline that keeps the index fresh, the evaluation that catches a regression before a customer does, and the serving architecture that keeps unit economics from eating the product. Those are ordinary hard engineering problems wearing a new hat.