Patrick Barker argues that LLM applications have different users and production problems, so some specialized tools are useful even though the field contains substantial hype.
2
Farhood Etaati argues that MLOps is a mindset and an engineering cycle around secure, transparent, reproducible data and production systems, regardless of the model architecture.
3
Patrick Barker predicts that increasingly capable agents could automate much of the training, evaluation, and serving work associated with traditional ML within the next few years.
Summary
Patrick Barker and Farhood Etaati disagree about whether LLMOps deserves to be treated as a separate field. Barker says LLM applications bring a new group of developers and a different production experience, especially when people build products around model APIs, fine-tuning, and agent tools. He thinks specialized tools can help these users. Etaati accepts that LLMs create new technical problems, but says the central MLOps work remains the same: delivering data securely, transparently, and reproducibly through a continuing cycle from data to production. The conversation also covers venture funding and hype. Barker sees bubbles as a way to explore a new technology quickly, while Etaati worries that repeated renaming leaves future engineers with fragmented tools and weak foundations. Barker then makes a stronger prediction: agents may automate model training, evaluation, and serving, although high-volume, context-heavy data engineering will be harder. Etaati adds energy use, carbon emissions, and the cost of repeatedly training large models to the list of unresolved problems.
LLMOps has some genuinely different production problems
Patrick Barker says LLMOps is more than a marketing label, although it overlaps with traditional MLOps. His experience changed when he moved from One Medical, where he ran a conventional ML stack on Kubernetes, trained early NLP and tabular models, and served them with tools such as MLflow and Seldon, to building applications around large language models. He says very little of that day-to-day skill set transferred directly. Fine-tuning with LoRA has a different tool set, and an application built by a JavaScript developer with an OpenAI key creates a production problem that older ML systems did not have in the same form.
Farhood Etaati sees MLOps as a model-independent engineering mindset
Farhood Etaati says the data side of MLOps is nearly identical whether a team trains a large language model or a simple model. The work is to deliver data in a secure, transparent, and reproducible way, then support the continuing cycle from data to production. He describes MLOps as an added cycle around DevOps rather than a label determined by the technology stack. In his view, engineers should extend existing tools and abstractions where possible instead of creating many small, specialized products for each new model family. The architecture may change, but the engineering problems remain recognizable.
The user profile changes the value of specialized tools
Demetrios Brinkmann asks how much traditional MLOps knowledge helps someone building with LLMs. Barker answers that it depends on the job. A person fine-tuning and serving a model benefits greatly from MLOps experience, while a JavaScript or Rails developer building an application around an API may gain less from learning the full discipline. Barker says this new audience needs tools designed around application development, because LLMs have brought many more frontend, scripting, and application developers into AI. Etaati agrees that abstraction is necessary, but wants clearer layers between the MLOps foundation and the AI system built above it.
Hype can fund useful exploration, although it also creates noise
The discussion turns to venture capital and technology bubbles. Etaati worries that names such as LLMOps and prompt engineering can become short-lived labels that attract money while overpromising results. He says this makes it harder for technical people to work toward difficult goals and leaves the field with repeated reinvention. Barker has a more positive view of bubbles. He argues that a large wave of investment lets people test many directions quickly, after which the useful parts remain. He says AI is still underinvested and that trying many approaches can be productive, even though some funded products will be useless.
Agents may automate much of the traditional ML lifecycle
Barker defends his prediction that generative AI could eat much of ML 1.0 within a few years. He points to research on training models to use tools and says an agent could eventually treat the traditional ML stack as a set of operations it can run. In his example, agents would train, evaluate, and serve models, while choosing lower-level algorithms for particular tasks. He does not expect XGBoost to disappear soon because it is small, efficient, and effective on tabular data. He does expect language models to become capable of training such models and managing more of their lifecycle.
Data engineering is harder to automate than model operations
Barker draws a boundary around the most difficult part of this automation. Training, evaluating, and serving models may become manageable for agents within a few years, but data engineering often involves high-volume streaming systems and failures that become complicated far downstream. Demetrios connects this prediction to the idea of generative AI for MLOps, where models help operate existing ML systems. Barker mentions that companies such as Abacus AI are beginning to work in this area, while admitting that he does not know how well the approach works. The conversation leaves data context and operational complexity as the harder unsolved part.
Large models have an efficiency and sustainability problem
Etaati says the computing and energy demands of transformer-based systems rise as these models become more capable. He wants models to become reusable building blocks instead of requiring a new model to be trained from scratch each time. The value produced by current systems may justify the cost for now, but he expects the tradeoff to become harder as simple applications spread and more complex applications appear. Barker agrees that efficiency matters at scale and points to the Mamba paper as a promising direction because of its lower computational profile and linear context scaling. He says it remains uncertain whether that approach will scale like transformers.
Research results do not automatically become production systems
Farhood Etaati describes a tension between research and engineering. Researchers want access to more resources and knowledge, while engineers must produce feasible systems with limited resources. MLOps sits between those expectations, because papers are quickly absorbed into industry even when their results do not hold up at the scale companies need. Demetrios cites Jonathan from Mosaic ML, who said his lab often struggles to reproduce published work at industry scale. Etaati says this weak separation between research results and production standards makes stable, thoughtful progress difficult. He is asking for a clearer foundation that future engineers can build on.
"The main challenge is the whole ML scene, the way transformers and all these architectures are working, the carbon footprint and the energy consumption of them."Farhood Etaati42:41
Who should watch
You are deciding whether an LLM application needs a separate operational stack or whether your existing MLOps platform should be extended.
You build AI products with JavaScript, Rails, or Python and want to understand what traditional ML knowledge will help with your work.
You are evaluating new MLOps tools and want a direct discussion of hype, venture funding, model automation, data engineering, and system efficiency.
