A Anthropic afirma que Claude gerou provas matemáticas, verificadas por computador, para 239 pontos de entrada de testes em 123 bibliotecas de código aberto. O trabalho foi feito em parceria com a Theorem, empresa especializada em métodos formais. A conclusão é específica: os programas analisados não apresentariam certos tipos de falha nas condições descritas — isso não significa que as bibliotecas sejam, em qualquer uso, totalmente livres de bugs.
9
5
A escala chamou atenção: a equipe diz que concluiu o trabalho em algumas semanas e produziu cerca de 180 milhões de linhas de provas em Rocq, uma ferramenta para escrever e verificar demonstrações formais. A proposta é tornar esse tipo de verificação mais viável em software real, sem ampliar as conclusões para além do que foi especificado e comprovado.
3
13
O que foi demonstrado
A Anthropic diz que as provas mostram que os programas cobertos terminam normalmente, sem erros de segurança de memória ou falhas em asserções, para todas as entradas menores que 64 MB e considerando respostas e configurações de memória do Linux representadas nos modelos utilizados — além de outras premissas do trabalho. Os alvos eram binários compilados para RISC-V; portanto, não se trata de uma garantia abstrata para todas as versões ou formas de uso de cada biblioteca.
9
12
Para montar as especificações, a equipe reaproveitou pontos de entrada dos testes do Google OSS-Fuzz, projeto que usa fuzzing para testar software com muitas entradas. Em vez de apenas tentar encontrar falhas executando diferentes casos, Claude gerou provas sobre o comportamento dos binários especificados em todo o conjunto de entradas abrangido pelo teorema.
3
13
A Anthropic descreve o projeto como uma primeira tentativa em grande escala de usar IA para verificar formalmente software de produção no nível de assembly. Essa é a caracterização da equipe sobre a novidade do trabalho, não um consenso histórico estabelecido de forma independente.
7
13
O papel do verificador Rocq
Claude gerou as provas, e o núcleo de verificação do Rocq checou se elas estavam corretas dentro do sistema formal. Assim, não é necessário confiar apenas no raciocínio do modelo nem pedir a desenvolvedores que revisem manualmente cada linha para que a prova seja verificada mecanicamente. Ainda há premissas importantes: o teorema precisa expressar a propriedade que realmente interessa, e os modelos formais e o verificador fazem parte da base em que o resultado se apoia.
9
5
Segundo os relatos, o conjunto soma cerca de 180 milhões de linhas de provas em Rocq — uma média aproximada de 600 mil linhas por binário. Esse volume mostra a escala do esforço, mas a quantidade de linhas, por si só, não indica quão abrangente é uma propriedade nem se ela corresponde às necessidades de uso de cada projeto.
3
12
O que os testes podem deixar passar
O fuzzing testa muitas entradas, mas não prova, sozinho, o comportamento para todas as entradas possíveis em um domínio definido. Relatos sobre o projeto dizem que Claude encontrou e corrigiu centenas de bugs, incluindo falhas que teriam resistido a trilhões de execuções de fuzzing. Esses números são atribuídos ao trabalho e não constituem uma medição independente de quanto a verificação formal será mais eficaz que os testes em outros projetos.
2
11
A conclusão prática não é abandonar os testes. É reconhecer que provas formais podem oferecer outro tipo de evidência: dentro do escopo e das premissas declarados, elas podem estabelecer o comportamento para todas as entradas abrangidas pelo teorema, e não apenas para os casos efetivamente executados durante testes.
9
2
Por que “verificado” não quer dizer “sem bugs”
As garantias dizem respeito a pontos de entrada selecionados e a binários específicos. Elas não cobrem automaticamente todas as funções de uma biblioteca, configurações de compilação, arquiteturas ou formas de uso.
9
5
As condições de execução também importam. Os relatos descrevem provas para binários estáticos e de execução em uma única thread, compilados para RISC-V e executados em um ambiente Linux modelado, com limite de memória definido. Como a maioria dos usuários utiliza programas compilados para outras arquiteturas ou configurações, o resultado não deve ser interpretado como garantia sobre esses usos.
12
27
34
Além disso, uma prova demonstra o teorema que foi escrito — não todas as propriedades que um desenvolvedor poderia desejar. Bugs podem estar fora do escopo, e a conclusão também depende dos modelos formais e dos fundamentos usados para verificar as provas.
5
31
O que desenvolvedores podem aproveitar
A principal contribuição do projeto é mostrar que a assistência de IA pode tornar a verificação formal de código assembly viável em uma escala maior de software real do que seria possível sem um esforço especializado considerável. Isso não estabelece um custo universal nem garante que o método funcione em qualquer base de código.
7
13
Uma parte das provas foi disponibilizada publicamente. Um relato descreve esse recorte como abrangendo 25 bibliotecas e 60 pontos de entrada, não o conjunto completo do projeto. A Theorem também anunciou o OSS Verify, um programa voltado a mantenedores de software de código aberto.
32
16
38
Para quem desenvolve ou mantém software, o passo útil é tratar cada prova como uma garantia delimitada: conferir o ponto de entrada, o binário, as premissas e a propriedade demonstrada antes de se apoiar no resultado. O trabalho torna a verificação formal assistida por modelos de linguagem uma opção a avaliar junto com os testes — não um motivo para parar de testar ou presumir que o software está livre de falhas.
9
5