IA Watch · Anthropic/Claude news
Claude formalized Fermat's Last Theorem — which is not the same as proving it
On September 4, 2026, Anthropic published the first complete, computer-checked proof of Fermat's Last Theorem in the Lean programming language. Claude wrote it, largely on its own, in 11 days. The eye-catching part isn't that a 350-year-old theorem got a new proof — it's what "formalizing" actually means, and why turning a proof into something a machine can check is a different, and in some ways harder-to-trust, problem than writing the proof in the first place.
1. What actually happened
Fermat's Last Theorem (FLT) states that no positive integers a, b, c satisfy aⁿ + bⁿ = cⁿ for any whole number n greater than 2. Pierre de Fermat scribbled the claim in a book margin around 1637, famously claiming to have "a truly marvelous proof" that the margin was too narrow to contain. No correct proof surfaced for 358 years, until Andrew Wiles published one in 1995 — 129 dense pages that took the mathematical community months to verify.
Anthropic's news isn't a new proof of FLT. It's a formalization of Wiles's proof: a rewrite of the entire logical chain into Lean, a "proof assistant" programming language that can mechanically check every single logical step, with zero trust required in any human reviewer. Tianyi Peng, an Anthropic researcher who also runs an AI-for-formalization lab at Columbia, set Claude loose on the problem mostly to see how far it would get. Over 11 days, largely autonomous, it wrote 13 million lines of Lean code and proved 30,300 intermediate theorems (29,500 of which made it into the final proof) — a feat outside mathematician Kevin Buzzard called "extraordinary," noting the resulting proof needs no assumptions beyond the basic axioms of mathematics itself.
2. Formalizing is not the same as discovering
It's worth being precise here, because it's easy to read this as "AI proves famous 350-year-old math problem," which overstates it. Claude did not discover a new proof of FLT and did not do what Wiles did. It followed an existing, published, simplified route through Wiles's argument (from a well-known exposition by Darmon, Diamond and Taylor) and translated that route, step by trivial step, into a language a computer can verify with certainty.
That distinction matters because the two tasks — discovering a proof and formalizing one — put very different demands on rigor. A human proof, written for other humans, is allowed to skip "obvious" steps and trust the reader's background knowledge. Lean accepts none of that: every single inference has to be spelled out, all the way down to axioms that have already been formally verified. Anthropic contrasts this explicitly with an earlier, separate result where Claude helped produce genuinely novel mathematics on the Riemann hypothesis — this time, the novelty is entirely in the checking, not in the math itself.
3. Why verification is normally the slow part
The reason this distinction is worth a full section: verifying a hard proof has historically been slower and more failure-prone than writing one. Wiles first presented his FLT proof in June 1993. Two months into the community's review, a mathematician spotted a gap serious enough that Wiles spent a year fixing it — almost giving up before finding the repair that let him publish the corrected version in 1995.
FLT isn't an outlier. Thomas Hales's 1998 proof of the Kepler conjecture spent four years in front of a 12-referee panel that eventually settled for "99% certain" rather than fully confirmed (Hales later spent 20 person-years formalizing it properly). Grigori Perelman's 2002 proof of the Poincaré conjecture took roughly four years and three separate 300-page expository write-ups before the community accepted it. And in 1908, a 100,000-mark prize for a correct FLT proof drew 621 incorrect submissions in its first year alone.
The pattern: checking a complex mathematical argument by hand doesn't scale — expert attention is scarce, and a single broken link anywhere in a long logical chain can silently invalidate everything built on top of it. That's exactly the problem automated formalization is aimed at.
4. How a team of Claude agents pulled it off
The formalization effort didn't succeed on the first attempt. Early runs of Claude agents made some early progress but "lost track of the project's state" over time and stopped collaborating effectively — their discarded work still contributed roughly 7% of the final proof's non-boilerplate lines, but the approach didn't scale on its own.
What changed the outcome was pairing Claude with Prove2Me, an open collaborative formalization platform built by Peng's team at Columbia. Prove2Me contributed three things a raw multi-agent setup was missing:
- A shared map of the problem — a directed acyclic graph (DAG) of theorem statements that every agent could consult to decide what to prove next, which kept dozens of agents from duplicating work or losing the thread over multi-day runs.
- Faster compilation — separating theorem statements from their proofs into different files, so Lean didn't have to recompile huge blocks of code for small changes.
- Reusable context — a plain-language description attached to every formal theorem, so agents could search for and reuse existing work instead of reproving the same lemma from scratch.
With that scaffold in place, a swarm of Claude agents (running on a general-purpose internal research model roughly comparable to Claude Fable 5.1) closed out the proof in under two weeks, consuming about six billion output tokens. Human involvement was limited to occasional prioritization nudges from Peng — messages like "push the Mazur theorem to be done soon" — not mathematical problem-solving. The finished proof was checked using only Lean's three standard axioms, and an automated comparator confirmed its final statement matches the standard formulation of FLT already in Lean's community math library, Mathlib.
5. The numbers, and what they're hiding
| Metric | Value |
|---|
| Time to complete | 11 days (agents), under 2 weeks including setup |
| Lean code written | 13 million lines — about 5x the size of Mathlib itself |
| Intermediate theorems proved | 30,300 (29,500 used in the final proof) |
| Output tokens consumed | ~6 billion |
| Human mathematical input | High-level prioritization only, no proof steps |
The 13-million-line figure is less impressive than it sounds: Anthropic itself notes the proof is likely far longer than necessary, partly because Mathlib is unusually concise and well-reviewed while a first-pass automated proof isn't optimized for brevity. A separate, smaller experiment is more telling of where things are headed: using just three personal Claude subscriptions (not an internal research cluster), a team formalized Vinogradov's Three Primes Theorem — a genuinely hard analytic number theory result — in three days using the same Prove2Me approach.
6. Why this matters beyond mathematics
Three things carry over from this story to anything involving AI-generated work that needs trust, not just math:
- Verification is a bottleneck that scales worse than generation. AI systems (including Claude) are already producing more claims, code and results than any team of humans can carefully check. Formal, machine-checkable verification is one of the few approaches that scales with the flood rather than against it — this is the same underlying problem as trusting AI-written code without reading every line, just posed in a domain where "checking" has a mathematically precise meaning.
- The DAG-plus-multi-agent pattern is the real engineering story. The breakthrough wasn't a smarter model sitting alone in a chat window — it was giving many agent instances a shared, structured map of a large problem and a way to avoid duplicating or losing each other's work over an 11-day run. That's the same shape of problem as coordinating multiple coding agents on a large codebase, just in a domain where success or failure is unambiguous.
- Anthropic is explicit that this doesn't replace human mathematicians — Kevin Buzzard's own comment frames it as a tool that "lightens the burden of referees" and helps check the flood of AI-generated math and code now arriving faster than humans can review it, not as a replacement for mathematical understanding or exposition aimed at people.
IA Watch · Novidades da Anthropic/Claude
O Claude formalizou o Último Teorema de Fermat — o que não é a mesma coisa que prová-lo
Em 4 de setembro de 2026, a Anthropic publicou a primeira prova completa e verificada por computador do Último Teorema de Fermat, escrita na linguagem Lean. O Claude escreveu ela, quase sozinho, em 11 dias. A parte chamativa não é que um teorema de 350 anos ganhou uma prova nova — é o que "formalizar" realmente significa, e por que transformar uma prova em algo que uma máquina consegue checar é um problema diferente, e em certos aspectos mais difícil de confiar, do que escrever a prova em si.
1. O que de fato aconteceu
O Último Teorema de Fermat (FLT, na sigla em inglês) afirma que nenhum trio de inteiros positivos a, b, c satisfaz aⁿ + bⁿ = cⁿ pra qualquer número inteiro n maior que 2. Pierre de Fermat rabiscou essa afirmação na margem de um livro por volta de 1637, alegando ter "uma prova verdadeiramente maravilhosa" que a margem era estreita demais pra conter. Nenhuma prova correta surgiu por 358 anos, até Andrew Wiles publicar uma em 1995 — 129 páginas densas que levaram meses pra comunidade matemática verificar.
A novidade da Anthropic não é uma prova nova do FLT. É uma formalização da prova de Wiles: reescrever toda a cadeia lógica em Lean, uma linguagem de programação de "assistente de prova" que consegue checar mecanicamente cada passo lógico, sem precisar confiar em revisor humano nenhum. Tianyi Peng, pesquisador da Anthropic que também toca um laboratório de IA pra formalização na Columbia, soltou o Claude no problema principalmente pra ver até onde ele chegaria. Em 11 dias, majoritariamente de forma autônoma, o Claude escreveu 13 milhões de linhas de código Lean e provou 30.300 teoremas intermediários (29.500 dos quais entraram na prova final) — um feito que o matemático Kevin Buzzard chamou de "extraordinário", notando que a prova resultante não precisa de nenhuma suposição além dos axiomas básicos da própria matemática.
2. Formalizar não é a mesma coisa que descobrir
Vale ser preciso aqui, porque é fácil ler isso como "IA prova problema matemático famoso de 350 anos", o que exagera o feito. O Claude não descobriu uma prova nova do FLT e não fez o que Wiles fez. Ele seguiu um caminho já existente, publicado e simplificado através do argumento de Wiles (de uma exposição conhecida de Darmon, Diamond e Taylor) e traduziu esse caminho, passo a passo trivial, pra uma linguagem que um computador consegue verificar com certeza.
Essa distinção importa porque as duas tarefas — descobrir uma prova e formalizar uma — exigem níveis de rigor bem diferentes. Uma prova humana, escrita pra outros humanos, pode pular passos "óbvios" e confiar no conhecimento de fundo do leitor. O Lean não aceita nada disso: cada inferência precisa ser escrita por extenso, até chegar em axiomas que já foram formalmente verificados. A própria Anthropic contrasta isso com um resultado anterior e separado, em que o Claude ajudou a produzir matemática genuinamente nova sobre a hipótese de Riemann — dessa vez, a novidade está inteiramente na checagem, não na matemática em si.
3. Por que a verificação costuma ser a parte lenta
O motivo dessa distinção merecer uma seção inteira: verificar uma prova difícil historicamente tem sido mais lento e mais sujeito a falhas do que escrevê-la. Wiles apresentou sua prova do FLT pela primeira vez em junho de 1993. Dois meses dentro da revisão da comunidade, um matemático encontrou uma lacuna grave o suficiente pra Wiles passar um ano consertando — quase desistindo antes de encontrar o reparo que permitiu publicar a versão corrigida em 1995.
O FLT não é exceção. A prova de Thomas Hales de 1998 pra conjectura de Kepler passou quatro anos na frente de um painel de 12 revisores que no fim se contentou com "99% de certeza" em vez de confirmação total (Hales depois passou 20 pessoas-ano formalizando ela direito). A prova de Grigori Perelman de 2002 pra conjectura de Poincaré levou cerca de quatro anos e três exposições separadas de 300 páginas até a comunidade aceitar. E em 1908, um prêmio de 100 mil marcos por uma prova correta do FLT atraiu 621 submissões incorretas só no primeiro ano.
O padrão: checar um argumento matemático complexo à mão não escala — atenção especializada é escassa, e um único elo quebrado em qualquer ponto de uma cadeia lógica longa pode invalidar silenciosamente tudo que foi construído em cima dele. É exatamente esse problema que a formalização automatizada tenta resolver.
4. Como um time de agentes Claude conseguiu isso
O esforço de formalização não deu certo na primeira tentativa. As primeiras execuções de agentes Claude fizeram algum progresso inicial mas "perderam o rastro do estado do projeto" com o tempo e pararam de colaborar de forma eficaz — o trabalho descartado deles ainda contribuiu com cerca de 7% das linhas não-repetitivas da prova final, mas a abordagem não escalava sozinha.
O que mudou o resultado foi combinar o Claude com o Prove2Me, uma plataforma colaborativa aberta de formalização construída pelo time de Peng na Columbia. O Prove2Me contribuiu com três coisas que faltavam numa configuração multi-agente crua:
- Um mapa compartilhado do problema — um grafo acíclico dirigido (DAG) de enunciados de teoremas que qualquer agente podia consultar pra decidir o que provar em seguida, o que evitou que dezenas de agentes duplicassem trabalho ou perdessem o fio da meada em execuções de vários dias.
- Compilação mais rápida — separando enunciados de teoremas das suas provas em arquivos diferentes, pra o Lean não precisar recompilar blocos enormes de código a cada mudança pequena.
- Contexto reaproveitável — uma descrição em linguagem natural anexada a cada teorema formal, pra os agentes conseguirem buscar e reaproveitar trabalho já feito em vez de reprovar o mesmo lema do zero.
Com essa estrutura em pé, um enxame de agentes Claude (rodando num modelo de pesquisa interno de propósito geral, aproximadamente comparável ao Claude Fable 5.1) fechou a prova em menos de duas semanas, consumindo cerca de seis bilhões de tokens de saída. A participação humana se limitou a empurrões ocasionais de priorização de Peng — mensagens como "priorizar o teorema de Mazur em breve" — não resolução de problemas matemáticos. A prova final foi checada usando só os três axiomas padrão do Lean, e um comparador automatizado confirmou que o enunciado final bate com a formulação padrão do FLT já presente na biblioteca matemática da comunidade Lean, a Mathlib.
5. Os números, e o que eles escondem
| Métrica | Valor |
|---|
| Tempo até a conclusão | 11 dias (agentes), menos de 2 semanas incluindo preparação |
| Código Lean escrito | 13 milhões de linhas — cerca de 5x o tamanho da própria Mathlib |
| Teoremas intermediários provados | 30.300 (29.500 usados na prova final) |
| Tokens de saída consumidos | ~6 bilhões |
| Contribuição matemática humana | Só priorização de alto nível, nenhum passo de prova |
O número de 13 milhões de linhas é menos impressionante do que parece: a própria Anthropic nota que a prova provavelmente é bem mais longa do que precisaria ser, em parte porque a Mathlib é incomumente concisa e bem revisada enquanto uma prova automatizada de primeira passagem não é otimizada pra brevidade. Um experimento separado e menor é mais revelador de pra onde as coisas estão indo: usando só três assinaturas pessoais do Claude (não um cluster de pesquisa interno), um time formalizou o Teorema dos Três Primos de Vinogradov — um resultado genuinamente difícil de teoria analítica dos números — em três dias, usando a mesma abordagem do Prove2Me.
6. Por que isso importa além da matemática
Três coisas dessa história valem pra qualquer trabalho gerado por IA que precise de confiança, não só pra matemática:
- Verificação é um gargalo que escala pior do que geração. Sistemas de IA (o Claude incluído) já produzem mais afirmações, código e resultados do que qualquer time de humanos consegue checar com cuidado. Verificação formal, checável por máquina, é uma das poucas abordagens que escala junto com a enchente em vez de contra ela — é o mesmo problema de fundo de confiar em código escrito por IA sem ler cada linha, só que num domínio onde "checar" tem um significado matematicamente preciso.
- O padrão DAG + multi-agente é a história de engenharia real aqui. O avanço não foi um modelo mais esperto sozinho numa janela de chat — foi dar a muitas instâncias de agente um mapa compartilhado e estruturado de um problema grande, e uma forma de evitar duplicar ou perder o trabalho umas das outras ao longo de uma execução de 11 dias. É o mesmo tipo de problema de coordenar múltiplos agentes de código numa base de código grande, só que num domínio onde sucesso ou fracasso é inequívoco.
- A própria Anthropic é explícita que isso não substitui matemáticos humanos — o comentário do próprio Kevin Buzzard enquadra isso como uma ferramenta que "alivia a carga dos revisores" e ajuda a checar a enchente de matemática e código gerados por IA que já chega mais rápido do que humanos conseguem revisar, não como substituto do entendimento matemático ou de exposições voltadas a pessoas.