The pattern behind AI's advances in math explains where it fails in production

In May 2026, an internal OpenAI model found a counterexample to the Erdős unit distance conjecture, a problem that had been open since 1946 and had resisted decades of proof attempts. In June, the company published a proof of the cycle double cover (CDC) problem, and in July, solutions to ten other open problems. In September, it published a proof for Navier-Stokes. During the same period, Anthropic formalized Fermat's Last Theorem and advanced bounds on the Riemann hypothesis.

An analysis published on Latent Space by Ankit Maloo tries to answer a more useful question than "are models getting good at math": is there a pattern that lets us predict WHAT type of problem a model will solve next? The answer matters to anyone building with AI, because the same pattern shows up in coding agents, RAG pipelines, and any system that delegates decisions to a model. Understanding where it works is understanding where it will stall in your product.

The complexity model: hints and work

Mathematician WT Gowers, commenting on the proof of the unit distance counterexample, proposes a simple way to measure a problem's difficulty: the minimum sequence of insights (he calls them hints) that an expert would need to reconstruct the solution. His formula is 2^k + t, where k is the number of insights required and t is the work between each one.

The core idea: solving a problem isn't a single flash of insight, it's a sequence of "insight, work, insight, work, solution". An expert needs fewer insights than a beginner because they already carry more background context. The problem is that this metric only works after the solution exists: you can't look at a new problem and predict how many insights it will require before you try.

Humans search breadth-first, models search depth-first

Here's the difference that matters to anyone building a product. A human researcher explores several directions superficially, abandons most of them early, and only commits to one after getting signals that it's worth it, because developing an idea to completion can take months. It's a breadth-first search, limited by the cost of being wrong.

An LLM does the opposite: given a prompt, it pursues one line of reasoning to the end, greedily, producing something that looks like a proof, whether correct or not. Running multiple agents in parallel multiplies this depth-first search: ten agents produce ten complete attempts, each carried through until it stalls or until it looks right.

This would be a waste of compute, according to the article, if there weren't an automatic verifier capable of pruning wrong attempts after they're done. With a fast verifier, it makes sense to spend compute on uncertain ideas: within minutes you know whether a direction worked or not. The limitation is that the verifier only judges finished arguments, never a half-formed idea.

The harness every agent developer already recognizes

The structure used to generate these proofs has three roles that anyone who has built an agent pipeline will recognize:

• Drafter: writes the prompts for the solver model, incorporating what has already failed in previous rounds (negative hints).
• Solver: generates one or several candidate solutions, possibly running subagents in parallel.
• Verifier: checks whether the argument is valid and solves the problem posed.

The prompt OpenAI used for the CDC problem illustrates this in practice: it instructs the model to assume a complete affirmative proof exists (so that it doesn't treat the problem's "open" status, learned during pretraining, as a reason to give up), explicitly lists a series of invalid substitutes for the real proof, and catalogs failure modes that adversarial agents must check in every attempt. Each line of this prompt is, in practice, a path that already failed before, turned into an instruction.

This is exactly the pattern behind coding agents that work well: a loop where the solver writes code, a verifier runs npm test or the compiler, and the result (passed or failed, and why) goes back as context for the next attempt, instead of being discarded.

while not verified:
 solução = solver(prompt, hints_negativos)
 resultado = verifier(solução) # compiler, tests, type checker
 if resultado.falhou:
 hints_negativos.append(resultado.motivo_da_falha)

The branching factor decides where AI works

Gowers points out that his formula ignores a critical variable: how many plausible paths exist at each step of the search, which the article calls the branching factor (b). With b plausible hints at each step and k total steps, the search space grows as b to the power of k. Models have to pursue nearly every plausible path at each intermediate stage, they just manage to do it fast; humans use judgment to keep b small, discarding most branches right away.

This explains why cybersecurity, according to the article, was one of the first areas where AI agents excelled: the branching factor at intermediate steps is low, something like one to two plausible paths per step, even when the knowledge required is high. The shape of the solution is already known in advance; what's missing is execution.

Failures cost the model almost nothing, the human a lot

One of the article's most concrete points is the case of Jacob Tsimerman, a mathematician recently hired by OpenAI, who had already considered the same counterexample hypothesis for unit distance, including testing increasing degrees of number fields, and gave up. In his words:

A very scary dynamic, hard to think through the analytic regimes and retain guiding intuition, consumes much time and frequently doesn't work out.

Jacob Tsimerman, mathematician at OpenAI

For a human, abandoning a direction after weeks with no sign of progress is a rational decision: the cost is working memory, morale, and career. For a model running in parallel with a cheap verifier, that cost barely exists. Tsimerman sums up the advantage:

This may indicate one way that AI systems have an edge: it's not just that they can try all known methods, but they can play for longer and in more treacherous waters than mathematicians without getting overwhelmed.

Jacob Tsimerman, mathematician at OpenAI

The real cost of this kind of search

This advantage isn't free. The Navier-Stokes proof OpenAI published in September, which completes an earlier research program by Córdoba and Martínez-Zoroa, used 10,000 agents and a total of 300 billion tokens over 88 hours, according to the article. That's the kind of number any engineer estimating the cost of an agent architecture in production needs to keep in mind: depth-first search with automatic verification scales, but it scales in compute, not in elegance.

Where AI still has no advantage

Gowers himself points to the limit: problems where the search tree is deep and heavily branched, such that, without rigorous pruning, the search isn't feasible even for a computer. In other words, high b and high k combined, exactly where human intuition still matters.

This has a direct parallel in software engineering. Architecture decisions, choosing between design approaches with no objective right-or-wrong criterion, or debugging an intermittent bug with no reliable reproduction are problems without what the article calls a gradient: there's no intermediate signal of progress that a verifier can measure while the search happens. A study by Metcalfe and Wiebe, cited in the piece, showed that people solving insight problems report zero sense of progress until they find the answer, unlike ordinary problems, where progress is felt gradually.

In short: before putting an autonomous agent to work solving something in production, it's worth asking two things, in this order. Is there a fast, reliable verifier for the final result, whether it's a compiler, a test suite, a security scanner, or an objective acceptance criterion?

And is the problem's branching factor low enough that pursuing every plausible path is feasible in terms of time and token cost? If both answers are yes, delegating to the model tends to pay off. If the answer to either one is no, the model's role is to explore and discard branches faster than a human would alone, not to replace the judgment of whoever is deciding.