On AI, Data Science, & Causal Models

LLMs now look much more like they are reasoning than they did just a year ago. In his 2025 review, Andrej Karpathy explains why:

In 2025, Reinforcement Learning from Verifiable Rewards (RLVR) emerged as the de facto new major stage to add to this mix. By training LLMs against automatically verifiable rewards across a number of environments (e.g. think math/code puzzles), the LLMs spontaneously develop strategies that look like “reasoning” to humans – they learn to break down problem solving into intermediate calculations and they learn a number of problem solving strategies for going back and forth to figure things out (see DeepSeek R1 paper for examples). These strategies would have been very difficult to achieve in the previous paradigms because it’s not clear what the optimal reasoning traces and recoveries look like for the LLM – it has to find what works for it, via the optimization against rewards.

Why should we care if they reason or not, as long as we get things done?

Reflecting my pedagogical approach, I’d argue that understanding a tool’s capabilities is key to getting the most out of it. Understanding what Excel is capable of means we wouldn’t ask it for life advice (even with Copilot integrated now, we’d better resist that urge).

I have been discussing this at a higher level in my talk, “Mind the AI Gap,” since 2024. I’ve most recently delivered this talk as a guest speaker for an executive cohort, and our discussion prompted updates to the deck. So I owe this update to 2025.

The updated deck is here, with both practical advice and high-level insights.

The key takeaway remains: Steve Jobs’ “bicycle for the mind” analogy is holding up. Today’s LLMs aren’t the mind itself; they’re still the tools that make the mind’s efforts go further. Much further. And we have yet to realize their full potential.

Karpathy concludes and I concur:

LLMs are emerging as a new kind of intelligence, simultaneously a lot smarter than I expected and a lot dumber than I expected. In any case they are extremely useful and I don’t think the industry has realized anywhere near 10% of their potential even at present capability.

[Click title for image]

I’m not ready to go all-in on Claude Code just yet. Despite the well-earned hype, I’m sticking with Cursor (for now). That’s because model independence is worth more to me than a native tool integration in an “actor-critic” type of workspace.

I started writing this as a comment on yet another Claude Code praise, but it evolved into an end-of-year reflection on coding assistants. I’ve been hearing a lot about Claude Code, but I haven’t yet found a compelling reason to abandon Cursor, which I’ve used since near its release. For those of us with a coding background, the primary reason for starting with Cursor was the low switching cost from VS Code to Cursor.

Claude Code is Anthropic’s response to VS Code and its forks: mainly Cursor and Windsurf. By the way, a lesser-known alternative emerged from Google last month: Antigravity.¹ It’s currently in public preview, so you can use it for free here. It looks promising, and the standout feature is “Agent Manager,” which essentially acts as a mission control dashboard for orchestrating multiple agents working in parallel.

I was planning to test Windsurf once my Cursor subscription expires (for the reason I highlighted here – Codemaps offer a hierarchical mental model of the codebase), but a new praise for Claude Code every day further piqued my curiosity. After checking a few resources, this comparison seemed fair (if you look past Qodo’s advertising). This one is also solid, and ultimately recommends that you “just use both.”

So, what is my plan for 2026?

I still intend to test Windsurf because I find the “Codemaps” feature intriguing. After that, I might revert to VS Code and layer in Claude Code (here is how). Meanwhile, I will keep an eye on the evolution of Google’s Antigravity, the latecomer. My hesitation to commit to a specific vendor stems from my frequent use of actor-critic logic (where one model/agent performs the task and another reviews it). I find value in using different models for these roles, so I want to retain the flexibility to switch between models. Based on the comparisons above, I might face a premium as context usage scales, but that’s a price I’m willing to pay for model independence.

And what do I mean by the actor-critic setup?

While “racing” parallel agents is becoming standard practice (see the Cursor documentation), I also use a sequential approach with diverse models: e.g., using Claude to code (the actor) and Gemini to review (the critic). VS Code documentation on agent use touches on this “multi-agent” idea without calling it an “actor-critic” setup (rightly so, as I’m just borrowing the concept from reinforcement learning).

Credit for the figure goes to Gemini 3 Flash & Nano Banana based on this reflection.

[Click title for image]

Pluribus knows everything, and understands nothing – just like an LLM!

I’ve finally found the time to start watching Pluribus. I’m only two episodes in, but the analogy to LLMs is already clear. The crux of this comparison for me is the scene where Carol tries to convince the unified human entity that it is okay to say “no” and not be obsequious.

Like an LLM, the show’s unified human entity (which possesses all human thoughts and knowledge) “knows” everything but “understands” nothing. This is an excellent link to my take on LLMs in the talk, “Mind the AI Gap: Understanding vs. Knowing.”

Clearly, I was not the first to make this connection (see this summary for example). As I understand it, Vince Gilligan didn’t intend for this to be about LLMs/AI; he wrote the story long before ChatGPT. This makes it even more fascinating, because he imagined a being with total knowledge but no agency or imagination (and thus, no counterfactual reasoning), and this being uncannily mirrors the behavior of an LLM.

Happy holidays to everyone with this holiday post!

[Click title for image]

Our version control debt has finally caught up with us. I’m working on a Jupyter notebook for the Causal Book using a helper LLM, and we seem to be approaching the absolute finality here..

For the record, this horrible naming convention is not a result of my input; it’s entirely derived from the training data. And here’s what Gemini says about it:

This is a hilarious catch. It looks like the AI has perfectly replicated the human panic of saving files as Project_Final_Final_v2_REAL_FINAL.doc.

Human panic, or uniquely human optimism for version control, you decide!

[Click title for image]

Is AI the bicycle for the mind (following Steve Jobs), or is it the mind riding the bicycle (quite literally like the 20-year-old robot here even before the Transformer)?

In this article, Tim O’Reilly, countering Jensen Huang’s keynote remarks, frames this as a question of function: Is AI a tool or a worker using other tools? He explores a number of premises and concludes the LLM is “a tool that knows it’s a tool.”

This may actually be an apt way to describe an agent: a tool that knows it’s a tool -and- can use other tools.

Credit for the picture goes to Koji Sasahara / AP.

In matching for causal inference, we often focus too much on reducing bias and too little on variance. This has generalizability implications. This paper, while not focused on external validity, tackles the bias-variance trade-off in matching for diff-in-diff:

While matching on covariates may reduce bias by creating a more comparable control group, this often comes at the cost of higher variance. Matching discards non-comparable control units, limiting the sample and, in turn, jeopardizing the precision of the estimate. That’s a good reminder.

How about matching also on pre-treatment outcomes?

Here, the win is clear: it’s a guaranteed reduction in variance because the sample-size trade-off no longer applies once matching is performed. So, while a reduction in bias isn’t a mathematical certainty, this makes additionally matching on pre-treatment outcomes a potentially optimal strategy when both bias and variance are a concern.

The generalizability implications will be part of the matching chapter of the Causal Book.

PS: Yes, matching on pre-treatment outcomes reduces the diff-in-diff estimator to diff-in-means and may introduce bias, but that’s a discussion for another day (and chapter).

[Click title for image]

That tagline with the made-up graph instantly raises a red flag, but the core idea is surprisingly cool. Windsurf’s new owner, Cognition (following the failed OpenAI acquisition), has shipped a new feature called Codemaps.

The idea is to significantly ease codebase understanding. This actually looks incredibly useful, especially when tackling an existing codebase, say, an open-source project, and it might get me to switch over from Cursor.

Source

I’m terribly sad to learn that the first consumer humanoid robot marketed to load the dishwasher (finally!) is essentially a proxy operated remotely by a human (oh no). The automation it offers is akin to hiring a teenager to mow your lawn remotely, yet it introduces privacy and latency nightmares.

How much longer must we keep loading the dishes? Until Nvidia’s valuation hits $10 trillion? Let’s buy more stonks. I’m losing my patience here.

Source – Neo Order Page

I first came across this paper while writing the Machine Learning Using IV chapter of the Causal Book. Revisiting it today, I remain struck by its central finding: about 95% of the empirical TSLS (Two-Stage Least Squares) models surveyed here claim to estimate the Local Average Treatment Effect (LATE), but they fail to meet the necessary conditions to do so.

The failure is mainly due to not controlling for covariates nonparametrically. That is to say, in attempting to correct for selection bias (endogeneity) using IVs, causal modelers inadvertently introduce significant specification bias, thereby theoretically nullifying the LATE interpretation.

On a different note, I’ve resumed work on Causal Book. Updates are on the way!

Today, my feed is full of speculation linking the recent AWS layoffs, driven by increased AI automation, to yesterday’s outage. In reality, we don’t really know if AI caused any of it.

What do we know? I read two articles this morning, and one thing that struck me is that AWS was reportedly not able to diagnose the core issue for 75–90 mins. That’s an absurdly long time.

If this timeline is accurate, the extended delay is compelling evidence that critical expertise was either absent or inaccessible when it was most needed, for whatever reason.

Credit for the image goes to Emil Lendof/WSJ.

Source 1 – Source 2