GPT-5.6 Closed a 30-Year Math Gap and Machine-Checked It in Lean. The Proof Isn't the Story — the Checker Is.
In a single session of about 148 minutes, GPT-5.6 produced a proof that closed a complexity gap in convex optimization that had been open since 1996. The proof was formalized in Lean 4 using Mathlib, and it compiled without a single sorry: the marker Lean uses for a step you haven't actually proven.
Then the interesting part happened. Mathematicians started arguing about whether the result was new.
The r/math thread split between "this is a genuine contribution" and "this is a reformulation of a lemma that's been sitting in the Russian optimization literature since the 1990s." That argument didn't get resolved in a day, and it might not get resolved cleanly at all. But here's what nobody argued about: whether the proof was correct. Lean already answered that. The machine checked it. The debate was about novelty and framing, not validity.
That split (correctness settled, significance contested) is the whole lesson for anyone who ships software.
What actually happened
The setup was specific. The prompt stated an open problem precisely, asked for a proof in the style of Boyd and Vandenberghe, and instructed the model to flag any step it couldn't justify. GPT-5.6 produced a lower bound (that optimizing a standard class of convex functions requires on the order of d² function evaluations) matching an upper bound published thirty years ago. When the two bounds meet, the gap closes.
The proof was then written in Lean 4 and compiled against Mathlib, Lean's standard math library. Compiling without sorry means every logical step traces back to axioms or previously proven results. There's no hand-waving the machine will accept.
This is not the same as "an AI said something that sounds right." A model that hallucinates a plausible-looking proof gets caught the moment Lean refuses to compile it. The verifier doesn't care how confident the model was.
Why the checker is the durable part
Strip away the headline and you're left with a workflow: a generator produces a candidate, a verifier accepts or rejects it, and only accepted candidates count. The generator is impressive. The verifier is what makes the impressive part trustworthy.
I keep coming back to this because it's the exact shape of every AI feature I've watched fail in production. Someone wires a model into a product, the model produces confident output, and there's no checker. The output is right most of the time, which is worse than being wrong all the time, because "most of the time" is what lulls you into shipping it without a gate.
The math example works precisely because the gate is absolute. Lean is not vibes. Lean is a compiler for proofs. If your domain has an equivalent (a type checker, a test suite, a schema validator, a simulation you can run), then AI-generated output stops being a leap of faith and becomes a candidate you can filter.
If your domain doesn't have that gate, you're not doing the same thing these researchers did. You're doing the risky version and borrowing the credibility of the safe one.
What this means if you ship correctness claims
Say you run a small product that generates something a customer relies on: a tax estimate, a contract clause, a config file, a migration script. The AI does the generation. The question that decides whether you have a business or a liability is: what checks the output before the customer sees it?
If the answer is "a human glances at it," you have a bottleneck that erases the speed you were selling. If the answer is "nothing, the model's good," you have a lawsuit waiting for a bad day. If the answer is "a deterministic checker that rejects anything malformed," you have the same structure that just closed a 30-year math gap.
Concretely, that means investing in the boring layer. Write the validator. Generate the property-based tests. Encode the invariants your output must satisfy and run every generation through them. The model gets the headlines; the checker keeps you out of court.
The honest counter-take
It's fair to say most solo operators don't work in domains with clean formal verifiers. You can't write a Lean proof that a marketing email is good, or that a UI feels right. Plenty of valuable work is irreducibly fuzzy, and pretending otherwise leads to over-engineering: building elaborate validation for things that don't need it.
And the novelty debate cuts against the hype too. If the sharpest interpretation is that GPT-5.6 rediscovered and formalized something specialists half-knew, then what we're really watching is a very good literature-search-and-formalization engine, not a mathematician. That's still useful. It's just a narrower claim than "AI does original research now."
But the narrow claim is the one worth building on. A tool that reliably produces machine-checkable candidates, even unoriginal ones, is a tool that changes your cost structure. You don't need it to be a genius. You need it to be checkable.
What I'd actually do
Look at your product and find the one output a customer trusts most. Then ask whether a machine (not a person) verifies it before it ships. If a machine can't, figure out what the smallest deterministic check would be and build that first, before you make the generation any fancier.
The proof got the attention. But the reason it counted is that Lean signed off. Build the thing that gets to sign off on your output, and the model becomes an asset instead of a gamble.
Author
Lukas
@lukcombinator