On AI, Data Science, & Causal Models

How do you get to new ideas when data is always looking back?

In this latest Data Duets post, we discuss a case from United Airlines and share five key lessons from an interview with Patrick Quayle, Senior VP of Global Network Planning.

The post explores how to go beyond historical data by using:

1. Transfer learning and clustering
2. Data triangulation (Spoiler: HBO’s White Lotus informs a business strategy here)
3. More frequent experimentation
4. Real-time falsification of new ideas
5. Combining data science with the art of creativity

Our Director’s Cut expands the discussion to offer insights for retail merchandising.

Enjoy the read and feel free to leave your comments on LinkedIn here.

[Click title for image]

This is so hilarious I had to share. A major issue with using LLMs is their overly obsequious behavior. They aren’t much help when I’m right; I don’t want to be right, I want to be corrected.

This project uses a Python script to count how often Claude Code says you’re “absolutely right.” The script doesn’t seem to normalize the counts by usage, which might be a good next step.

Source – Script

A recent New York Times story offers insights.

Using LLMs as a “second pair of eyes” or as a fallible assistant seems to work well. Automation also works effectively when the instructions are clear and the objectives are defined unambiguously. In both cases, human agency remains central.

Use case #15 in the article, “Review medical literature,” reminded me of a study I shared earlier (How do LLMs report scientific text?). The study showed that LLMs systematically exaggerate claims they found in the original text. The user in this case is a medical imaging scientist and is aware of the danger. When a tool isn’t foolproof, the user’s expertise and awareness make all the difference.

The high-demand use cases are quickly scaling into independent businesses with more standardized output, often with LLMs as the core wrapper. I suspect some are marketed as “magic,” and to resist that hype, users will need a combination of expertise and awareness.

If you’re a visual learner looking to deepen your understanding of AI and language models:

I’ve just made the deck from my recent talk, “AI in 64 Pictures,” available. It’s a visual journey through language processing: from word embeddings to RNNs, attention, and transformers.

Understanding AI models better helps us discover more use cases and navigate their limitations. And if you’re looking to dive deeper, you can follow the links in the slides.

Nearly half of all AI agent projects are set to fail (as Gartner predicts here). Why? Unclear business value, inadequate risk controls, and escalating costs.

As I see it, much of this is fueled by hype, leading to existing solutions being relabeled as “Agentic AI” without any rethinking of business processes.

Human creativity is missing in this picture. It’s this creative thinking that should move agent use beyond just automating or augmenting individual tasks with LLMs, leading instead to the redesign of business processes and a vision for how humans and AI can truly complement each other.

The risks and costs are more straightforward to resolve:

– Managers who are most excited about AI agents often do not fully understand the risks and limitations of LLMs. They should invest as much in understanding these models as they do in using them.

– The true cost of scaling proof-of-concept GenAI solutions is often underestimated. This is on selecting the right vendor. Gartner estimates only about 130 of the thousands of agentic AI vendors are real.

Andrew Gelman’s latest “rant” is worth a read. Everybody lies, but why, even when data clearly refutes it?

It’s interesting to think a little bit more and understand why and how people lie, especially when it comes to scientists, medical doctors, and law enforcement officials. Spoiler is, the answer is not always money.

[Click title for image]

Turns out Anthropic literally purchased and scanned millions of print books to train its language model Claude.

The judge finds that the scanning of these purchased books is “fair use” even without licensing, and goes on to say:

Everyone reads texts, too, then writes new texts. They may need to pay for getting their hands on a text in the first instance. But to make anyone pay specifically for the use of a book each time they read it, each time they recall it from memory, each time they later draw upon it when writing new things in new ways would be unthinkable. For centuries, we have read and re-read books. We have admired, memorized, and internalized their sweeping themes, their substantive points, and their stylistic solutions to recurring writing problems.

This is quite interesting, as it draws an analogy between how humans read, comprehend, and write text and how a language model operates.

Source

[Click title for image]

One way is hitting that accept button until the code works. This is like gambling: it works until it doesn’t, and you never know why in either case.

Another way is intentional use. Intentional use is:

• Telling LLMs exactly what to do.
• Inspecting their code, line by line, before accepting.
• Unit testing the solution before it ever sees production.

This means treating LLMs as over-confident, lightning-fast assistants. They are incredibly helpful in boosting productivity, quickly looking things up and delivering operational code. They can search a 100-page API documentation and find a solution to your problem in seconds.

Unless we see a structural breakthrough in how language models are built, this is also the best we can have: an over-confident assistant. LLMs don’t think or reason; they achieve (shallow) deductive closure at best. While the debate over whether LLMs “think” can be unproductive, there is a practical implication: LLMs make profoundly inhuman coding mistakes.

The errors LLMs make aren’t the errors a human assistant would make, so working with LLMs takes another perspective shift. Understanding this distinction is key to effectively using them: our coding assistant is deeply inhuman.

Otherwise, LLM-driven coding will inevitably lead to more failures in data science. Expect to hear more stories about models breaking unexpectedly.

This post was inspired by the write-up “Here’s how I use LLMs to help me write code,” which nails many other crucial points. It’s worth checking out.

[Click title for image]

The founder of this Shark Tank backed company (thinks he) did an A/B test on the impact of tariffs on customer behavior (demand for a showerhead): “Made in USA” vs. “Made in Asia”.

There’s so much wrong here that I’m just going to share it without comment. But one thing is clear: Outside of tech and other companies that are invested in data science, we’re still in the early days of business analytics education. When it comes to causal modeling, inference, and experimental design, we seem to be just getting started.

Source

[Click title for image]

This is ironic and offers a valuable lesson.

Cursor, an AI-powered integrated development environment (IDE), started kicking users out when they logged in from multiple machines.

I use Cursor on a daily basis, and I know how frustrating and disruptive this limitation can be for most users.

So many Cursor users rushed to email the support team to ask if this was a new policy. In response, the support team explained that this was “expected behavior” as part of a new security feature.

But, in reality, there was no support team. Sam is a bot designed to “mimic human responses.” That answer, which was completely made up by the bot, quickly went viral, and users started canceling their subscriptions.

By the time Cursor’s “real humans” stepped in, the damage was done. Here on Reddit, Cursor is doing damage control.

Pretty remarkable that the AI company got hit by the AI and no one noticed until users canceled their subscriptions in droves.

And this could have been largely avoided if Cursor had disclosed that Sam was a bot.

[Click title for image]

How much longer will we have non-zero trust in what see on a computer screen?

Generative models are eroding trust in the digital world at an astonishing rate with each new model released. Soon, pictures and videos of events will no longer be accepted as evidence.

Insurance companies won’t accept pictures and videos of damage after accidents, and accounting departments will no longer accept pictures of receipts. This may be an easier problem to solve. We’ll likely develop more ways to authenticate digital files. More algorithms will verify authenticity, and companies may simply ask customers to use dedicated apps.

But the shift in public trust in digital files is less easily repairable and may even be permanent. We may be leaving behind pics or it didn’t happen for I only believe what I physically see.

[Click title for image]

Some tasks require understanding, not just knowing how to do. Tools can’t fill the gaps in understanding. For these tasks, time is better spent learning and understanding. No-code development is useful for building without understanding, but understanding is most critical when things fail. And things fail while building products, be they data products or otherwise.

Here the user switches from Cursor (automated coding) to Bubble (a no-code tool) to address the lack of understanding, not realizing that switching tools is solving the wrong problem.

We often make the same mistake in data science, especially in predictive modeling, where a new off-the-shelf library or method is treated as a prophet (pun intended), only to find out later that it was solving the wrong problem.

Source

[Click title for image]

Doing is not understanding. Even LLMs seem to know the difference.

I’ve written and spoken a lot about this (link to the talk). Naturally, the exchange here was too good not to share. Here is Claude in Cursor lecturing a user on the difference between having something coded by an LLM vs. coding it yourself so you learn and understand.

The better we separate things we need to understand from things we just need to do, the more effectively we will benefit from LLMs. We certainly can’t understand everything (nor do we need to), but it’s a good idea to avoid the illusion of understanding just because we can do it.

To paraphrase Feynman, we can only understand the code we can create.