Glasseye
Issue 22: February 2026
In this month’s issue:
The dunghill on how tech bros use Bayesian statistics to signal their rationality.
Are you being de-skilled by the prompt? And, if so, what can you do about it? The white stuff reviews a recent paper.
Never again be humiliated by your own work. Semi-supervised gives you three essential checks for any piece of analysis.
The dunghill
What’s going on with tech bros and their “priors”? And why 10x something? Why not 3x it? Or 5x it? Or maybe just “turn it up”? And is the last thing someone told you really a “data point”? Was that surprising news worth describing as “out of sample”? In short, why is Silicon Valley suddenly talking and writing like Gelman’s Bayesian Data Analysis is a style guide?
If this were just an irritating trend, then it probably wouldn’t be worth our attention. Unfortunately, it seems to be symptomatic of something else. A nasty bit of hubris.
The truth is this is about rationality signalling (I’m having this if no one else has claimed it) - the attempt to convey the impression that the speaker’s thought processes are identical to the workings of a Bayesian model. Their current beliefs, their “priors”, are laid out before them with perfect clarity; every new fact they learn, every new data point, modifies these beliefs in the most rational way possible, that is through the application of Bayes’ Theorem. In other words, the bro is a relentless, unstoppable calculating machine, with a rational response to anything and anyone.
Admittedly, the philosophy of the website LessWrong (the wellspring of this movement, with posts like Update yourself incrementally) is more subtle than this. The authors there do very much focus on the cognitive biases that get in the way of flawless Bayesian processing. But what subtlety there is in the strange, slightly cultish doctrine of The Sequences (the teachings of their master, Eliezer Yudkowsky) was lost when it was absorbed into the vocabulary of Silicon Valley. Here the point is not to emphasise vulnerability or analyse the causes of failure, but to project superhuman competence.
But look, if there’s one belief that it’s rational to hold, given the overwhelming evidence, then surely it’s this: we are the least Bayesian animal out there. An earthworm, I’d wager, is more Bayesian than any human being, untroubled as it is by wounded pride, daddy-issues, emotional complexes, etc. We are so far off being Bayesian in our everyday thinking that even to suggest it as a goal is misleading. Better to accept that this mode of thought requires an intense effort, that it goes against the grain, and that it is unlikely to ever completely succeed. Fooling yourself into thinking that it’s your default mode is the opposite of insightful. I certainly don’t know the vast majority of my “priors”. Do you know yours?
Talking of fooling yourself, perhaps the least rational of all behaviours is betting the house on something happening (say the emergence of consciousness in a tin shed in Memphis), just because you’d really really like it to happen.
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.
The white stuff
Someone - some self-effacing, anonymous contributor - took great care in planning out the polars Python library. This relatively new data manipulation package is a masterpiece of minimalism. There is one easily-learnt syntax for constructing expressions, but the expressions themselves are given different meanings in different contexts (for example, in the context of a selection, a filter, an aggregation, etc.) The result is both highly constrained and extremely flexible. Achieving such a balance is an art. Create something too simple and it gets butchered by workarounds, too complex and we never quite get the hang of it (ahem Regex).
But I missed all this when it was first released. Why? Because its rise to prominence coincided with the emergence of LLM-assisted coding. Although I skim read the documentation and convinced myself that it was all going in at some level, I didn’t really feel it. A couple of weeks ago, I decided enough was enough, pulled the plug (temporarily) on my little agent friends and invested a few hours in understanding how polars really works. That was when I started to appreciate the design, and I’m sure my coding benefited.
But I am, after all, a sample of one, and that, as we all know, is never good enough - which is why the paper How AI Impacts Skill Formation (laudably commissioned by the Anthropic foundation) is so timely. In fact, career-wise, it may be one of the most important papers you ever read.
The authors express a concern that may have crossed your mind. If, as seems increasingly likely, coding agents will always require human agents to direct and debug them, and if junior coders are, through their reliance on coding agents, losing the skills needed to carry out these tasks, then, while we might be ok for the time being, there will come a day when we run out of road - that is out of people who know how to code.
There’s good news in this paper, and there’s bad. The bad is that their randomised controlled study confirms our worst fears: “We find that AI use impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average.” The good is that when we dig into results from the AI-assisted group, there are lessons to be learnt about how we can have and eat cake. The authors found that those who scored highest on skill acquisition “only asked AI conceptual questions instead of code generation or asked for explanations to accompany generated code; these usage patterns demonstrate a high level of cognitive engagement.” The lesson then is: know thyself. If you don’t have the self-discipline or patience to follow up code generation with questions (that’s me), then ask first and code later (by yourself). Note, this only applies to work in areas that you do not yet understand. If it’s familiar territory, then other than to keep your tools sharp, there’s no reason not to let those agents whir.
But there’s another reason to keep the tools sharp. If the big AI players are unable to recoup their losses elsewhere, then they might be forced to squeeze as much as they can from products where the use cases are real. Might the long-term strategy be: keep the price low, wait until everyone has become dependent, not just on LLMs (they are a dime a dozen) but on tasty, IP-laden products like Claude Code, and then… jack it up?1
Semi-supervised
First, apologies to anyone I’ve worked with, managed, or mentored over the last twenty-five years. You will have heard this before. Feel free to skip, although there’s some new stuff here too.
I’m talking about my three tests - three simple quality assurance tests that fit almost any piece of analysis work. They are quick and easy to do. Find yourself pressed for time, then do these as a minimum, and you can be almost certain your work will stand up to scrutiny.
The triangulation test: Find another way of arriving at roughly the same result. For example, you might be estimating the size of a potential market for a new product by using the purchasing behaviour of individuals. This is a bottom-up approach. Test that your answer is sane by doing a top-down calculation, starting with the populations of the UK and narrowing it down to your potential market. If the two techniques produce roughly the same number, you can be more confident in your estimate. Sometimes it is reasonable to assume that the two techniques will arrive at exactly the same result. If it turns out there’s a difference, then debug.
The spot check: Defined as a test made without warning on a randomly chosen subject. Your analysis work might pass the triangulation test but still, at a more detailed level, there are problems with your work, perhaps errors that get averaged out in the aggregated data. This is a job for the spot test. Pick five to ten records at random and follow them through whatever process or algorithm you have built. If everything happens as you’d expect, then you should be ok at the nuts and bolts level.
The bastard test: You may have been extremely diligent in the last two tests but unfortunately you make a typo on a number in the final presentation and are judged, perhaps unfairly, on that. This would have been picked up on with the bastard test. Imagine you are another person, a person who hates you with a passion. (I find it helpful to picture the famous mathematician G. H. Hardy in the pose shown below.) Run through your work and try to catch yourself out. Make quick sense-checking calculations in your head and examine the whole thing for plausibility. The bastard test can now be supplemented (not replaced - see this month’s Dunghill) by the digital bastard test. So long as there are no confidentiality or data protection issues you can run your work past an LLM (Anthropic’s Opus is particularly good for this) instructing it to search aggressively for errors.
One more tip - a technique not a test: I find it useful to pick out what I call guideline numbers (after the lines used to align objects on a digital canvas). These are numbers that thread through all of your calculations and data transformations, while remaining the same. They should be recalculated at every step of the process and if they do change, it is a sure sign that something has gone wrong. Some simple examples are: the number of subjects in a test, or the minimum and maximum date covered by a data set.
Please do send me your questions and work dilemmas. You can DM me on substack or email me at simon@coppelia
From Coppelia
Despite all the griping in this issue’s white stuff, this, for me, has been the month of Claude Code. I now have an army of personal CLI tools written in Rust that do exactly what I want them to do. Whether I will actually use them is another thing. Two that I am particularly happy with are:
pangraph: a universal graph converter, that allows me to switch between Mermaid, Graphviz, the Obsidian Canvas, SimpleMind Pro, and many others that I haven’t even heard of!
td: a CLI tool for managing minimalist todo.txt files (which I love). A nice tool already exists, but I wanted one that handles time contexts.
Use both at your own risk - I can’t vouch for my collaborator (who pretty much did all the work!).
After the spectacular wrong turn of synthetic respondents, it is encouraging to see what looks like an original and intelligent use of digital in the usually stagnant world of quantitative research. Take a look at Polis. (Thanks to Mark Potts for pointing me in their direction!)
If you’ve enjoyed this newsletter or have any other feedback, please leave a comment.
Thanks @pstobbs!
Ah yes I fully agree on your final test! I always ask myself "If I presented this at a conference, what things would the cynical old professor point out, and can I make a plot to convince them that's not the case"
Also I have been diving into Gelman's Bayesian Data Analysis this week so good to see it get a mention!