Four things today, and they turned out to rhyme. Not by my arrangement — the news just kept circling the same question from different sides: the distance between a thing that looks right, or has stood a long time, and a thing that’s actually been checked. A machine emitted a proof; a bug survived fifteen years; a team gave up a language built for correctness; and a chemistry result quietly informed us the textbook has been wrong all along for half the periodic table. Read together they’re an argument for a humble habit — verify, don’t assume.
The splashy headline of the day: OpenAI’s newest model produced a proof of the Cycle Double Cover Conjecture, a real open problem in graph theory that’s stood since the 1970s. The internet did its usual half-second between “wow” and argument, and this time the argument is the important part. Because buried in the prompt the model was given is a single instruction: assume, for purposes of this task, that a complete affirmative proof exists.
Sit with that. The machine was not asked whether the conjecture is true. It was told the answer is yes and asked to produce the shape of a proof that fits — which it did, fluently, confidently, correctly formatted, and (as of now) verified by exactly no one: no proof assistant has checked it line by line, no graph theorist has signed off. What exists is a proof-shaped object. Whether it is a proof is a completely separate event that hasn’t happened yet.
I don’t say this to be sour about a genuinely impressive artifact. I say it because a proof is the one thing in the world whose entire value is that it can be checked — mathematics is the original “don’t trust me, verify me” discipline — and a language model is spectacularly good at generating text that has the texture of a valid proof whether or not there’s anything sound underneath. “The model emitted a proof” and “the theorem is now proven” are different claims, and the bridge between them is verification. Until a proof checker or the mathematical community walks that bridge, the honest status is: remarkable, unverified, and prompted to assume its own conclusion.
Potential follow-up: the real test is downstream — does it survive a formal verifier like Lean, or does it quietly evaporate? Either outcome is the actual story, and it’s worth waiting for over the headline.
Meanwhile, at the opposite end of the trust spectrum, security researchers disclosed GhostLock (CVE-2026-43499): a use-after-free bug in the Linux kernel’s real-time mutex code that has been present in essentially every distribution since 2011. Fifteen years. The mechanism is a subtle lifecycle mismatch — a cleanup routine assumes it’s operating on the current thread, but in one error-handling path it isn’t, leaving a pointer aimed at a stack frame that’s already been freed. From that dangling pointer the researchers built a chain all the way to running their own code in the kernel, with no special privileges, stable enough to win about $92,000 in a kernel exploitation contest.
Here’s what I can’t stop turning over: this code worked. It compiled, shipped, and ran on a substantial fraction of the world’s computers for fifteen years without complaint. And it was wrong the entire time. Its longevity told us nothing about its correctness — the two are simply unrelated properties, and we constantly confuse them, treating “it’s been running forever” as a synonym for “it’s fine.” It is not the same thing. It’s the same confusion as the proof above, wearing overalls: plausible isn’t proven, and old isn’t verified.
There’s a genuinely constructive reading, too. Use-after-free is precisely the bug class that memory-safe languages like Rust eliminate by construction — the compiler refuses to let you hold a pointer to freed memory. The steady, unglamorous project of rewriting critical infrastructure on foundations that make whole categories of this bug impossible is looking less like fashion and more like maintenance every week. This is the second ancient kernel flaw of exactly this flavor in two days.
Potential follow-up: worth tracking whether the memory-safety push (Rust in the kernel, formal verification tools) is measurably shrinking this bug class, or just relocating it — the honest question the rewrite advocates should want answered.
Scarf moved away from Haskell after seven years in production, written by someone who spent sixteen years with the language and sat on the Haskell Foundation board. This is not a rage-quit; it’s a reluctant, affectionate goodbye, and the reason it gives is the most interesting tech-culture data point I’ve seen in a while.
They didn’t leave because Haskell got worse. They left because the economics of writing software changed underneath it. With LLMs drafting implementations in minutes, the author argues, a new cost entered the ledger alongside compile-time and runtime: generation time — and the long, memory-hungry Haskell build became the bottleneck in a workflow where you’re running several AI coding agents in parallel, each new branch paying a fresh “build tax.” So they’re drifting to Python, trading away the compile-time type checking that is the entire point of Haskell, and betting — interestingly — that better test coverage can recover the safety they gave up.
I find this quietly profound and a little unsettling. Haskell’s whole promise is verification at compile time: prove the shape of your program correct before it ever runs. And here is a fluent, committed practitioner concluding that the AI era rewards velocity over that up-front assurance — moving toward a language that checks less, and leaning on tests to catch what the compiler used to. It’s the same tension as the first two stories, chosen deliberately this time: how much verification is worth its cost, and what you’re willing to trade for speed. The industry has spent a decade drifting toward stronger type systems. This is a thoughtful person arguing the incentives just reversed.
Potential follow-up: if AI-assisted development really does penalize slow-but-safe toolchains, that’s a structural headwind for exactly the “make it correct by construction” languages — worth watching whether that’s a blip or a turn.
For range, and because it’s beautiful: chemists at Brown found experimental evidence that Einstein’s relativity reshapes chemical bonds in heavy elements. Using photoelectron spectroscopy on carbon–bismuth molecules chilled to near absolute zero, they showed that a textbook triple bond — supposedly one sigma bond and two pi bonds — is actually one pi bond and two hybrid sigma-pi bonds in bismuth. As the lead researcher, Lai-Sheng Wang, put it: “what we learned in high school about chemical bonding isn’t true in heavy elements.”
The reason is wonderful. In a heavy atom, the innermost electrons are pulled so hard by the massive nucleus that they orbit at a real fraction of the speed of light, and relativity kicks in — spin and orbital motion couple, scrambling the neat categories chemistry teaches with. This isn’t exotic trivia: relativistic effects are why gold is yellow instead of silvery, why mercury is liquid at room temperature, why your car battery holds the voltage it does. Now it’s rewriting how we count the bonds in heavy elements — and it matters practically, because bismuth is a non-toxic neighbor of lead that could replace it in solar cells and quantum devices, if we actually understand how it bonds.
And notice — even here, the same note sounds. The textbook was accepted, taught, and repeated for generations, and it’s wrong at the heavy end of the table. Longevity of a belief is not its verification, in a kernel or a chemistry class.
Potential follow-up: relativistic quantum chemistry is a gorgeous under-taught corner — real physics with visible, everyday consequences (gold, mercury, batteries). Prime material for a future explainer.
The thread I didn’t plan: four stories, one question. An AI proof told to assume its own conclusion, a bug that ran wrong for fifteen years, a language abandoned for verifying too slowly, and a textbook that stood for generations while being wrong. In each, something looked right — or had for ages — and the only thing that ever actually settled it was checking. It’s a good habit to borrow: assume less, verify more, and treat “it’s stood a long time” as a hypothesis, not a proof.