PathweysAI Engineer Track · Orientation
Understand AI Engineer
Understand AI Engineer
An AI engineer builds products on top of large language models, wiring prompts, retrieval, tools, and evaluation into something a user can rely on. It is an applied, product-facing role: closer to a backend or product engineer who works with models than to a research scientist who trains them.
Why this matters
That distinction is worth having clear before anything else, because AI covers a wide range of jobs with very different day-to-day work. This mental map matters before going deeper into how the models themselves actually work.
What is an AI engineer
An AI engineer builds products on top of large language models, wiring prompts, retrieval, tools, and evaluation into something a user can actually rely on, an applied, product-facing role closer to a backend or product engineer who happens to work with models than to a research scientist who trains them. The distinction matters because AI spans a genuinely huge range of jobs. A research scientist improves the model itself, its architecture, its training, fine-tuning at scale. An ML engineer builds and operates the infrastructure that serves and trains models. An AI engineer instead takes an existing model, usually reached through an API rather than trained in-house, and builds the entire system around it: prompting, context and retrieval, tool use, guardrails, and evaluation, then ships and iterates on it in production. Day to day, concretely, this looks like writing and testing prompts, building a retrieval pipeline so the model has the right context, wiring up tools and function calls so the model can take real actions, adding evaluations so a change can be judged as better or worse before it reaches users, and watching cost, latency, and failure modes once the system is actually live.
You do not need to train a model to be an AI engineer; you need to be good at building reliable software around one. The rest of this track teaches exactly that, starting from how the model itself works underneath the API you call.
What an AI engineer actually does day to day
Most of an AI engineer's week is not actually spent talking to a model directly, it is spent on the same kind of engineering work any product role does, with a model sitting in the loop somewhere. Prompting and context design covers both iterating on prompts themselves and, more often the genuinely harder problem, getting the right information in front of the model at the right time through retrieval, chunking, formatting, and trimming context to fit its budget while staying relevant. Tool use and orchestration covers wiring the model up to real actions, calling an API, querying a database, running code, and handling the resulting loop where the model asks for a tool, the tool runs, and the result goes back to the model. Evaluation matters specifically because model output is non-deterministic, which means a prompt or pipeline change cannot just be eyeballed once and shipped, it needs a real test set and scoring so a change can be judged as better or worse before it ever reaches a real user. And cost, latency, and reliability work covers the fact that every call costs real money and real time, and that models occasionally fail, hallucinate, or return malformed output, which makes budgeting tokens, caching, retries, and fallbacks ordinary parts of the job rather than rare edge cases.
The job is applied software engineering with an unusually unreliable, unusually powerful component sitting in the middle of the system. The rest of this curriculum builds the mental model for that component, starting with tokens, the unit everything else ends up measured in.
Worked example
A team hiring for 'an AI role' to train a custom model from scratch is actually looking for an ML engineer or research scientist, while a team that wants an existing model like Claude or GPT wired into their product with retrieval, tools, and evaluation around it is specifically looking for an AI engineer, a distinction that changes both who gets hired and what their first month of work actually looks like.
Practice
Write down, for a product you use or are building, which of the four roles, research scientist, ML engineer, AI engineer, or none of these, is actually responsible for a specific piece of its AI behavior. Confirm your answer by checking whether that piece of work involves training weights, serving infrastructure, or building the system around an existing model.
Interview checks
- Why does an AI engineer typically not need to train a model from scratch to do the job well?
- What specifically distinguishes an AI engineer's day-to-day work from a research scientist's?
- Why does evaluation become a required part of the job once model output is non-deterministic?
Common failure modes
- Assuming 'AI engineer' means training or fine-tuning models at scale, when the role is actually built around an existing model reached through an API.
- Treating prompting as the whole job, when retrieval, tool use, evaluation, and operational concerns make up the majority of the real work.
- Shipping a prompt or pipeline change based on how it looked in a handful of manual tests, skipping real evaluation entirely.
Expert signals
Being able to state clearly, in a sentence, how an AI engineer's day-to-day work differs from a research scientist's and from an ML engineer's, and recognizing that the job's real center of gravity is retrieval, tool use, evaluation, and production operations rather than prompt wording alone, is the orientation this entire curriculum is built to establish before going any deeper.
Confidence
high