ML Engineer vs AI Engineer vs
Deep Learning Engineer

The ML Engineer is the classic role of the three: the engineer who turns a company's own structured data into predictive models, then keeps those models honest in production.

What an ML engineer builds

• Predictive models on the company's own data. The bread and butter is structured business data: fraud detection, ranking, recommendations, churn prediction, forecasting, and anomaly detection.
• Learned behavior, not hand-written rules. The whole point of the role is replacing brittle rule lists with systems that learn patterns from historical data and generalize to new cases.
• A three-part deliverable. The output is a trained model artifact plus a serving pipeline plus monitoring: all three together, not just a model file handed over the wall.
• Statistics-first math. The required depth is solid statistics and evaluation methodology, with constant feature and label thinking; heavy neural-network math is not the default requirement here.
• Clear litmus answers. Against tab 1's questions: trains models rather than only calling them, lives in structured business data, and delivers a model artifact rather than a product feature.

The day-to-day

• Clean data and engineer features. Most work starts in the data itself: fixing quality issues and turning raw columns into features a model can actually learn from.
• Train and evaluate models. Run experiments, compare candidates, and apply careful evaluation methodology so the offline numbers can be trusted.
• Deploy behind an API. Package the winning model and serve it so product systems can call predictions like any other service.
• Monitor for drift. Watch production behavior, because the world changes and yesterday's accurate model quietly stops matching today's data.
• Automate retraining pipelines. The MLOps side of the job: schedulers, model registries, and experiment tracking that make retraining routine instead of an emergency.

The role at a glance

A week in the life

1. Start in SQL and pandas. Pull fresh data, profile it, and clean the issues that would poison training; unglamorous, but everything downstream depends on it.
2. Build and refine features. Encode the business signal into columns, and think hard about labels so future information cannot leak into the training data.
3. Train, evaluate, and track. Fit candidates with scikit-learn or XGBoost/LightGBM, log every run in MLflow-style experiment tracking, and pick a winner on honest held-out metrics.
4. Ship it behind an API. Containerize with Docker, register the artifact in the model registry, and deploy on the cloud ML platform so callers get predictions, not notebooks.
5. Close the loop. Wire up drift monitoring and the Airflow-style retraining pipeline, because a good week ends with drift caught by the pipeline before users ever see it.

Baseline set. The remaining titles are departures from it: one builds on foundation models someone else trained, the other goes all-in on neural networks. Next up: the AI Engineer, the title that changed its meaning.

The newest title of the three, and the one whose meaning moved. In the LLM era, an AI Engineer usually builds on foundation models that other people trained, and turns them into product features that hold up in production.

What the title means now

• Builds on foundation models. The industry convention today: an AI Engineer ships systems on top of existing models reached through an API, rather than training models from scratch.
• The model is a component, not the project. The engineering happens around it: retrieval to ground answers, tools to take actions, guardrails to contain output, evals to prove it works.
• The deliverable is a feature. The output is an AI-powered feature or agent with evals and monitoring, not a trained model artifact.
• Lightest math, heaviest product and systems. Of the three roles this one asks for the least mathematics and the most backend, API, and product engineering judgment.
• Closest to a normal software job. The stack is model APIs plus ordinary backend skills, which is why this path has the shortest on-ramp for working engineers and testers.

Day-to-day work

• Prompt design. Writing and versioning the instructions that steer the model, and treating every change as something to test.
• RAG pipelines and vector databases. Chunking, embedding, and indexing the company's documents so the model answers from real knowledge instead of guessing.
• Tool-calling agents. Wiring the model to APIs so it can look things up and take actions, then constraining what it is allowed to do.
• Model routing. Sending each request to the model that fits it, so simple work does not pay for premium reasoning capability.
• Guardrails and evals. Input filters, output checks, and LLM-as-judge eval suites that catch regressions when prompts or models change.
• Latency and cost tuning. Watching response times and per-request spend the way a backend engineer watches any other production budget.

The shape of the work

# shape of an AI feature (pseudo-config, not a real vendor file)
model:      hosted foundation model, routed per task
retrieval:  vector database over product docs, best matches into the prompt
tools:      ticket search, order lookup, bug filing (the agent part)
guardrails: input filters, output schema checks, refusal rules
evals:      golden set plus LLM-as-judge, run on every prompt change
budget:     p95 latency and cost per request, tracked like test coverage

At a glance

The train-vs-call divide

• The one-question filter. Ask of any role: do you train models or call them? The answer places the job faster than the title does.
• The training side. Classic ML and DL work: cleaning data, engineering features, running training jobs, shipping a model artifact, watching for drift.
• The calling side. AI engineering: designing prompts and retrieval, orchestrating tools and routing, wrapping guardrails and evals around a hosted model.
• Reliability lives on both sides. Training work monitors drift and silent accuracy decay; calling work monitors evals, latency, and cost. Neither side gets to skip the watching.

Next up is the opposite end of the spectrum: the Deep Learning Engineer, the specialist who designs and trains neural networks like the ones behind those hosted APIs.

The specialist of the three. A Deep Learning Engineer designs and trains neural networks, mostly for unstructured data, and works with the deepest math and the narrowest job market of the three roles.

The specialist inside ML

• A subset of a subset. Deep learning is machine learning done with multi-layer neural networks, so every DL engineer works in ML and in AI, while the reverse does not hold.
• Unstructured data is home turf. Images, audio, video, and text: the data where classic feature engineering runs out of road and the network learns the representations instead.
• Research-adjacent by nature. The deliverable is a trained network plus the training recipe that produced it, and the role sits closer to research than either of the other two.
• The deepest math of the three. Linear algebra, calculus and backprop intuition, and optimization are daily working tools here, not background theory.
• The narrowest market. Fewest openings of the three, concentrated in companies that train their own models: vision, speech, robotics, and foundation-model shops.

Day-to-day work

• Architecture selection and modification. Choosing and adapting network families, CNNs for images and transformers for sequences, to fit the task at hand.
• GPU training runs. Launching long runs, often distributed across many GPUs, and keeping them healthy while they grind through the dataset.
• Loss curves and hyperparameter tuning. Reading training and validation curves, then adjusting learning rate, batch size, and the rest of the knobs until the network converges.
• Data augmentation. Stretching a limited dataset with transformations so the network generalizes instead of memorizing what it saw.
• Model compression. Quantization and distillation that shrink a trained network so inference is fast and affordable in production.

Anatomy of a training run

1. Pick and adapt an architecture. Start from a proven family, a CNN for images or a transformer for sequences, and modify it for the task instead of inventing from a blank page.
2. Prepare the data and augmentation. Label, split, and augment the raw media (crops, flips, noise) so the network sees more variety than you could ever collect.
3. Launch the run on GPUs. Kick off training, often distributed across machines, and let it run while you watch the metrics rather than the clock.
4. Read the loss curves and tune. A diverging or plateauing curve sends you back to the hyperparameters; this feedback loop is where most of the craft lives.
5. Compress and serve. Quantize or distill the trained network, then export it through an ONNX or TensorRT style path so inference meets the latency budget.

At a glance

The math depth ladder

• DL engineer: deepest. Linear algebra, calculus, and optimization are how you debug a training run when the loss refuses to fall.
• ML engineer: solid statistics. Evaluation methodology and feature-and-label thinking carry the classic role more than heavy calculus does.
• AI engineer: lightest. Systems and product engineering depth substitutes for math depth when the model arrives pretrained.
• Use the ladder as a filter. If reasoning about gradients sounds like fun, DL fits; if shipping features on strong model APIs sounds better, the AI engineer path fits.

That completes the three roles. The next tab drops the titles and puts the actual work side by side; the two after it hand you the sorting questions and the QA route in.

Same umbrella, three different jobs. This table puts the roles side by side so you can compare them in one pass, and the tells below let you classify any posting at a glance.

One table, three roles

The fastest tells

• Listen for the verb. "Train" on your own business data says ML Engineer, "train at scale on GPUs" says Deep Learning Engineer, "integrate" or "call" a model API says AI Engineer.
• Read the stack line. scikit-learn and SQL point at ML, PyTorch and CUDA point at DL, LangChain-style orchestration and a vector database point at AI Engineer.
• Check the data. Tables and transactions mean ML, images and audio mean DL, prompts and documents fed to a foundation model mean AI Engineer.
• Ask what ships. A model artifact with a serving pipeline is ML, a trained network with a training recipe is DL, a feature or agent inside a product is AI Engineer.
• Probe the math. Interviews heavy on statistics and evaluation signal ML, backprop and optimization signal DL, system design and product tradeoffs signal AI Engineer.
• Look at what monitoring means. Drift dashboards belong to ML, loss curves belong to DL, eval suites with latency and cost budgets belong to AI Engineer.

That is the map. The next tab turns it into a decision: a short set of questions that tells you which of the three lanes fits the skills you already have.

Forget the titles for a minute. Answer five questions honestly and the right lane usually picks itself.

Five questions that sort it

1. Do you want to train models or call them? If the exciting part is training on your own data, you are looking at ML or DL work. If the exciting part is shipping something users touch by calling a foundation model, that is the AI Engineer lane.
2. Structured business data or unstructured media? Tables, events, and transactions point at ML Engineer. Images, audio, video, and raw text you train on point at Deep Learning. Documents you retrieve and feed to a model point at AI Engineer.
3. Is the deliverable a model artifact or a product feature? If success means a trained artifact plus its pipeline and monitoring, choose ML or DL. If success means a feature or agent in production, with evals wrapped around a model someone else trained, choose AI Engineer.
4. How much math do you actually want? The deepest appetite (linear algebra, calculus and backprop intuition, optimization) fits DL. Solid statistics and evaluation methodology fits ML. If you would rather go deep on systems and product engineering than on math, that is the AI Engineer profile.
5. Product taste or research taste? DL work is often research-adjacent: architectures, loss curves, training recipes. ML lives in pipelines, retraining, and monitoring. AI Engineer sits closest to the product, shipping features and tuning latency and cost.

Pick your lane

• Pick ML Engineer if. You enjoy turning messy business tables into features and labels, and a well-monitored pipeline feels like a finished product to you.
• Pick ML Engineer if. Statistics and evaluation methodology are your comfort zone and you want the broadest pool of classic openings to aim at.
• Pick AI Engineer if. You want to ship user-facing features fast by building on foundation models: prompts, RAG, agents, guardrails, and evals rather than training runs.
• Pick AI Engineer if. You already have backend or QA instincts (APIs, CI/CD, an evaluation mindset) and want the lightest math on-ramp of the three.
• Pick DL Engineer if. Linear algebra and backprop intuition genuinely excite you, and research-adjacent work on architectures and training recipes sounds like fun rather than a chore.
• Pick DL Engineer if. You want to work on images, audio, video, or speech at companies that train their own networks, and you accept the smallest, most specialized market in exchange.

Whichever rung you choose, prove it with a small build before you rewrite your resume: an eval suite for a chatbot, RAG over your own test docs, or a bug-triage agent. The title follows the things you ship.

If you test software for a living, you are closer to this field than you think. The AI Engineer path is the natural door in for a QA or SDET, because the thing most AI teams are worst at, proving the system actually works, is the thing you already do all day.

The skills you already carry

• Scripting is covered. The Python or JavaScript you use for automation is the same language this stack speaks: calling model APIs, gluing pipelines together, writing harnesses.
• API skills transfer straight across. A model behind an endpoint is still an endpoint: auth, payloads, status codes, timeouts, contract thinking. You have tested harder APIs than this.
• CI and CD become eval gates. The pipelines you already build for regression suites are exactly where LLM evals need to live, so nobody ships a prompt change blind.
• The evaluation mindset is the rare part. Oracles, edge cases, regression thinking: most AI teams struggle to define what "correct" even means for a model. You have a whole career of answering that question.
• That mix points at one role. It maps most directly onto the AI Engineer path, building on existing models, because evals and reliability are the weak spot of most teams and your strongest muscle.
• The other two doors cost more up front. The ML Engineer route asks for statistics depth and feature pipelines before you ship anything, and the DL route demands the heaviest math for the fewest openings. Start where your edge pays off on day one, and keep the option to go deeper later.

The transition ladder

• Climb in order. Prompts first, then RAG, then agents, then MCP, then LLM evals with DeepEval and PromptFoo, then the AI testing tools built on top of all of it. Each rung reuses the one below.
• This is the AI Tester Blueprint sequence. The ladder is not invented for this page: it is the order the batch teaches, because it is the order the skills depend on each other.
• Get the words straight early. If model, agent, and tool-calling still blur together, LLM vs AI agent draws the line before you start climbing.
• The middle rungs have guides. RAG for QA covers grounding a model in your own documents, and AI agents for QA covers giving it tools and a loop.
• The top rungs are your edge. Evals are where a tester stops following this field and starts leading it: begin with the DeepEval masterclass, then bring PromptFoo alongside it for prompt-level comparisons.

Entry projects that sound like your job

• An LLM eval suite for a chatbot. Pick any bot you can reach, define what a good answer looks like, and score it with DeepEval and PromptFoo. It is a portfolio piece almost no other applicant has.
• RAG over your own test docs. Index your test plans, runbooks, and bug reports, then ask questions against them. You learn chunking, retrieval, and grounding on data you already understand deeply.
• A bug-triage agent. Feed it incoming bug reports and let it label severity, flag likely duplicates, and draft repro steps. Agents click fastest when the workflow is one you already do by hand.
• Contract tests around a model API. Treat the model endpoint like any third-party dependency: schema checks, latency budgets, failure-mode tests, and alerts when behavior drifts.

Your first stretch of building

1. Set up once, properly. A working Python or Node environment, one model API key or a local open-weights model, and a repo you commit to from the first script. Good looks like: a fresh clone runs in minutes.
2. Ship a prompt, not a course. Write a small script that sends a real task from your week to a model and prints the answer. Momentum beats syllabus, and the first rung of the ladder is deliberately small.
3. Ground it with RAG. Point the same script at your own test documents so answers cite your material instead of guessing. You now understand retrieval because you built it, not because you watched it.
4. Give it hands, carefully. Grow the script into a small agent with one or two tools, then expose those tools over MCP so they plug into other clients. The bug-triage agent is a natural candidate here.
5. Write the evals before you trust it. DeepEval and PromptFoo suites that score correctness, groundedness, and regressions, wired into CI so every prompt or model change gets judged automatically.
6. Harden, ship, and loop. Add monitoring, latency and cost budgets, and failure handling, then show the thing to someone. Start the next small feature with the same loop, carrying your eval suite forward.

Ready to climb? Do the boring part first: the batch setup guide walks you through the keys, tools, and repo layout, so your first rung is a build session, not a fight with your machine.