Most people calling themselves AI/ML engineers have never actually deployed anything to production.
They can train a model, compare metrics, and explain why one algorithm performed better than another. Ask how the application is deployed, where it runs, or how a failed release is rolled back, and the conversation changes.
Their best example of a "production model" is a static notebook they run periodically before sending a CSV file to stakeholders.
The output might be useful. People might make business decisions from it. But running that notebook hasn't taught them how to deploy and manage a production application.
The title came with the job. The experience didn't.
You can hold an AI/ML engineering title for years without touching the infrastructure your models depend on.
Docker. Kubernetes pods. EKS or GKE. Helm charts. Argo CD. Terraform. Feature stores. Airflow. MLflow.
These tools handle different parts of the work, and no single application needs all of them. The gap shows when you don't know which parts your own team uses, how they fit together, or who operates them.
You trained the model. Someone else packaged it. Someone else deployed it. Another team monitors the service.
Your contribution ends at the handoff.
Large companies make this easy to miss
In a large company with many cross-functional teams, your chances of deploying and managing an application yourself can be very slim.
The data team owns the pipelines. The ML platform team owns the training infrastructure. The backend team integrates the predictions. The infrastructure team manages the cloud environment. Operations handles incidents.
There are good reasons to divide the work. But look at what that means for your experience: you can contribute to a product used by thousands of people and still have no hands-on experience getting it into production.
The company deployed it. You worked on one part of it.
That distinction matters when you describe what you've done. It matters even more when your next employer expects you to own the whole application.
Then someone asks how you deployed it
Where did you save the trained model? How does the application load it? What happens when a new version fails? Who gets called when predictions stop working?
Those are ordinary questions about an application people depend on.
If another team handled all of that, say so. Explain the part you owned. But don't mistake being close to a production system for having deployed and managed one yourself.
And if your workflow is still opening a notebook, running the cells, and emailing the results, be clear about that too. Your job title won't fill in the experience you haven't had.
And don't even get me started on AI agents
Deploying agents to production takes this gap further.
Getting an agent to answer a question or call a tool in a demo is one thing. Letting it act on company systems means dealing with permissions, failed actions, retries, costs, and records of what it did.
Someone has to decide what it can change, when a person must approve an action, and how to stop it when it goes wrong.
My view is that very few companies are doing this properly in production. Yet the number of people describing themselves as experienced agent builders keeps growing.
A working demo gives you something to show. Operating it gives you something much harder to claim: experience with what happens after people start depending on it.
Get the experience your title suggests
If your current role ends at the notebook, look for a chance to follow the work further. Work with the team deploying it. Take responsibility for a release, investigate a failure, or help operate the application after launch.
If that opportunity doesn't exist at work, deploy an application of your own and maintain it. Be honest about its scale and what you've learned.
You can be good at modelling and still lack production experience. Recognising that gap is how you start closing it.
Comments