# I Am Once Again Asking "What is MLOps?"

Oleksandr Stasyk, Synthesia | MLOps Podcast | Episode 308 | 1:06:22
Hosted by Demetrios Brinkmann

Source: https://www.youtube.com/watch?v=OlFqZ14ytmI
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/i-am-once-again-asking-what-is-mlops
Published: 2025-04-22
Tags: data-engineering, engineering-culture, platform-teams, testing

## TL;DR
- MLOps connects research, engineering, data, and product work through short feedback loops from an idea to customer value.
- An MLOps engineer does not need every skill themselves. Teams work better when people have complementary depth and empathy for adjacent roles.
- AI can speed up exploration and MVPs, but software engineering, data quality, testing, and human judgment are still needed before production.

## Summary
Oleksandr Stasyk describes MLOps as the work of helping a business iterate on machine learning efficiently. He compares it with DevOps, while adding the demands of research, data, models, and production feedback. His focus is organisational as much as technical. Research and production teams need bridges between them, otherwise one side publishes papers while the other keeps an old model running. Stasyk argues for short feedback loops from an idea to customer value, with teams choosing the right checks and automation at the right stage. He also explains why there is no universal MLOps team structure. The right setup depends on people, skills, domain, and company context. Data deserves special care because it is stateful and can affect many downstream systems. AI and vibe coding can help people explore and build MVPs, but they do not remove the need to recognise when generated code is unsafe or unmaintainable, or when a problem requires a person with deeper expertise.

## Key ideas
### Vibe coding is useful until someone must recognise that the result cannot be maintained
[02:11](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=131s)
Oleksandr Stasyk says the important skill in vibe coding is knowing when to stop. Generated code can become unmaintainable, insecure, or full of exposed secrets, especially when the person using it does not know what security questions to ask. He also points out that prompts often contain coding-specific language and detailed algorithm descriptions, so knowing nothing about software still limits what a person can ask for. Vibe coding lowers the barrier to exploration, which he sees as a benefit, but people need guidance and must know when to ask for help or hire someone. Some problems should be solved with infrastructure, moving a file, or a spreadsheet instead of more code.

### An MLOps engineer grows from one technical depth into adjacent skills
[09:08](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=548s)
Stasyk explains his idea of the T-shaped MLOps engineer. One deep leg comes from a person's original background, such as software engineering or research. A software engineer may learn models, features, drift, inference, and scaling. A researcher with a model in a Jupyter notebook may learn Docker, Kubernetes, deployment, and production operations. He adds domain knowledge as another dimension, such as chemistry, computer vision, or finance. The point is not to find one person who knows everything. Stasyk says the strength is in the team, where people with different depths support each other.

### Good data remains a foundation even when a team is building GenAI quickly
[13:31](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=811s)
When Demetrios Brinkmann asks whether GenAI reduces the need for data engineering, Stasyk says the pressure to make money encourages teams to sacrifice some foundations. Data is one of the debts they may have to pay later. His personal rule is, "can't have AI without good data." A team may get lucky with enough data to build an MVP, but it will eventually need better data or a way to pay down the accumulated debt. Stasyk accepts moving quickly when a team is validating whether a product has legs, while warning against pretending that an API call or a prompt-based prototype is already a production system.

### MLOps shortens the path between research, production, and customer value
[17:07](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=1027s)
Stasyk defines MLOps as DevOps with extra concerns around machine learning. It means breaking down organisational walls and creating feedback loops between research and production. If those groups become separate, the company can end up with researchers publishing papers while production teams keep an old model running. MLOps tries to create bridges and eventually reduce the distinction between the groups. The measure he returns to is the value stream from an idea, such as predicting something, to whether it makes money. Teams should iterate and validate close to the customer, with a productization step when research code needs to be rewritten or refactored.

### Platform organisation depends on people, timing, and empathy rather than a fixed model
[21:41](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=1301s)
Stasyk does not give one preferred answer for centralised platforms, embedded teams, or hub-and-spoke structures. He says organisations need to hire complementary skills and understand how those skills interact. Even when a team lacks expertise on the other side, its members need empathy for the problems that adjacent teams face. A researcher needs freedom to experiment, while a platform must support that work without ignoring production needs. Leaders also need to know their people's skills, preferences, and working relationships before creating an ML platform team or a research team. Stasyk recommends making changes step by step and accepting that a reorganisation may be needed.

### Small enablement choices can remove large organisational blockers
[24:27](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=1467s)
Stasyk gives a platform example involving a developer who needs a database. If the developer submits a request to DevOps and waits in a queue, progress stops even though the task may be simple. Giving that developer enough Terraform knowledge to create the database can remove the blocker. He says the problem is often not that the work is inherently complicated. Someone may simply lack the knowledge, initiative, or access needed to complete the next step, and the right people may not be in the conversation. He summarises the organisational answer as having the right people, skills, and conversations at the right time.

### Empathy and downstream checks protect data teams from hidden breakage
[27:53](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=1673s)
The conversation turns to changes that travel through data systems. Demetrios Brinkmann describes how a software change can break downstream products and leave data engineers under pressure from ML engineers or analysts. Stasyk agrees that a small check before making a change can save someone many hours. He discusses YAGNI and DRY as examples of software ideas that can create unexpected coupling when applied without understanding downstream effects. A refactor that looks clean to one team may make another team unable to change its code. A test in CI can shift some checking left and make people aware of a problem before it reaches a downstream product.

### Agile and DevOps ideas survive after teams reject their old ceremonies and labels
[32:24](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=1944s)
Stasyk describes the current period as post-Agile and post-DevOps because many engineers are tired of buzzwords and heavy ceremonies. He distinguishes the useful spirit of Agile from capital-A Agile, which may mean story points, stand-ups, sprint planning, or rigid process. For him, Agile is doing small things and getting frequent feedback. DevOps also has a broader meaning than Terraform and AWS. It can include reorganising teams or creating a platform team under a different name. The labels change, but feedback loops and collaboration remain useful. He says teams should choose the tools and meetings that lower friction, whether that is Jira, ClickUp, Slack, or a whiteboard.

### Shift-left checks must balance earlier feedback against their cost
[56:08](https://www.youtube.com/watch?v=OlFqZ14ytmI&t=3368s)
Stasyk explains shifting left as moving checks closer to the person who has the idea or writes the code. A conversation can catch a bad idea before code exists. Type checking can catch a problem before a commit, while integration tests provide a later and more expensive check. He warns against an end-to-end test that takes hours for every small change, since the cost can outweigh its value. Data is harder to shift left than code because code is usually stateless while data has state and can create many downstream effects. Media data adds more difficulty than simple tabular data. Teams therefore need to decide which checks provide enough value at each stage rather than automate everything immediately.

## Notable quotes
- Oleksandr Stasyk: "To me, MLOps is about enabling your business to actually iterate on its machine learning efficiently." (19:15)
- Oleksandr Stasyk: "It's about your value stream map from an idea in terms of I would like to predict something to does it actually give us the money." (18:28)
- Oleksandr Stasyk: "You really, really, really need to know your people well." (24:24)
- Oleksandr Stasyk: "Can't have AI without good data." (14:38)
- Oleksandr Stasyk: "Sometimes you just have to do the work yourself as a human." (48:43)

## Tools & references mentioned
- Synthesia
- MLOps Community
- ChatGPT
- Jira
- Terraform
- AWS
- Kubernetes
- Atlassian
- Slack
- ClickUp
- Etsy
- Warhammer
- YAGNI
- DRY
- CI/CD
- Shift Left Data Conference

## Who should watch
- You are building an ML or GenAI product and need to decide what can stay lightweight during MVP work and what must be made production-ready.
- Your research, data, platform, and product teams keep handing problems to one another because their feedback loops are slow.
- You are designing an ML platform organisation and want practical guidance on team skills, empathy, platform access, and when to add automation.

## Editor's note

Oleksandr Stasyk says that a researcher with a model in a Jupyter notebook may need to learn Docker, Kubernetes, deployment, and production operations. ZenML lets teams write workflows as Python steps and run the same pipeline code on a laptop, Kubernetes, Airflow, Kubeflow, or cloud services through configuration. That can keep the workflow code consistent as it moves toward production.

Written by the MLOps Talks editors (the ZenML team), not by the speaker.

## Related talks

- [Engineering MLOps](https://mlopstalks.com/talks/engineering-mlops) (Emmanuel Raj, TietoEvry, 51:55)
- [Machine Learning Operations: What Is It and Why Do We Need It?](https://mlopstalks.com/talks/machine-learning-operations-what-is-it-and-why-do-we-need-it) (Niklas Kühl, IBM and Karlsruhe Institute of Technology (KIT), 58:47)
- [MLOps: Isn't That Just DevOps?](https://mlopstalks.com/talks/mlops-isnt-that-just-devops) (Ryan Dawson, Seldon, 1:06:32)
- [MLOps vs LLMOps](https://mlopstalks.com/talks/mlops-vs-llmops) (Richa Sachdev, JPMorgan Chase & Willem Pienaar, Feast & Chris Van Pelt, Weights & Biases & Aparna Dhinakaran, Arize AI & Alex Ratner, Snorkel, 34:57)
- [Operationalize Machine Learning at Scale with MLOps](https://mlopstalks.com/talks/operationalize-machine-learning-at-scale-with-mlops) (Christopher Bergh, DataKitchen, 57:50)