The ML engineer is the person who takes a model that works in a notebook and makes it work in the real world. A data scientist builds a recommendation model that performs well on historical data. The ML engineer's job is to deploy that model into a production system where it serves predictions to millions of users, monitor its performance over time, retrain it when the data changes, and build the infrastructure that makes all of this happen automatically and reliably. The primary pull is Resolution — taking something that is fragile, manual, and researcher-grade and making it robust, automated, and production-grade.
The distinction between data scientist and ML engineer is one of the most important and least understood boundaries in the field. The data scientist asks: can we build a model that does this? The ML engineer asks: can we make this model work at scale, reliably, continuously, without a researcher babysitting it? These are different skills, different temperaments, and different daily textures. The ML engineer's world is closer to software engineering than to research — version control, testing, deployment pipelines, monitoring, alerting, and the particular challenge of systems whose behaviour is non-deterministic because the model's outputs depend on its inputs in ways that are not fully specified.
The work has a characteristic satisfaction and a characteristic frustration. The satisfaction: building a system that serves a million predictions a day without anyone noticing. The frustration: the gap between what research papers describe and what actually works in production, reliably, at scale. A significant share of ML engineering work is unglamorous infrastructure — data pipelines, feature stores, model registries, monitoring dashboards — that has nothing to do with the model itself but without which the model cannot do its job.
Kitsune can talk through anything on this page — whether it might suit you, what to do next, questions this page doesn't answer. Everything here is yours to read either way.
The title "ML engineer" attracts people who want to build cool AI models. The actual job is production systems engineering with ML as the payload. If you want to design models, you want to be a data scientist or research scientist. If you want to make models work — which is a different and equally difficult problem — you want to be an ML engineer. The people who are happiest in this role are those who find infrastructure satisfying and who get genuine pleasure from reliability, automation, and systems that run without intervention.
The on-call and production-monitoring dimension is real. A model serving predictions in a production system is a thing that can break, and when it breaks, the consequences are immediate and visible — wrong recommendations, bad predictions, degraded user experience. ML engineers often carry on-call responsibilities for the systems they deploy.
The field is evolving rapidly. MLOps (the operational practice of ML deployment) has matured significantly, but the tools and best practices are still less stable than in traditional software engineering. An ML engineer's toolkit changes faster than most engineering disciplines.
Software engineering background is the most common path — ML engineers are engineers first who specialise in ML systems. Computer science degrees with coursework in machine learning, distributed systems, and software engineering provide the strongest foundation. Some data scientists transition into ML engineering after discovering they prefer the systems work to the research work. Cloud platform certifications (AWS, GCP, Azure ML) carry weight. The field values demonstrated ability to build and deploy production systems more than academic credentials.
Meta-disruption: builds AI while disrupted by AI. Growth role despite high exposure because deployment demand exceeds supply. Rising skill bar at entry level.
Growth role — BLS 34%, WEF top-15. Title may converge with AI Engineer. Entry positions exist but skill bar elevated.
People drawn to ML Engineerare often drawn to these — in the order they're closest. The ones marked sit in a different field entirely.