Adam Langley Diz Que a Automação de Provas em Lean Já Chegou. A Parte Difícil Apenas Mudou de Lugar

Adam Langley afirma que a automação de provas em Lean ultrapassou um limiar prático depois que diversos modelos de linguagem de grande porte concluíram uma prova de software difícil em cerca de 20 minutos. A afirmação vem com uma ressalva importante. A IA gerou a prova, mas o Lean verificou cada etapa em relação a uma especificação formal.

Essa distinção separa este experimento de mais uma história sobre IA produzindo código plausível. Langley construiu um descompressor Zstandard em Lean e depois pediu a modelos que provassem propriedades universais de sua tabela de decodificação de entropia. Os modelos teriam concluído sem lacunas de prova não resolvidas, embora também tenham alterado partes de sua implementação.

O experimento aponta para um acordo diferente para equipes de software. Desenvolvedores podem passar menos tempo construindo provas e mais tempo decidindo exatamente o que seus sistemas precisam garantir. Assistentes de programação com IA geram uma resposta e pedem que humanos encontrem erros. O Lean inverte essa relação ao rejeitar qualquer resposta que não satisfaça uma declaração verificável por máquina.

Isso não prova que a verificação formal se tornou barata, fácil ou adequada para todas as aplicações. Langley descreveu o descompressor como um brinquedo, não divulgou seu código-fonte e mediu seu desempenho em um décimo da velocidade do comando zstd padrão. Pesquisas independentes também mostram que provadores de IA enfrentam dificuldades quando as provas dependem de repositórios grandes e desconhecidos.

A conclusão mais defensável ainda é significativa. A IA já consegue absorver trabalho repetitivo de provas o suficiente para tornar a verificação digna de testes fora de seus nichos tradicionais. Para trabalhadores do conhecimento, a lição mais ampla vai além do software: a automação se torna mais confiável quando os critérios de aceitação são explícitos e verificados de forma independente.

Um Experimento com Zstandard Colocou a Automação de Provas em Lean para Trabalhar

A notícia não é que uma IA escreveu mais um programa. É que um trabalho gerado por IA passou por um verificador criado para rejeitar erros lógicos.

Langley, engenheiro de segurança conhecido por seu trabalho em criptografia e infraestrutura da internet, publicou o experimento em 26 de julho de 2026. Seu relato sobre automação de provas descreve a construção de um descompressor Zstandard em Lean e a formalização de diversas propriedades de suas tabelas de decodificação.

Lean é tanto uma linguagem de programação funcional quanto um assistente de provas. Um assistente de provas verifica se um argumento formal estabelece uma proposição formulada com precisão. O pequeno kernel do Lean valida o termo de prova resultante, portanto os usuários não precisam confiar no modelo que o produziu.

O teste se concentrou em Entropia de Estado Finito, ou FSE, que o Zstandard usa para codificar alguns valores de forma eficiente. A FSE distribui símbolos por uma tabela de estados de acordo com suas probabilidades. Cada estado identifica um símbolo, o número de bits a ler e uma base para calcular o próximo estado.

Uma tabela correta precisa preservar diversas relações. Ela precisa ter o número esperado de entradas, a alocação correta para cada símbolo e transições válidas para todos os estados possíveis. Cada símbolo com probabilidade diferente de zero também precisa ter exatamente uma rota para cada estado de destino.

Testes unitários podem verificar exemplos selecionados da especificação Zstandard. Eles não conseguem estabelecer que essas propriedades valem para toda entrada válida. Em vez disso, Langley escreveu um teorema que abrange a função completa de construção da tabela.

Diversos LLMs teriam produzido uma prova em cerca de 20 minutos. Langley confirmou que o Lean aceitou o resultado e que os arquivos não continham declarações sorry, que desenvolvedores Lean usam como marcadores de posição para provas ausentes.

Os modelos não apenas preencheram uma lacuna isolada. Eles alteraram o código de geração da tabela porque Langley havia usado estrutura demais no estilo imperativo. Essa estrutura era mais difícil de analisar para o mecanismo de provas.

Esse detalhe importa porque revela tanto a atração quanto o custo. A IA lidou com a construção da prova, mas a implementação ainda precisava ter uma forma que favorecesse o raciocínio. A verificação não chegou como um botão final de controle de qualidade aplicado a código arbitrário.

Langley também evitou apresentar o projeto como evidência de produção. O código continua inédito, o decodificador cobriu um experimento limitado e seu desempenho ficou atrás da implementação estabelecida. Sua afirmação diz respeito à disponibilidade da automação de provas, não à prontidão deste descompressor em particular.

Um projeto relacionado oferece um ponto de referência mais amplo. O criador do Lean, Leonardo de Moura, destacou uma implementação de zlib assistida por IA que passou em testes e provou a correção de ida e volta em todos os níveis de compressão. Juntos, esses exemplos aproximam a prova com IA do código de sistemas comum.

Ainda assim, eles deixam uma lacuna entre um artefato impressionante e um processo de engenharia repetível. Fechar essa lacuna determinará se a automação de provas em Lean se tornará uma ferramenta comum de desenvolvimento ou continuará sendo uma demonstração para especialistas.

A Antiga Barreira Era o Trabalho de Prova, Não a Verificação da Prova

A verificação formal já oferecia fortes garantias. Seu problema econômico era o esforço humano necessário para formulá-las e mantê-las.

Um teste normal pergunta se o software se comportou corretamente nos exemplos executados. A verificação formal pergunta se um modelo matemático satisfaz uma propriedade declarada para toda entrada dentro desse modelo. Essa promessa maior cria uma carga de trabalho muito maior.

O microkernel seL4 continua sendo um dos exemplos históricos mais claros. Sua equipe de verificação produziu uma prova verificada por máquina conectando a implementação do kernel à sua especificação formal. O projeto mostrou que softwares de produção, em escala e de alta garantia, podiam ser verificados.

Também documentou o custo. Segundo a retrospectiva do projeto da equipe, a verificação exigiu aproximadamente dez vezes o esforço gasto no projeto e na implementação do código C. O material de prova excedeu a implementação em mais de vinte vezes o número de linhas.

Esses números não significam que todo projeto verificado herda a mesma proporção. O seL4 buscou garantias excepcionalmente amplas em um kernel substancial de sistema operacional. Eles explicam por que a maioria das organizações de software optou por testes, revisões, análise estática e monitoramento operacional.

A automação tradicional reduziu parte dessa carga. Ferramentas como solucionadores SMT, que procuram soluções para restrições lógicas, podem resolver obrigações rotineiras de prova. Elas funcionam bem quando o problema se encaixa nas teorias suportadas e na estrutura esperada pelo solucionador.

A experiência se torna menos previsível quando um objetivo fica fora dessa zona confortável. Desenvolvedores podem esperar sem saber se um solucionador precisa de mais tempo ou se jamais terminará. As equipes também aprendem padrões de implementação que fazem o solucionador funcionar, criando outra disciplina especializada de engenharia.

Os LLMs abordam a tarefa de maneira diferente. Eles podem ler definições, mensagens de erro, lemas próximos e explicações informais. Podem propor resultados intermediários, revisar táticas que falharam e reorganizar o código quando a representação atual impede o progresso.

Essa flexibilidade torna a geração de provas um alvo natural para modelos de linguagem. Não é necessário confiar no modelo como autoridade final. Ele precisa produzir um artefato que o kernel de provas aceite.

Isso se encaixa melhor do que muitas tarefas de automação de escritório. Um memorando estratégico gerado não tem um verificador completo para verdade, relevância e julgamento. Uma prova em Lean tem uma condição de aceitação restrita que o software pode avaliar de modo determinístico.

O resultado muda a divisão esperada de trabalho. Humanos especificam a propriedade, selecionam as premissas e decidem se o modelo representa a realidade. A IA procura uma prova, enquanto o Lean verifica o resultado proposto.

Isso não elimina o trabalho humano. Ele desloca o esforço para especificação, arquitetura e revisão. Essas atividades são mais difíceis de automatizar porque exigem decidir quais resultados importam.

Para trabalhadores do conhecimento, essa é a história de produtividade mais profunda. A automação mais forte não apenas produz mais material. Ela conecta o material gerado a condições explícitas que determinam se o resultado é aceitável.

Esse princípio também se aplica ao trabalho de pesquisa e operação. Uma equipe que usa uma base de conhecimento pessoal pode recuperar evidências antes de gerar uma resposta. O resultado ainda precisa de critérios que abranjam qualidade das fontes, escopo e atualidade.

O Lean torna esses critérios incomumente rigorosos. Sua lição não é que toda tarefa precisa de um provador de teoremas. É que a automação se torna mais confiável quando a organização consegue definir um contrato verificável.

A IA Muda o Custo da Prova, Não o Significado da Correção

A automação de provas em Lean pode verificar que o código atende a uma especificação, mas não pode decidir se a especificação captura o problema certo.

Essa é a inversão central no experimento de Langley. O raciocínio incerto dos modelos não compromete automaticamente a prova porque o Lean verifica sua saída final. Ainda assim, o mesmo verificador não consegue salvar um teorema que formaliza o requisito errado.

Suponha que um teorema sobre um descompressor prove que toda transição de estado gerada permanece dentro da tabela. Isso é valioso, mas não estabelece compatibilidade com todos os arquivos Zstandard. Também não diz nada sobre comportamento de negação de serviço, limites de memória, canais laterais ou desempenho da implementação.

Cada garantia adicional precisa de uma declaração correspondente e de uma conexão com o programa real. Se essa conexão omitir uma premissa, o Lean pode provar a declaração formal enquanto o sistema implantado continua vulnerável.

A questão se assemelha a um contrato bem redigido que rege a transação errada. Uma consistência interna perfeita não consegue reparar uma obrigação ausente. A verificação aumenta a confiança dentro do limite que as pessoas definiram.

O teorema FSE de Langley ilustra o melhor caso. As propriedades correspondem diretamente às premissas necessárias para o loop de decodificação otimizado. Tamanho da tabela, alocação de símbolos, transições válidas e alcançabilidade única são invariantes concretos, e não afirmações amplas sobre qualidade.

Quando esses invariantes existem, o compilador e o kernel podem impô-los em todo o programa. Uma edição futura que viole um deles deixará de passar na verificação de tipos até que a implementação ou a prova seja alterada.

Isso cria uma superfície de revisão diferente. Engenheiros não precisam examinar milhares de etapas de prova geradas com igual atenção. Eles precisam auditar o teorema, suas premissas e a conexão entre código e modelo.

É para aí que a expertise escassa se desloca. Um engenheiro sênior que antes passava dias orientando táticas poderia, em vez disso, passar esses dias refinando o contrato formal. A IA cuida de grande parte da busca mecânica, enquanto revisores humanos avaliam se o contrato merece confiança.

A abordagem também pode tornar divergências mais produtivas. Equipes de produto, segurança e engenharia costumam usar a mesma palavra, como “válido”, atribuindo-lhe definições diferentes. Uma especificação formal força essas definições a se tornarem condições visíveis.

O trabalho do conhecimento sofre do mesmo problema de invariantes ocultos. Uma análise de mercado pode precisar de fontes atuais, uma região definida e um período de relatório fixo. As equipes frequentemente deixam essas restrições em comentários, notas de reunião ou na memória de um funcionário.

A IA pode gerar um relatório polido enquanto viola silenciosamente qualquer uma delas. Um fluxo de trabalho melhor representa restrições importantes antes do início da geração. Algumas condições podem se tornar verificações automatizadas, enquanto outras permanecem como questões explícitas de revisão.

É por isso que a combinação de conhecimento importa no trabalho assistido por IA. O resultado gerado se torna mais fácil de avaliar quando permanece conectado aos registros, decisões e evidências relevantes. A verificação é menos absoluta do que o kernel do Lean, mas o princípio operacional é semelhante.

Portanto, as organizações devem resistir à interpretação mais fácil da automação de provas. O benefício não é a permissão para parar de revisar resultados de IA. É uma oportunidade de revisar em uma camada mais valiosa.

A geração de provas se torna mais barata. Definir a correção se torna mais central. Equipes que não conseguem concordar sobre requisitos não obterão garantias fortes ao adicionar Lean ou um provador de IA.

A Verificação Formal com Lean Agora Pressiona Fluxos de Trabalho Baseados Apenas em Testes

A pressão imediata recai sobre equipes que desenvolvem código sensível à segurança e ainda tratam os testes como sua maior garantia disponível.

Os testes continuam essenciais porque avaliam execuções reais, integrações, desempenho e comportamento ambiental. A verificação formal responde a uma pergunta diferente. Ela verifica se um modelo satisfaz uma propriedade em todos os casos abrangidos pela prova.

Nenhum dos métodos substitui o outro. Langley usou vetores de teste do Zstandard como testes unitários comuns enquanto provava propriedades mais amplas do gerador de tabelas. Os testes verificavam exemplos de compatibilidade, enquanto o teorema cobria invariantes estruturais universais.

A mudança é econômica. A verificação formal antes exigia trabalho especializado suficiente para que muitas equipes pudessem descartá-la antes de avaliar seus benefícios. Se a IA reduz o tempo de construção de provas, essa rejeição automática se torna mais difícil de justificar.

O software criptográfico oferece um primeiro campo de validação. Pequenos erros aritméticos podem invalidar sistemas de segurança maiores, e muitas funções importantes já possuem especificações matemáticas. O valor das garantias universais é excepcionalmente claro.

Um relatório de experiência de maio de 2026 descreveu um pipeline de verificação em Rust que traduz código criptográfico de produção para Lean. Ele combina ferramentas de extração de Rust, bibliotecas de especificação formal e provadores de IA como Aristotle e Aleph.

Os pesquisadores aplicaram o pipeline a componentes do Plonky3 e do RISC Zero. Os alvos incluíam aritmética de corpos, verificação de inclusão Merkle, avaliação de polinômios e operações FRI usadas por sistemas de conhecimento zero. Todas as provas submetidas ainda passavam pelo kernel do Lean.

O artigo também registra atritos de engenharia. As versões da cadeia de ferramentas divergiam, as ferramentas de tradução suportavam apenas partes do Rust, e lemas ausentes bloqueavam a automação. Os provadores de IA resolveram algumas obrigações, enquanto outras ainda exigiam trabalho manual.

Essa evidência sustenta uma previsão ponderada. A verificação provavelmente entrará em produção por meio de componentes restritos e de alto valor, em vez de aplicações de negócios inteiras. As equipes podem começar com analisadores sintáticos, regras de autorização, operações criptográficas e lógica de transição de estado.

Esses componentes têm três propriedades úteis. Seu comportamento muitas vezes pode ser especificado com precisão, as falhas têm custos elevados e seus limites são pequenos o bastante para que as ferramentas atuais os compreendam.

A pressão também alcançará fornecedores que vendem sistemas de programação com IA. Gerar mais código está se tornando menos distintivo. Produzir código com propriedades verificáveis de forma independente cria uma proposta mais forte.

Um agente de programação poderia eventualmente retornar três artefatos conectados: uma implementação, uma declaração formal do comportamento exigido e uma prova verificada pelo kernel. Os revisores poderiam se concentrar em saber se a declaração corresponde ao requisito do produto.

Plataformas voltadas a testes responderão em vez de desaparecer. Espere combinações mais fortes de fuzzing, testes baseados em propriedades, execução simbólica e prova. Os testes gerados continuarão encontrando incompatibilidades entre modelos formais e ambientes de implantação complexos.

Os fornecedores de verificação formal também enfrentam pressão. Sua vantagem tradicional inclui conhecimento escasso em construção de provas. A IA reduz o valor do trabalho repetitivo com táticas, enquanto aumenta a demanda por design de especificações, integração e arquitetura de garantia.

Os gestores não devem interpretar essa mudança como uma redução imediata nas contratações. A adoção inicial normalmente cria trabalho de integração antes de eliminar trabalho de manutenção. As equipes precisarão de pessoas que entendam tanto o domínio da aplicação quanto o limite da prova.

A pergunta útil, portanto, não é se Lean substitui a programação convencional. É quais suposições caras agora podem migrar de comentários e listas de verificação de revisão para contratos impostos por máquina.

O Que o Resultado do Zstandard Não Prova

Um único decodificador de demonstração não publicado não pode estabelecer que os provadores de IA atuais escalam em repositórios de produção, mudanças frequentes ou sistemas mal especificados.

Langley afirmou essas limitações diretamente. Seu decodificador rodava cerca de dez vezes mais devagar do que o comando zstd em sua máquina. Ele também alertou que tipos fortes podem ampliar mudanças porque suposições revisadas se propagam por tipos derivados.

Essa propagação pode ser um benefício. Ela expõe cada componente dependente que precisa de atenção. Também pode transformar uma pequena mudança de produto em um grande projeto de manutenção de provas.

O desempenho cria outra troca. Lean pode fazer atualizações no local quando um objeto tem uma única referência. Uma pequena alteração no código que mantém outra referência pode, portanto, prejudicar o desempenho sem mudar a correção funcional.

A automação de provas não detecta automaticamente essa regressão. O teorema deve incluir um modelo de desempenho apropriado, ou outro benchmark deve detectá-la. Correção e eficiência continuam sendo alegações de engenharia separadas.

A escala do repositório apresenta o desafio mais importante. O exemplo de Langley tinha uma implementação focada e um teorema conectado a definições próximas. Sistemas de produção distribuem significado entre pacotes, código gerado, configurações de compilação, bancos de dados e serviços externos.

O estudo VeriSoftBench de 2026 testou esse problema usando 500 obrigações de prova de 23 repositórios Lean de código aberto. Seu benchmark de repositórios preservou definições específicas de projetos e dependências entre arquivos.

Os pesquisadores descobriram que provadores treinados em tarefas de Lean voltadas à matemática tinham baixa transferência para a verificação de software centrada em repositórios. O desempenho caiu à medida que as provas dependiam de cadeias maiores e de múltiplas etapas de definições locais.

Fornecer contexto cuidadosamente selecionado melhorou os resultados em comparação com expor um repositório inteiro. Ainda assim, deixou espaço substancial para melhorias. A recuperação de contexto ajudou, mas não resolveu o problema de raciocínio.

Essa descoberta limita diretamente a interpretação mais forte da alegação de Langley. LLMs podem produzir provas de software significativas hoje. Elas ainda não conseguem lidar com toda obrigação de prova simplesmente porque um projeto usa Lean.

Também há uma lacuna de verificação em torno do experimento publicado. Os leitores podem examinar a explicação, a declaração do teorema e as ressalvas de Langley. Eles não podem reproduzir o resultado completo porque ele não publicou o decodificador nem os arquivos de prova.

Sua confirmação de que não restavam declarações sorry é uma evidência útil de primeira mão. Não é o mesmo que uma compilação independente a partir de um repositório fixado. O resultado deve ser tratado como um relatório de engenharia crível, não como um benchmark.

As equipes de segurança também devem examinar a base computacional confiável. O kernel do Lean é intencionalmente pequeno, e implementações independentes do kernel podem comparar resultados. Ainda assim, as implantações dependem de compiladores, comportamento em tempo de execução, hardware e da precisão de qualquer modelo externo.

O sistema pode provar que uma função Lean atende a uma especificação Lean. É necessário trabalho adicional para mostrar que o código nativo otimizado preserva essa semântica. Langley sugeriu assembly verificado como uma possível direção.

Esses limites não anulam o resultado. Eles o situam. A automação de provas no Lean parece útil para componentes delimitados cujas propriedades podem ser declaradas com precisão e cujas dependências cabem no contexto disponível.

Isso já é mais prático do que a antiga suposição de que a prova formal sempre exige que um especialista elabore manualmente cada etapa. Ainda está muito longe de um botão universal de “verificar” para software gerado.

Três Sinais Mostrarão se a Automação de Provas Realmente Chegou

A próxima fase depende de reprodutibilidade, manutenção em escala de repositório e adoção em fluxos de trabalho comuns de engenharia.

O primeiro sinal é uma implementação pública e reproduzível que corresponda ao padrão de Langley. Ela deve incluir código-fonte, declarações de teoremas, provas geradas, dependências fixadas e uma compilação automatizada que rejeite lacunas não resolvidas.

Um artefato publicado permitiria que equipes independentes medissem o tempo de prova, a dependência do modelo e os custos de manutenção. Também revelaria quanta intervenção humana ocorreu entre a implementação inicial e a prova aceita.

Se várias equipes reproduzirem o fluxo de trabalho em analisadores sintáticos ou bibliotecas de compressão, a conclusão de Langley se tornará mais forte. Se os resultados dependerem de prompts ocultos extensos ou reestruturação manual, a atual alegação de produtividade enfraquece.

O segundo sinal é o desempenho em repositórios que mudam. Um sistema útil deve reparar provas após refatorações normais, atualizações de dependências e requisitos alterados. Resolver um teorema uma vez é menos valioso do que mantê-lo resolvido ao longo das versões.

Portanto, benchmarks em escala de repositório devem adicionar tarefas longitudinais. Um provador de IA poderia receber commits consecutivos e reparar as provas afetadas enquanto preserva a especificação original. As equipes devem acompanhar reparos aceitos, tempo decorrido, uso de computação e edições humanas.

A melhoria em dependências locais densas enfrentaria a fraqueza identificada pelo VeriSoftBench. Falhas contínuas confinariam a prova por IA a módulos pequenos com contexto cuidadosamente selecionado.

O terceiro sinal é a integração em agentes de programação convencionais e sistemas de integração contínua. A automação de provas se torna operacional quando uma pull request pode declarar um invariante exigido, gerar uma prova e fazer com que o Lean a verifique automaticamente.

Esse processo também precisa de modos de falha transparentes. Um modelo que não consegue encontrar uma prova deve distinguir entre contexto ausente, um teorema difícil, código incompatível e uma declaração falsa. Caso contrário, as equipes recebem mais uma compilação com falha opaca.

A adoção provavelmente começará onde as organizações já escrevem requisitos precisos. Criptografia, implementações de protocolos, compiladores, controles financeiros e sistemas de controle de acesso se enquadram nessa descrição. O software empresarial mais amplo avançará mais lentamente.

Os trabalhadores do conhecimento devem observar o mesmo padrão em suas próprias ferramentas. A automação confiável precisa de entradas explícitas, regras de aceitação, evidências rastreáveis e um verificador com autoridade para rejeitar o resultado.

A maioria das tarefas de escritório não pode alcançar certeza matemática. Ainda assim, elas podem adotar barreiras mais restritas. Um resumo de pesquisa pode exigir fontes datadas. Uma análise de vendas pode exigir que cada alegação sobre uma conta seja mapeada para um registro de cliente. Uma atualização de projeto pode sinalizar declarações não respaldadas por trabalho recente.

Essa mudança transforma a IA de um autor sem verificação em um gerador de candidatos que opera dentro de um processo controlado. As pessoas mantêm a responsabilidade de definir o limite e revisar o que as verificações não conseguem cobrir.

A automação de provas com Lean oferece a versão mais clara desse futuro porque seu verificador é exato. O modelo pode ser inconsistente, verboso ou estar errado repetidamente durante a busca. Apenas uma prova válida chega ao programa.

A pergunta para os próximos meses não é se os LLMs podem gerar alguma prova formal. Eles já podem. A pergunta é se as equipes conseguem transformar repetidamente requisitos reais em software mantido e verificado por máquina sem recriar o antigo fardo de trabalho dez vezes maior.

Escolha uma suposição onerosa no seu fluxo de trabalho e anote o que a tornaria comprovadamente verdadeira. Se a condição puder ser verificada, automatize essa verificação antes de automatizar mais resultados. Essa é a lição prática por trás do experimento de Langley e o padrão que a automação agora precisa cumprir.