I spend most of my professional life building systems around large language models — not prompting them for answers, but weaving them into workflows where they act as agents with memory, tools, and autonomy. So when I read about Phillip Kerger's result earlier this week, I didn't file it under "interesting math news." I filed it under "the shape of my job just changed."

Let me tell you what happened, and then let me tell you why it matters to anyone who thinks seriously about how we'll work alongside these systems.

The math, in one paragraph, so we're grounded.

There's a 30-year-old open problem in convex optimization. You have a function living in d dimensions, you can query it at points of your choosing, but you only get the function value back — no gradient, no derivative information. This is zeroth-order optimization, and it matters when your "function" is a physical experiment or a simulator: you see the outcome, not the internal math.

In 1996, a researcher named Protasov showed that roughly d² queries are enough to find an optimal point. The best known lower bound? About d — a linear gap. For thirty years, nobody knew whether the answer was nearer to d or closer to d². It's the kind of gap that sits in the back of every optimization theorist's mind: are we leaving a quadratic factor on the table?

Kerger, a professor at UC Berkeley IEOR, now has a proof that the lower bound is Ω(d² / log d). Up to a log factor, Protasov's algorithm was optimal all along. The gap is closed.

That is not the interesting part.

The interesting part is how this proof came to exist.

Kerger had been chipping at the problem for about a year. He'd tried earlier versions of the model — GPT-5.4, GPT-5.5 — and gotten nowhere. The problem was hard enough that the usual approach of "describe the problem, get a candidate proof" didn't come close to working.

Then, after OpenAI proved the CDC Conjecture (another long-standing open problem), a prompting methodology emerged that produced a repeatable pattern for tackling open mathematical problems. Kerger spent time understanding that methodology and then wrote a prompt for this problem.

Ten pages.

Not ten lines. Ten pages of structured context: the mathematical setting spelled out precisely, the approaches he'd already tried and why they failed, the shape of a construction that might work, constraints on what would and wouldn't count as a valid solution. He was effectively doing what an experienced research advisor does for a promising PhD student: bounding the search space with hard-won domain knowledge.

He kicked it off and walked away. One hundred and forty-eight minutes later, GPT-5.6 Sol Pro produced the core construction — a family of hard functions and an adversarial oracle strategy that completed the argument. Kerger checked it, formalized it in Lean 4, and the proof passed.

This is where my brain started buzzing.

Divide the credit however you like:

  • Kerger supplied the question, the year of accumulated failed attempts, the ten-page structured prompt with explicit search constraints, the audit and validation, and the Lean formalization.
  • GPT-5.6 supplied the proof search — literally finding the needle in the haystack that Kerger had already mapped.
  • Lean supplied mechanical verification that the encoded reasoning holds.

What's new here isn't that an AI wrote a proof. What's new is the division of labor that made it possible.

The model didn't understand convex optimization. It didn't wake up one morning inspired by Protasov's old paper. But it did do something most humans can't do: it methodically explored a constrained high-dimensional search space for 148 minutes without fatigue, without losing thread, without getting discouraged. It held the structure of the argument the way only a machine can — not because it's smart, but because it doesn't get bored.

Kerger, in turn, did something the model can't do: he knew which decade-old papers were relevant, which dead ends were truly dead, and what a valid proof in this subfield looks like. He translated that knowledge into a prompt that was simultaneously a research plan and a search constraint. Then he verified the output, because he could.

In my own work, I've been moving toward what I call "agentic scaffolding" — architectures where the human specifies the problem and the constraints at a high level, and one or more AI agents explore the solution space within those bounds, reporting back. Kerger's result is the most extreme validation of this pattern I've ever seen. It's not about replacing the researcher. It's about compressing the iteration loop from "months of trying blind alleys" to "one long session."

But here's where the nuance matters, and I want to be honest about it.

The 148-minute session produced the proof, but it sat on top of a year of Kerger's prior work. The model didn't generate the insight that Protasov's algorithm might be optimal — it generated the specific construction that proves it. The model didn't decide what to prove, or why it matters, or which techniques were likeliest to work. All of that came from a domain expert who had already spent the cognitive labor of refining the question to the point where a guided search could find the answer.

This is not a case of "AI solved a 30-year math problem autonomously." It's a case of "a domain expert used an AI to execute the final, hardest search step in a year-long research program." The distinction matters because it tells us something about where this technology is useful and where it isn't.

Think about it this way: if a result is reachable with existing techniques, a modern AI model will eventually find it. That means the low-hanging and medium-hanging fruit in any technical field — the problems that are hard but don't require genuinely novel approaches — are about to disappear very fast. Not because the AI is creative, but because it's tireless. Give it a well-constrained search space and enough time, and it will land on the construction that's been waiting there all along.

I find that both exhilarating and humbling. Exhilarating because I can now tackle problems that would have taken a year of blind alleys in a focused week. Humbling because I need to be much more honest about which parts of my work are "searching in a bounded space" versus "conceiving something genuinely new."

So what does this mean for someone like me, who builds systems around these models every day?

First, it's sharpened my thinking about prompt design. Kerger's ten-page prompt isn't an anomaly — it's a template. The more domain context I can encode, the more dead ends I can pre-eliminate, the more likely the model is to find the solution I'm looking for. My job is increasingly about compression: taking everything I know about a problem and translating it into constraints that guide search without over-constraining it.

Second, it's made me take formal verification more seriously. Lean's role in this story isn't decorative — it's credibility infrastructure. Kerger didn't trust the model's output because it looked plausible. He verified it, mechanically. That's the standard we should be holding AI-generated work to, whether it's a math proof or a database migration script.

Third, it's clarified the shape of the team that builds these systems. The winning configuration isn't "human plus AI." It's "domain expert plus AI search plus mechanical verification." Three distinct capabilities, each doing what it does best.

I don't know exactly what my workflows will look like in two years. But I know what they should look like: I spend most of my time figuring out what questions to ask and how to constrain the search space. The model spends most of its time searching. A type checker, test suite, or formal verifier spends whatever time it needs to confirm the result.

That's the blueprint Kerger just published. Not in the math — in the method.

I plan to study it closely.