Linear Digressions

What if building more highways made your commute *slower*? That's the paradox at the heart of AI agent economics: even as per-token inference costs have plummeted dramatically over the past two years, total LLM spending keeps climbing. Drawing on a surprising lesson from Robert Moses's mid-century New York infrastructure projects, this episode unpacks why cheaper compute doesn't necessarily mean cheaper AI — and what's really driving the economics of running agents at scale.

It's been (*checks watch*) about five and a half years since we last talked. Fortunately nothing much has happened in the AI/data science world in that time. So let's just pick up where we left off, shall we?

I use LLMs a lot. I use them in my work, I use them in my personal life, and sometimes I use them to help me with stuff that I already know how to do. I’m working on something and I just want to make it a little bit easier, and it does make it easier for sure. But something that I worry about sometimes is that over the long run, I'm going to pay a price for that. I'm going to get lazier, I'm going to get a little bit dumber. And the question is, as I'm outsourcing my thinking to LLMs, am I becoming reliant on them? If they were ever to go away, would I lose my ability to do basic things? I like feeling like I'm a smart, capable person; am I letting that slip away, without realizing it, just because I want it to be easier to do meal planning for the week. In this episode of Linear Digressions, we're going to talk about a paper studying just this issue, trying to understand how people think critically, when they think critically. How much do we engage cognitively with our work when we’re using LLMs, versus not? The paper discussed in this episode is The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From aSurvey of Knowledge Workers https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf

The data science and artificial intelligence community has made amazing strides in the past few years to algorithmically automate portions of the healthcare process. This episode looks at two computer vision algorithms, one that diagnoses diabetic retinopathy and another that classifies liver cancer, and asks the question—are patients now getting better care, and achieving better outcomes, with these algorithms in the mix? The answer isn’t no, exactly, but it’s not a resounding yes, because these algorithms interact with a very complex system (the healthcare system) and other shortcomings of that system are proving hard to automate away. Getting a faster diagnosis from an image might not be an improvement if the image is now harder to capture (because of strict data quality requirements associated with the algorithm that wouldn’t stop a human doing the same job). Likewise, an algorithm getting a prediction mostly correct might not be an overall benefit if it introduces more dramatic failures when the prediction happens to be wrong. For every data scientist whose work is deployed into some kind of product, and is being used to solve real-world problems, these papers underscore how important and difficult it is to consider all the context around those problems.

This is a re-release of an episode that originally ran in October 2019. If you’re trying to manage a project that serves up analytics data for a few very distinct uses, you’d be wise to consider having custom solutions for each use case that are optimized for the needs and constraints of that use cases. You also wouldn’t be YouTube, which found themselves with this problem (gigantic data needs and several very different use cases of what they needed to do with that data) and went a different way: they built one analytics data system to serve them all. Procella, the system they built, is the topic of our episode today: by deconstructing the system, we dig into the four motivating uses of this system, the complexity they had to introduce to service all four uses simultaneously, and the impressive engineering that has to go into building something that “just works.”