AI / ML Engineer roadmap
The other side of the line: training models, not just calling them. Data pipelines, experimentation, distributed training, optimisation, serving, and the infrastructure that keeps models correct after they ship.
15 stages282 topics
This is the infrastructure-and-training track, distinct from AI engineering. It demands more mathematics and more systems depth, and there are fewer such roles - but they're less crowded. Take this path if you want to build the systems that produce and serve models. If you want to build products on top of models that already exist, the AI engineer track is the better fit and the faster one.
Mathematical Foundations
More maths than the AI engineer track needs, and the honest reason this path is longer. You need enough to read papers, debug training, and reason about why a model behaves as it does.
Software and Systems Engineering
Production ML is 80% engineering. This section is not optional garnish - it is the difference between a research script and a system.
Classical Machine Learning
Still a large share of production ML. Most business problems are tabular, and a gradient-boosted tree beats a neural network on them more often than newcomers expect.
Deep Learning
Data Engineering for ML
The most underrated section. Data problems cause more production failures than modelling problems, by a wide margin.
Experimentation
Training at Scale
Where ML engineering becomes distributed systems engineering. Also where costs become large enough that inefficiency is visible on a budget line.
Model Optimisation
Serving and Inference
MLOps
The connective tissue. Most of what distinguishes a senior ML engineer from a strong modeller lives in this section.
Monitoring and Reliability
A model does not throw an exception when it becomes wrong. Detecting silent degradation is the defining operational skill of this role.
Foundation Models
Where this track meets the AI engineer track - but from the infrastructure side: adapting and serving models rather than calling an API.
Specialisation
Pick one and go deep. Breadth across all of these is worth less than depth in one, and hiring is usually organised around them.
Responsible ML
Professional Practice
Capstone
One model that lives in production and keeps working without you watching it. The training is the easy part; everything around it is the job.
The system
- An automated pipeline from raw data to a registered model
- Versioned data, code, and model artifacts, reproducible from a commit
- Tracked experiments with a documented winning configuration
- Validation gates that block a worse model from promotion
- An optimised, benchmarked inference service with a latency SLO
- Shadow deployment, then canary, then full rollout
- Drift and performance monitoring with alerting
- An automated retraining trigger, and a rollback that has been rehearsed
Then answer these
- What does one prediction cost, and one training run?
- What is the p99 latency, and where does it go?
- How would you know the model degraded, and how fast?
- What happens if the feature pipeline silently changes a column?
- Can you reproduce last month's model exactly?
An engineer who can answer all five about a system they built is hireable. Model accuracy is rarely what gets discussed in the interview.
Training a model is a bounded problem with a clear finish. Keeping a model correct in production is unbounded, and that is where nearly all the engineering time actually goes. Roadmaps that stop at model training stop at roughly 20% of the job.