Claude encontrou em 36 segundos o bug que 10 milhões de testes não encontraram

Autoria: Hyperautomation Labs · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Claude Found the Bug 10 Million Tests Missed (in 36 Seconds) · Canal: Hyperautomation Labs · 07:17 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Claude Code, Engenharia de software com IA

Resumo

O vídeo compara testes aleatórios com provas formais e mostra como Claude usou provas para encontrar bugs que ferramentas de teste não detectaram. Em uma demonstração, um fuzzer executou 10 milhões de testes sem encontrar um erro em uma função C, enquanto Claude Code usou CBMC para gerar um caso de falha em cerca de 36 segundos. A pesquisa da Anthropic e da Theorem também aplicou provas a bibliotecas open source e encontrou vulnerabilidades em projetos conhecidos. O método não garante que o software esteja livre de bugs: suas conclusões dependem de hipóteses sobre o hardware, o ambiente e a validade do proof checker.

Pontos-chave

Testes aleatórios exploram apenas alguns casos; uma prova formal verifica se uma propriedade vale para todos os casos definidos.
Provar a correção de software costuma exigir muito mais trabalho do que escrever o código, o que historicamente limitou o uso de provas formais.
Claude provou propriedades de 239 pontos de entrada em 123 bibliotecas open source.
Um proof checker independente verifica cada linha da prova e rejeita provas incompletas.
O processo revelou bugs que ferramentas de teste não encontraram, incluindo vulnerabilidades em bibliotecas e leitores de PDF.
Na demonstração, 10 milhões de entradas aleatórias não encontraram um bug que CBMC expôs em cerca de 36 segundos.
A verificação formal não significa ausência total de bugs: as provas valem sob hipóteses específicas sobre o chip, o ambiente e a propriedade verificada.
O custo em tokens ainda pode ser alto, mas o vídeo relata reduções no uso de tokens em testes com Claude Opus 5.5 e com agentes que reutilizaram provas.

Capítulos

Início	Capítulo	Resumo
00:00	Testes aleatórios e provas formais	O vídeo apresenta um teste que encontra algumas falhas e compara essa abordagem com provar uma propriedade para todos os caminhos considerados.
01:03	O custo de provar software	O exemplo do SEL4 ilustra por que provas formais foram caras e raras, antes de Claude aplicá-las a bibliotecas open source.
02:35	Bugs que os testes não encontraram	As provas revelam falhas em bibliotecas e um leitor de PDF, e uma demonstração mostra CBMC encontrando um bug ignorado por 10 milhões de testes.
04:41	Outros resultados e custo em tokens	O vídeo descreve modelos de chips e um interpretador Python verificados, além de discutir o custo das provas e a reutilização entre agentes.
06:15	Limites e perspectivas	O apresentador explica as hipóteses e os componentes ainda confiáveis, e discute a possível adoção de provas formais por desenvolvedores.

Citações

Ele não testou. Ele provou. — 00:00

Você só sabe sobre os cômodos em que entrou. — 01:03

10 milhões de uploads aleatórios, zero falhas. — 03:38

Verificado formalmente não significa livre de bugs. — 05:44

Conceitos e entidades

Claude (modelo): Modelo de IA usado para produzir provas formais e encontrar bugs no código.
Claude Code (ferramenta): Ferramenta solicitada pelo apresentador para provar a propriedade de uma função C.
Anthropic (empresa): Empresa que publicou a pesquisa sobre o uso de Claude para provar propriedades de software.
Theorem (empresa): Empresa que colaborou com a Anthropic na pesquisa e oferece o processo para outros projetos open source.
CBMC (ferramenta): Ferramenta gratuita usada na demonstração para verificar o código e apresentar uma entrada que o faz falhar.
SEL4 (repo): Kernel de sistema operacional citado como exemplo de software cuja prova de correção exigiu muito mais trabalho do que sua implementação.
Linux kernel (repo): Kernel citado no vídeo como software amplamente usado que teve mais de mil vulnerabilidades divulgadas recentemente.
libexpat (repo): Biblioteca de leitura de XML na qual Claude redescobriu uma vulnerabilidade de segurança conhecida.
Opus 5.5 (modelo): Modelo que, em 36 tarefas de teste mencionadas no vídeo, provou metade delas usando cerca de 40% menos tokens que Opus 5.
Prova formal (conceito): Demonstração verificável de que uma propriedade especificada do programa vale sob determinadas hipóteses.
Fuzzing (conceito): Técnica de teste que envia entradas variadas, muitas vezes aleatórias, a um programa para tentar provocar falhas.
Proof checker (conceito): Programa independente que confere cada linha de uma prova e aceita ou rejeita seu resultado.

Tradução completa (pt-BR)

00:00 Os aplicativos do seu celular rodam com código que foi testado bilhões de vezes. Mesmo assim, ainda há bugs que ninguém encontrou. Veja só. Uma máquina de testes envia entradas aleatórias para um programa. Um bilhão e meio de tentativas. Foram encontradas quatro falhas, e ninguém sabe o que há no restante do labirinto. Agora veja o que Claude fez com exatamente o mesmo labirinto. Ele não testou. Ele provou. Todos os caminhos a partir daquela porta foram verificados e aprovados. A Anthropic publicou esta pesquisa em

00:31 22 de outubro, junto com uma empresa chamada Theorem. E a primeira frase é direta: a maioria dos softwares está repleta de bugs que a IA agora consegue encontrar e explorar com facilidade. O kernel do Linux roda em bilhões de dispositivos e, recentemente, mais de mil vulnerabilidades foram divulgadas. Então, encontrar bugs já não é a parte difícil. O difícil é provar que não restou nenhum. Aqui está a diferença, em palavras simples. Testar é como verificar se há vazamentos de gás num prédio entrando em cômodos aleatórios. Se você andar por tempo suficiente, vai encontrar alguns

01:03 vazamentos, mas nunca poderá dizer que o prédio é seguro. Você só sabe sobre os cômodos em que entrou. Uma prova é diferente. É como ter a planta de cada cano e uma garantia de que nenhum deles vaza. As pessoas sabem como fazer isso há décadas. Quase ninguém faz porque é brutalmente caro. Quanto custa? Aqui está o exemplo famoso. Um kernel de sistema operacional chamado SEL4. Foram necessários dois anos de trabalho de uma pessoa para construí-lo e

01:33 20 anos de trabalho de uma pessoa para provar que estava correto. Dez vezes mais trabalho para provar o código do que para escrevê-lo. Por isso, as provas só eram usadas quando um bug podia custar vidas, como no software que pilota aviões da Airbus. Então, a Anthropic tentou algo novo. Eles [fungada] pegaram bibliotecas open source, os blocos de construção escondidos em navegadores, visualizadores de imagens e servidores. E pegaram os testes que os desenvolvedores já tinham escrito. Cada teste virou uma promessa. Para toda entrada com menos de 64 megabytes, este programa nunca

02:05 falha. O trabalho de Claude era provar essa promessa. Ao longo de algumas semanas, Claude provou isso para 239 pontos de entrada em 123 bibliotecas. Isso dá cerca de 180 milhões de linhas de prova. Uma prova típica tem cerca de 600 mil linhas. Ninguém lê isso. E aqui está a parte inteligente: não é preciso. Um programa separado, chamado verificador de provas, verifica cada linha. Aqui, ele rejeita

02:35 a prova de Claude porque ainda há um caso em aberto. Claude o corrige. O verificador aceita. Agora, está provado que esse programa, compilado para esse tipo de chip, não falha. Aqui está a parte de que mais gosto. Para concluir uma prova, Claude precisa lidar com cada bug em seu caminho. Então, encontrou bugs que as máquinas de teste não detectaram durante anos. Um deles só acontecia com um arquivo de cerca de 20 megabytes, com uma disposição rara. Mas as ferramentas de teste geralmente param em torno de 1 megabyte.

03:06 Elas nunca chegariam lá. Outro exigia uma imagem de 64 megabytes e 2 gigabytes de memória. Claude também redescobriu uma falha de segurança conhecida na libexpat, uma biblioteca usada para ler XML. E, quando a equipe testou isso em um leitor de PDF muito usado, encontrou em uma semana tantos bugs de segurança quanto costumam ser relatados em um ano inteiro. Então, experimentei uma versão minúscula disso. Escrevi uma pequena função em C que divide um upload em blocos de 1 megabyte,

03:38 e inseri um bug nela. Um que só aparece em uploads grandes, como os do artigo. Depois, executei um fuzzer limitado a 1 megabyte, como os de verdade. Dez milhões de uploads aleatórios, nenhuma falha. Pelos padrões dos testes, esse código parece perfeito. Então, pedi ao Claude code que parasse de testar e, em vez disso, provasse a correção com uma ferramenta gratuita chamada CBMC. Levou cerca de 36 segundos. A prova falhou, e o CBMC retornou o upload exato que causa o problema, com cerca de 63

04:09 megabytes. Qualquer upload com mais de 16 megabytes escreve além dos limites de um array de 16 posições. Meu fuzzer nunca enviou nada tão grande. Então, não tinha a menor chance de encontrar o bug. Claude adicionou uma linha e provou a versão corrigida. Verificação bem-sucedida. Todos os tamanhos de 0 a 64 megabytes, com qualquer conteúdo — não uma amostra. Todos eles. Também apontou a contrapartida: agora, uploads grandes só têm seus primeiros 16 blocos indexados. Essa é a ideia toda em um minuto.

04:41 Eles não pararam nas falhas. Claude escreveu seu próprio modelo de como os chips da Intel e da AMD executam instruções, bom o suficiente para inicializar o Ubuntu. E, durante esse trabalho, encontrou centenas de erros na documentação oficial de referência. Também criou um interpretador de Python em Rust e provou que ele segue as regras do Python. Em 1,7 milhão de programas aleatórios, ele correspondeu ao Python real em 99,95% das vezes. Então, qual é o porém?

05:11 O custo. Algumas dessas provas usam centenas de milhões de tokens, mas isso está caindo rapidamente. Em 36 tarefas de teste, Claude Opus 5.5 provou metade delas usando cerca de 40% menos tokens do que Opus 5. E, quando os agents Claude puderam copiar as provas concluídas uns dos outros, usaram 17% menos tokens. As provas são reutilizadas da mesma forma que o código. Agora, a Anthropic é cautelosa quanto a isso, e nós também devemos ser. Verificação formal não

05:44 significa ausência de bugs. Essas provas pressupõem um chip RISC-V, uma thread e uma configuração específica. A maioria das pessoas executa esse código em Intel ou ARM. Também havia o risco de trapaça. Claude poderia fazer qualquer prova passar simplesmente reescrevendo o programa para que ele nunca fizesse nada. Por isso, a equipe penalizou cada mudança de código feita por Claude e auditou essas mudanças. O que você obtém não é perfeição. É uma lista muito menor de coisas nas quais você precisa confiar: o chip e o modelo do Linux.

06:15 A promessa exata que foi provada. E o próprio verificador de provas. Então, o que isso significa para você? A previsão da Anthropic é que as provas em breve serão tão comuns quanto os testes são hoje. A Theorem já está se oferecendo para executar esse processo em outros projetos open source. E publicou uma skill do Claude para que os desenvolvedores possam experimentar com o próprio código. Se isso acontecer, o software que você usa todos os dias deixará de vir acompanhado da promessa de que foi testado e passará a vir acompanhado de uma prova. Então, aqui vai minha pergunta: você confiaria mais

06:46 no código se uma IA o provasse, ou menos? Conte nos comentários. Eu leio todos. Falando sério: 90% de vocês que estão assistindo ainda não se inscreveram. No YouTube, clique em “Participar” e torne-se membro. Ou simplesmente inscreva-se. É grátis e diz ao algoritmo para mostrar mais conteúdo para você. No Facebook, o botão de inscrição é o botão de apoio. É isso que mantém as luzes acesas por aqui. Inscreva-se para nos apoiar. Se quiser um resumo de uma página com os

07:17 números principais, as três coisas nas quais você ainda precisa confiar e todos os links, comente “labirinto” que eu envio para você. Se quiser os guias completos, meus guias pagos estão nos links abaixo. Acompanhe no Instagram e no Facebook para ver conteúdo de IA em pequenas doses. As análises aprofundadas ficam aqui no YouTube. Até a próxima.

Transcrição original

[00:00] The apps on your phone run on code that’s been tested billions of times. It still has bugs nobody has found. Watch this. A testing machine is throwing random inputs at a program. One and a half billion tries. Four crashes found and the rest of the maze, nobody knows. Now watch what Claude did with the exact same maze. It didn’t test it. It proved it. Every path from that door checked and green. Anthropic published this research on

[00:31] October 22nd together with a company called Theorem. And the first line is blunt. Most software is riddled with bugs which AI can now easily find and exploit. The Linux kernel runs on billions of devices and it recently had more than a thousand vulnerabilities disclosed. So finding bugs isn’t the hard part anymore. Proving there are none left is. Here’s the difference in plain words. Testing is like checking a building for gas leaks by walking into random rooms. Walk long enough and you’ll find some

[01:03] leaks, but you can never say the building is safe. You only know about the rooms you walked into. A proof is different. It’s like having the plan of every single pipe and a guarantee that none of them leak. People have known how to do this for decades. Almost nobody does it because it is brutally expensive. How expensive? Here’s the famous example. An operating system kernel called SEL4. It took two person years to build it and

[01:33] 20 person years to prove it correct. 10 times more work to prove the code than to write it. That’s why proofs were only used where a bug could cost lives, like the software that flies Airbus planes. So Anthropic tried something new. They [snorts] took open source libraries, the building blocks hiding inside browsers, image viewers, and servers. And they took the tests the developers had already written. Each test became a promise. For every input under 64 megabytes, this program never

[02:05] crashes. Claude’s job was to prove that promise. Over a few weeks, Claude proved it for 239 entry points across 123 libraries. That’s about 180 million lines of proof. A typical proof is around 600,000 lines. Nobody reads that. And here’s the clever part. You don’t have to. A separate program, called a proof checker, checks every single line. Here, it rejects

[02:35] Claude’s proof because one case is still open. Claude fixes it. The checker accepts. Now that program, compiled for this kind of chip, is proven not to crash. Here’s the part I like most. To finish a proof, Claude has to deal with every bug in its way. So, it found bugs the testing machines had missed for years. One only happened on a file of about 20 megabytes with one rare layout. But testing tools usually stop at around 1 megabyte.

[03:06] They’d never get there. Another needed a 64 megabyte image and 2 gigabytes of memory. It also rediscovered a known security hole in libexpat, a library used to read XML. And when the team tried this on a widely used PDF reader, they found as many security bugs in 1 week as usually get reported in a whole year. So, I tried a tiny version of this myself. I wrote a small C function that splits an upload into 1 megabyte blocks,

[03:38] and I planted a bug in it. One that only shows up on big uploads, like the ones in the article. Then I ran a fuzzer capped at 1 megabyte, like the real ones. 10 million random uploads, zero crashes. By testing standards, this code looks perfect. So, I asked Claude code to stop testing and prove it instead with a free tool called CBMC. It took about 36 seconds. The proof failed and CBMC handed back the exact upload that breaks it, about 63

[04:09] megabytes. Any upload over 16 megabytes writes past the end of a 16-slot array. My fuzzer never sent anything that big. So, it never stood a chance. Claude added one line and proved the fixed version. Verification successful. Every size from 0 to 64 megabytes with any contents, not a sample. All of them. It even flagged the trade-off. Big uploads now only get their first 16 blocks indexed. That’s the whole idea in 1 minute.

[04:41] They didn’t stop at crashes. Claude wrote its own model of how Intel and AMD chips run instructions, good enough to boot Ubuntu. And while doing it, it found hundreds of mistakes in the official reference documentation. It also built a Python interpreter in Rust and proved it follows Python’s rules. On 1.7 million random programs, it matched real Python 99.95% of the time. So, what’s the catch?

[05:11] Cost. Some of these proofs take hundreds of millions of tokens, but that’s dropping fast. On 36 test tasks, Claude Opus 5.5 proved half of them using about 40% fewer tokens than Opus 5. And when Claude agents were allowed to copy each other’s finished proofs, they used 17% fewer tokens. Proofs get reused the same way code does. Now, Anthropic is careful here and so should we be. Formally verified does not

[05:44] mean bug-free. These proofs assume a RISC-V chip, one thread, and a particular setup. Most people run this code on Intel or ARM. There was also a cheating risk. Claude could make any proof pass just by rewriting the program into one that never does anything. So, the team penalized every code change Claude made and audited them. What you get isn’t perfection. It’s a much shorter list of things you have to trust. The chip and Linux model.

[06:15] The exact promise that was proved. And the proof checker itself. So, what does this mean for you? Anthropic’s prediction is that proofs will soon be as normal as testing is today. Theorem is already offering to run this pipeline on other open source projects. And they published a Claude skill so developers can try it on their own code. If that happens, the software you use every day stops coming with a promise that it was tested and starts coming with a proof. So, here’s my question. Would you trust

[06:46] code more if an AI proved it or less? Tell me in the comments. I read everyone. Real talk. 90% of you watching haven’t subscribed. On YouTube, hit join and become a member. Or just subscribe. It’s free and it tells the algorithm to send you more. On Facebook, subscribe is the supporter button. That’s what keeps the lights on here. Subscribe to support us. If you want a one-page summary with the

[07:17] key numbers, the three things you still have to trust, and every link, comment maze, and I’ll send it to you. If you want the full playbooks, my paid guides are linked below. Follow along on Instagram and Facebook for bite-size AI. The deep dives live here on YouTube. See you in the next one.