Glasseye
Issue 27: July 2026
In this month’s issue:
The white stuff talks to UCL’s Sam Livingstone about using LLMs for mathematics and about the future of computational statistics.
The confusion behind data fusion in this month’s dunghill.
Semi-supervised takes you on a tour of my ultra-minimalist data science environment.
The white stuff
From papers to professors - I’ve decided to extend the brief of our monthly check in on academia to include interviews with academics whose work is relevant to the daily grind of data science. This month I’m talking to Sam Livingstone, Associate Professor at UCL’s Department of Statistical Science about the integration of machine learning and statistics and about how to use LLMs without losing control of your thinking.
Simon: So Sam, thank you for talking me. I read on your blog that you see yourself as working at the intersection of probability, computational statistics, and machine learning. These are areas which have been separated out in academia for various historical reasons, but we, as data scientists, are always working within this intersection. For that reason, your field of study is fascinating to us. It would be great to understand how you got into it.
Sam: Well, my background was more mathematics. I followed an honours degree in mathematics with a master’s in the same subject, so I very much thought of myself as a mathematician. Then I went into industry for a couple of years, as a data scientist in an operations research team. I was doing demand and revenue forecasting for transport schemes, and I wanted to do things right; I wanted to understand what I was doing, but I found the needs of the industry insisted that I didn’t go too deep, that I didn’t dwell too much on the more abstract questions (and it made a lot of sense not to do that because we were on a budget). So I thought that this wasn’t the best place to do this kind of exploration. I went back and did another master’s in statistics, where it does make sense to think more deeply and try to get to the right answer, even if it takes quite a lot longer.
Since then I’ve lived in a world where you’ve got statisticians - and increasingly now people from machine learning and all sorts of other applied fields, epidemiology, econometrics - designing models and trying to calibrate them to data, to learn something. And they’re using increasingly varied and complex algorithms to fit those models. I study those algorithms. How they work. How they perform. Do some algorithms perform better than others? Can we design new algorithms that will work better?
Simon: Leo Breiman wrote a famous paper in the early 2000s on the two cultures of data modelling and machine learning, how they were divided, and how they could learn from each other. Do you think that is still the case?
Sam: So there was a time, a few decades ago, when there was this nice blending between the cultures, because people had all the right sets of skills to help each other out. And it was exciting, and they were converging on the idea that probabilistic modelling was the right direction. That was when I started doing my research and it really felt like there was going to be a complete synergy.
But then deep learning came along and it was very much not probabilistic at the outset, very computer science-y in the way it was explained. Geoff Hinton was a probabilistic thinker, but then the engineers took hold of it and focused mainly on the architecture and similar things. Having got great empirical results, they put the probabilistic questions aside for a while. This fragmented the fields yet again.
And I would say there’s once again more of a blending, in which statisticians study deep learning algorithms and try to appreciate the statistical properties that they do have. But it took a good five to ten years to decipher the literature because it was written in such a different language: flow diagrams and computer architectures, very few equations. We just were speaking a different language. Statisticians are a bit purist when it comes to insisting that things are written up properly. And that’s on us. But similarly, the machine learning people from the more engineering side can be a bit relaxed and sloppy.
Simon: I came across your work in your blog post, Will AI ruin mathematics?, about the role of large language models and agents in mathematics. It caught my interest because you discuss many of the issues that data scientists are currently wrestling with - Is my role redundant? Should I use LLMs at all and if so how? Is there a limit on what is achievable using LLMs? What is hype and what is real? - and it is fascinating to see these same concerns occupying someone who is much more focused on the mathematics. Could you take us through your thoughts on each of these issues?
Sam: Speaking as a university academic, I don’t think my role is going to become redundant. There are one or two people in my department who panic now and again. But this is not the first time in higher education that people have felt, “Oh no, I’m not the keeper of all this knowledge any more. What am I going to do? Maybe people don’t want me?” But if that were the case then universities as a place to teach should have been redundant from the moment the printing press was invented.
LLMs are just the latest in a long line of innovations that threaten this “secret knowledge” model. But I don’t think that model was correct in the first place. A big part of why people commit to coming to a university is for someone to be there and take them through it, and hold them accountable, and inspire them and set the right assessments, to challenge them. You have to go through a lot of pain to learn things, to really get them into your head, to really grow and evolve. We ask people to do these things because we think it will make them have a happier and healthier life, be able to make more intelligent life decisions, think more clearly, in all aspects of their life. It doesn’t really matter what they’re learning to some extent.
Simon: This seems like a good point at which to bring up one of the biggest concerns about the use of LLMs in both mathematics and data science. Will using them degrade our problem-solving abilities in any way?
Sam: I’m not someone who believes you shouldn’t use LLMs at all. I think you should use them, environmental concerns aside (I think that’s a separate thing). But I think there’s a fine balance between using them to enhance your understanding and using them to overextend to the point that you actually limit your own understanding in the long term. And I think if you overuse them in that way, it’s a bit of a false economy. Eventually you don’t know what you’re doing anymore.
Simon: So where for you would that line be, when striking a balance?
Sam: Well that’s the magic question, right? But put it like this: everyone in academia agrees that it’s still important to teach students the full linear algebra course, where we make them do matrix operations by hand, let’s say twenty times, so that they really get the vibe of how long the different algorithms take, what they’re all doing, what the inner workings are. Everyone also then agrees that once you’ve got that basic understanding you can leave these calculations behind. If we were to scrap that part of the course and just say: inverting a matrix is a thing, and you do it by typing “solve”, then I think we’d lose a lot; people would stop developing new and better algorithms for doing similar tasks. And I think this same idea can be applied more generally.
Simon: So the basic principle is, at the very least, delegate tasks to LLMs that you understand and could have done yourself, but which are tedious, time-consuming and might have got you lost in the weeds.
Sam: Exactly. If you’ve got a good high-level picture and it’s just some tedious technical things that you need to do that are sort of orthogonal. Usually I’ve tailored these things to the point where I can ask a very concrete question. In fact, a big part of the role of a mathematician is not at the problem-solving end. It’s about problem-defining - starting at a high level and packaging things up into a series of concrete questions that we can show to be true or false.
Simon: Returning to Breiman’s two cultures, do you think perhaps this focus on higher-level problem solving, brought about by coding agents, might do something to bridge the gap still further?
Sam: That’s an interesting question. I think it’s been the generations that have changed thinking. In statistics, in the generation before me, you were either a frequentist or a Bayesian, and if you were in one camp you’d hate the other. My generation is much more pragmatic. We learned about both and saw that both had been used successfully in different domains. And the generation after me are more comfortable blending machine learning approaches into their statistics, while I still think of these things as a bit separate.
Whether AI tools can help that integration is another thing. It’s definitely true that I can do a lot more coding now than I could. Maybe in the same way, people on the more computational side might feel that the mathematical side is more accessible to them. So there may be a kind of blending of ideas from that. I haven’t seen that much evidence of it so far, but I think it’s early days for things like that.
Simon: It is true that there is a lot of uncertainty, and I think that is what makes people anxious. What do you think your field is going to look like in five to ten years’ time?
Sam: It’s really hard to say, and I think anyone who tries to make these kinds of predictions is going to look very silly. That includes the heads of all the AI firms who are confident in predicting that all white-collar jobs will be automated. I think that it is foolish to make a prediction like that.
Simon: Thank you for your time, Sam. It’s been an incredibly interesting conversation!
Sam: A pleasure, thank you.
Semi-supervised
Following March’s semi-supervised on my post-LLM tool choices, I’ve been asked to say a little more about my set-up for data science work. Honestly I could bore you into a stupor on this one…
Home is a Ghostty terminal emulator, usually divided into three panes: top left, bash prompt; bottom left, Claude Code; right, Neovim. I’m not a command-line zealot, so of course I visit the browser, and occasionally sin with Finder, but the terminal is where I want to be - a peaceful, distraction-free environment that is completely under my control.
I’ve been able to retreat more often to my terminal paradise because I have ditched GUI IDEs and Jupyter notebooks and replaced them with Neovim. This is a relatively extreme position for a data scientist, although common for developers. Why would I do such a thing? Well for one, I was sick of my IDE (PyCharm then VS Code then Cursor) changing configuration behind the scenes and being overly needy about acknowledging its latest feature. There is also the visual claustrophobia of too many graphical objects demanding attention. By contrast, Vim is a modal editor. It’s mouseless, which limits the possibilities for screen objects, so it’s visually sparse. There are no tabs (unless you absolutely want them) and you navigate with your brain and keystrokes.
Another reason that this environment has come into its own is that configuration, painful by hand, can now be effortlessly and neatly dealt with using Claude Code. The Neovim environment is customisable to a fault, but with Claude Code you can just ask for what you want in prose and you have it. Mine is set up for writing (extensions: Pencil, Limelight, Vale) when I open markdown and coding when I open everything else. In fact I have a Claude Code skill that looks after all my configurations across Ghostty, Neovim and zshrc - cleaning up, syncing, and logging my key mappings in a reference database. It can even sync a visual theme across Neovim, Ghostty and Obsidian.
My replacement for notebooks is a combination of Quarto and Claude Code. Quarto has a number of advantages over Jupyter notebooks. It is structurally simpler (just markdown and fenced code blocks rather than JSON), which means it integrates better with other tools, and it is geared towards publishing pretty things (pdfs, html, slides) which is usually my deliverable to the client. Quarto is editable within Neovim, and the Molten Neovim plugin makes the code blocks runnable, giving me all the functionality of a Jupyter notebook. Furthermore I can use Claude Code to direct the layout of my Quarto output without getting too caught up in the formatting details.
On Claude Code itself - yes, it lives in its bottom left pane, and yes, this means no LLM-based prediction in the coding editor. But I am happy with this. It clearly separates our roles, and makes me think about what I should do versus what it should do. I give it a job, usually on a different worktree, and then I review it. Or I ask it how to do something, and then I do it. Its separate pane is also convenient when I use it to handle administrative and versioning tasks.
Finally, I have a growing library of Claude Code skills, mostly around repository set-up for Python, Rust and TypeScript1 projects (during which they set up a CLAUDE.md file from a template, which in turn does a lot of standardisation work) and general administration, including a nice one for copy-editing (which makes criticisms of my prose using grammar references and various uptight conventions from The Economist style guide. But never about actual prose style - I don’t want to sound like Claude Code.)
And that’s it. For now.
Please do send me your questions and work dilemmas. You can DM me on substack or email me at simon@coppelia
The dunghill
I missed an obvious entry in April’s dictionary of bullshit for statistics, AI and data science. For as long as there have been frustrated clients and accommodating agencies, there has been something called “data fusion”. To be fair there are some things that might legitimately be given this name. There’s plain old data integration; there’s a problem in robotics about how to integrate information from different sensors; there’s the Google Cloud Data Fusion product. There’s also the problem of finding the best match for an individual within a dataset. And the fascinating problem of how you might construct a pseudo-control group for observational data. But none of these correspond to “data fusion” as I have heard it used ad nauseam. In fact, nothing can correspond to it - it’s meaningless.
Here’s what usually happens. An agency pitches some product or service to a client that involves using its business data. The client likes the idea but notes that it can only work if the agency can connect up two or more datasets that the client has been struggling to join together, since there is no unique identifier common to both. “Hmm,” says the agency, “We’ll see what we can do.” Fortunately someone on the agency team recalls a previous project in which that same problem was solved using something called “data fusion”. Of course! That sounds perfect! “Fusion” means joining things but it’s also quite clearly science.
With the help of data fusion, the agency wins the job. The client data is then passed to the internal data team, who are told to fuse it. Which means what? You can of course find some variables that are common to both data sets, say age band, gender and location, and then aggregate both datasets up to this level, and then join. But that gives you an aggregate-level dataset, not the “fused” individual level data set that was promised to the client. The fact is that you can’t magic your way down to a lower level of integration. No amount of pseudo-scientific probabilistic matching and modelling is going to make this happen.
Unfortunately the agency data science team are nearly all recent graduates, and, knowing no better, quite reasonably assume that a term that has been knocking about for decades means something - if only they can figure out what! In the end they come up with something awful, which they feel bad about and heavily caveat - but what else could they do?
At this point the data fusion is complete. The agency logs the success in its collective memory, to be drawn on in some future pitch, and the cycle continues.
If you have some particularly noxious bullshit that you would like to share then I’d love to hear from you. DM me on substack or email me at simon@coppelia.io.
From Coppelia
This month for the first time I felt the need to point out to a client that the report I was handing over was not written by AI. I hope it was obvious. I hope I don’t sound like an LLM, even in the driest of reports. But who knows? This is new territory and new norms will need to be established.
We are very happy that Mark Bulling, the earliest of early adopters, frequently name-checked in Glasseye, has joined the Melt Collective. I can no longer pass his discoveries off as my own.
A reminder that if you are interested in the areas covered by Glasseye and you would like some face-to-face support, then Coppelia offers tailored mentoring packages as well as training workshops on a wide range of topics. Just let me know at simon@coppelia.io.
If you’ve enjoyed this newsletter or have any other feedback, please leave a comment.
My Rust is terrible. My Typescript worse. But these are usually for components that are tightly-defined and then vibe-coded, or, in the case of Rust, translated from Python for speed.