A senior data scientist with 20 years of experience recently asked a question that perfectly captures the industry’s current state of confusion: Does the DS just feed the data into an LLM and ask it to predict something? Or does the LLM build the model that gets deployed?
The short answer: both are possible, and both are mediocre ideas. The long answer is far more interesting, and reveals where LLMs are actually changing predictive modeling and anomaly detection in ways that matter.
The “Throw a Spreadsheet at ChatGPT” Trap
Let’s address the elephant in the room first. Feeding your tabular data into an LLM and asking it to forecast next quarter’s revenue is technically possible and generally produces “inconsistent and unexplainable garbage”, as one practitioner astutely noted. The model will happily generate plausible-looking predictions with zero statistical grounding, and you’ll have no idea why it made them.
The seduction is real. A salesperson dropping a spreadsheet into an AI chat and getting a forecast feels like magic compared to waiting three weeks for the data science team. But it’s exactly the kind of magic that gets companies in trouble when those predictions quietly fail during quarterly planning.
This approach fails for structural reasons. LLMs are trained on text, not on the underlying probability distributions of your business data. They excel at linguistic patterns and semantic relationships, but they have no mechanism for understanding that your SaaS churn data follows a Weibull distribution or that your inventory levels have weekly seasonality. Traditional statistical methods and gradient-boosted trees absolutely crush LLMs on structured, tabular data, and this isn’t controversial among people who actually build these systems.
Where LLMs Actually Shine: The Surprise Metric
The genuinely fascinating LLM applications in anomaly detection come from a completely different angle: treating events as language.
At Datadog, security researcher Nicolas Grislain built Mambark, a model that reads audit logs the way a language model reads text. It’s a modest 97 million parameters, small by modern standards, but it’s been trained on hundreds of billions of security events. The core insight is elegant: an anomaly is just a surprising sequence, and language models are essentially probabilistic machines for predicting what comes next.
Mambark scores every event by how surprising it is. A normal user session reads like a predictable sentence. A compromised account reads like a grammatical error, unexpected, jarring, and worth investigating. This is fundamentally different from threshold-based monitoring or traditional statistical anomaly detection because it captures sequential context. A login at 3 AM from a new device in another country isn’t anomalous on its own, it becomes anomalous in the context of everything that preceded it.
The research community is converging on similar ideas. At ECCV 2026, researchers are presenting CL-Anomaly, a framework that uses layer-adaptive mixture-of-experts with multimodal LLMs for continual learning in anomaly detection. The “continual” part matters: production environments change constantly, and models that can adapt without catastrophic forgetting are the ones that survive contact with reality.
The Real Revolution: LLMs as the Data Science Workbench
The most experienced practitioners I’ve seen discussing this topic consistently land on the same conclusion: the highest-value use of LLMs in data science isn’t as models, it’s as tooling. This is the point that gets lost in the hype cycle.
Consider the actual workflow of anomaly detection in production. You’re not just detecting anomalies, you’re:
- Cleaning and preparing data across dozens of sources
- Brainstorming approaches for edge cases you haven’t encountered
- Building and iterating on pipelines to handle data drift
- Debugging models that produce plausible but wrong results
- Explaining outputs to stakeholders who want answers, not ROC curves
LLMs and coding agents are transforming each of these steps. The experienced practitioners I’ve spoken with describe using LLMs for data labeling, initial passes at text classification, and rapid prototyping of feature engineering. They use them to generate boilerplate model code and to interact with prediction data through natural language interfaces.
But here’s the critical caveat that separates veterans from novices: you still need to know what you’re doing when the LLM “inevitably spits out something that looks right but has a subtle logic flaw buried in the feature engineering step.” The model is turbo-charged boilerplate, not a replacement for expertise. It’s the difference between having a brilliant intern who works at 100x speed and having no oversight at all.
The Observability Blind Spot
As LLMs become embedded in data science workflows, they create a new class of failure modes, and most teams aren’t prepared. This is where AI observability becomes existential rather than nice-to-have.
Modern AI workloads run through layered pipelines that pull from dozens of data sources. When something breaks, finding the root cause can take hours. The AI observability landscape has exploded in response, with 18 major platforms now competing for attention, from open-source solutions like Grafana and WhyLabs to enterprise platforms like Monte Carlo and Datadog.
The key insight: data observability and AI observability are two halves of the same system. As one platform put it, “You cannot separate data observability from agent observability, because the data feeding the agent matters as much as the agent itself.” This is illustrated beautifully by the iceberg model of observability:
If you’re feeding an LLM garbage context, it will produce garbage predictions, and no amount of prompt engineering will fix that. The monitoring tools that matter are the ones that trace the entire journey from data source to model output.
What This Means for Your Career
If you’re a data scientist reading this and feeling a mix of excitement and existential dread, you’re not alone. The reality is more nuanced than either pure hype or pure doom.
The data scientist role isn’t disappearing, but the work is shifting dramatically. The entry-level grunt work, data cleaning, feature engineering boilerplate, initial model iteration, is being automated. What’s replacing it is higher-level work: deciding what to model, understanding why models fail, and explaining results to stakeholders in ways that build trust.
This mirrors what’s happening to software architects, who are finding that LLMs can generate documentation and architectural patterns in minutes, but still can’t make the judgment calls about trade-offs and constraints that define real architecture.
For anomaly detection specifically, the winners will be teams that embrace a hybrid approach:
- Use LLMs for unstructured data where their semantic understanding genuinely shines: log analysis, threat detection, customer feedback, document classification
- Keep traditional methods for tabular data where statistical rigor and interpretability matter: financial forecasting, churn prediction, demand planning
- Use LLMs to accelerate everything around the model, code generation, testing, documentation, and stakeholder communication
The Reality Check
The hype around using LLMs directly as prediction engines is premature. The applications that actually work in production are the ones where LLMs’ core competency, understanding sequential patterns in language-like data, aligns with the problem domain. Security logs, system telemetry, network traffic: these are all sequences that can be read as language.
If you’re considering whether to use an LLM for predictive modeling, ask yourself this: is your data fundamentally about sequence and context or about distributions and relationships? If it’s the former, an LLM-based approach might surprise you. If it’s the latter, you’re probably better off with traditional methods and using the LLM to build and deploy them faster.
And whatever you choose, build the observability infrastructure before you need it. The teams that are successful with AI in production aren’t the ones with the best models, they’re the ones that can detect and diagnose failures before users notice.
The spreadsheet-to-ChatGPT pipeline will give you a forecast. Whether it gives you a correct one is a different question entirely.
