AlphaProof Code vs AesCode 32B: Um prova que o código está correto, o outro o desenha

Coloque AlphaProof Code e AesCode 32B na mesma frase e a única coisa que eles compartilham é a palavra "code". AlphaProof Code é um framework agêntico do Google DeepMind anunciado em 10 de novembro de 2026 que produziu cerca de 6,5 milhões de linhas de Lean verificado por máquina, provando que o binário compilado do libsignal se comporta conforme especificado. AesCode 32B é um checkpoint de visão-linguagem de 33 bilhões de parâmetros que a Microsoft enviou ao Hugging Face no início de outubro de 2026 sem nenhum anúncio, e ele escreve um prompt em um único documento HTML autocontido — um slide, um pôster, um painel — que uma pessoa então observa. Nenhum dos dois é um serviço que você possa chamar. Um deles nem sequer é um modelo. Se você chegou aqui procurando uma decisão de substituição direta, a resposta honesta é que essa decisão não existe, e o restante deste texto explica por que a comparação ainda vale a pena.

O erro de categoria, formulado corretamente

AesCode 32B é um gerador. Você fornece uma descrição; ele retorna um artefato cuja qualidade é avaliada esteticamente e pela coincidência de os números na página serem os números que você pediu. A formulação do próprio cartão do modelo é que geradores de imagem compõem uma página elegante e renderizam mal os números nela, enquanto modelos de código acertam os números e não conseguem ver como a página se parece — AesCode combina seu prompt com uma imagem gerada a partir desse mesmo prompt e usa a imagem como referência estética, seguindo o texto para o conteúdo.

O AlphaProof Code é um verificador. Você fornece a ele uma especificação — uma declaração do que deve ser verdadeiro — e ele retorna uma prova, verificada pelo kernel do Lean, de que um binário compilado específico satisfaz essa especificação. Não há nenhum julgamento estético em nenhum ponto do processo. Uma prova ou é aceita, ou não é, e o critério de aceitação são algumas milhares de linhas de código de kernel, e não o gosto de um revisor.

Essa distinção decide para que serve cada um. O AesCode 32B responde a “faça uma coisa para mim”. O AlphaProof Code responde a “esta coisa é o que afirma ser?”. Você usaria o primeiro numa tarde de terça-feira para montar um deck, e o segundo, se fosse a Signal, ao longo de quatro semanas com cinco pesquisadores e equipes de 40 a 80 agentes.

O que cada um realmente oferece

• Parâmetros — AesCode 32B: cerca de 33,4 bilhões em BF16 distribuídos por quatorze fragmentos safetensors, totalizando 66.714.912.704 bytes. AlphaProof Code: nenhum. Trata-se de um framework mais um repositório de artefatos, e não há pesos para baixar.

• Base — AesCode 32B: um ajuste fino do Qwen3-VL-32B-Instruct, com arquitetura declarada como Qwen3VLForConditionalGeneration, portanto carrega com transformers 4.57 e versões posteriores. AlphaProof Code: agnóstico ao modelo por construção; o artigo do DeepMind nomeia Gemini 4 Carbon para os agentes de prova e diz que Claude Opus 5.5 foi usado entre os modelos que redigem e revisam especificações.

• Licença — AesCode 32B: Apache 2.0, no Hugging Face hoje. AlphaProof Code: o desenvolvimento em Lean, a semântica AArch64 e o binding do libsignal estão publicados em github.com/google-deepmind/code-verification, e a landing page não indica nenhuma licença, o que você deve resolver antes de desenvolver qualquer coisa com base nela.

• Disponibilidade — AesCode 32B: apenas auto-hospedado. Cerca de 65 GB de memória de acelerador para os pesos, um comando vLLM em quatro ranks de paralelismo de tensor, nenhum endpoint hospedado e nenhum mapeamento de provedor de inferência por trás da página do repositório. AlphaProof Code: artefato de pesquisa, sem endpoint, sem lista de espera, sem preços.

• Saída — AesCode 32B: um documento HTML, verificável ao abri-lo. AlphaProof Code: um termo de prova Lean, verificável pelo Lean.

• O que "correto" significa — AesCode 32B: a página parece correta e os valores correspondem ao prompt, julgados por uma pessoa. AlphaProof Code: o teorema vale para todas as entradas no modelo, julgado por um kernel.

A única sobreposição genuinamente interessante: ambas as saídas são artefatos

Aqui está a comparação que vale a pena. Ambos os sistemas produzem um arquivo que sobrevive ao modelo que o criou. O HTML do AesCode 32B é um documento finalizado; você pode distribuí-lo, editá-lo, fazer diff dele, e ninguém precisa do modelo de novo. A prova em Lean do AlphaProof Code é uma derivação finalizada; você pode verificá-la novamente em um laptop em alguns minutos de processamento e, se a especificação não mudou, o resultado continua válido daqui a cinco anos.

Isso é uma propriedade mais rara do que parece num mercado cheio de endpoints de chat. A maior parte da saída dos modelos é texto descartável cujo valor depende de o modelo continuar disponível. Ambos produzem algo que você pode guardar. A diferença é o que "guardar" lhe proporciona: com AesCode você guarda um deck, com AlphaProof Code você guarda uma garantia.

Onde a analogia falha é na auditabilidade. Qualquer pessoa pode abrir o HTML e ver se o título está errado. Quase ninguém consegue abrir 6,5 milhões de linhas de Lean e ver se o teorema diz o que o comunicado à imprensa diz que ele diz — razão pela qual o artigo do DeepMind passa páginas enumerando sua base confiável, suas 37 primitivas contratadas e as propriedades que ele não prova. O artefato é verificável; sua leitura não é gratuita.

Quanto valem os números de cada lado

O principal destaque do AesCode 32B é uma pontuação geral de 85,89 contra o GPT-5.5 com 81,28 — a medição da Microsoft de um modelo concorrente, segundo uma rubrica escrita pela Microsoft, em um harness construído pela Microsoft. Boundary fica em 97,27, com overflow severo em 4,3% das amostras, e estilo em 55,99, uma linha em que nenhum modelo da tabela ultrapassa 60. Pelos próprios contadores do repositório, ninguém fora da Microsoft havia publicado um número para o modelo. Todos os números acima são informados pelo fornecedor e não foram reproduzidos.

O AlphaProof Code não tem nenhuma tabela de benchmark, e isso não é uma lacuna no relatório — é um tipo diferente de afirmação. O resultado é que um binário específico satisfaz dez teoremas simbólicos e uma trilha computacional com um limite concreto. Você pode discordar da especificação, mas não pode discutir o veredito do kernel sobre a prova. As ressalvas comparáveis são estruturais e não estatísticas: nenhuma garantia pós-quântica para a cura do SPQR, nenhuma privacidade de payload, nenhuma autenticação do respondedor em primeiras mensagens não promovidas, uma sessão por promoção, comprimentos de mensagem fixos, nenhum estado multi-dispositivo. E um limite de falsificação de MAC que se torna vazio por volta de 25.000 mensagens em uma única sessão.

Há um número que se transfere de forma útil. A verificação do AlphaProof Code levou quatro semanas, enquanto trabalhos comparáveis têm historicamente levado anos para equipes especialistas, frente às próprias linhas de base citadas no artigo, de aproximadamente 20 pessoas-ano para o seL4 e cerca de 6 para o CompCert. É essa proporção que vale reter, e é uma afirmação sobre fluxo de trabalho, não sobre a qualidade do modelo.

Qual deles você consegue realmente executar esta semana

AesCode 32B: sim, se você tiver o hardware. Baixe os fragmentos, sirva com vLLM em quatro ranks, mantenha os prompts abaixo do limite de 24.576 tokens da placa e aceite que sua etapa de revisão é uma pessoa apertando os olhos para o HTML renderizado. Ele não dirá se a página está correta; dirá se a página parece correta.

AlphaProof Code: não. Os artefatos publicados são um desenvolvimento em Lean, não um pipeline que você invoca. Nem mesmo os modelos dentro dele são o entregável — o framework é um constructo de pesquisa, e a própria formulação do DeepMind é que escalá-lo "requer pesquisa contínua". O CodeMender é o projeto irmão para reparo automatizado; verificação e remediação são dois produtos diferentes no roteiro daquele laboratório.

Se o que você quer é um modelo para redigir as especificações — a etapa em que especialistas humanos traduziram as metas de segurança do Signal para Lean, revisadas uma a uma — isso é trabalho comum de modelo, e o Claude Opus 5.5 está no catálogo da OrcaRouter a US$ 4 por milhão de tokens de entrada e US$ 20 por milhão de tokens de saída com o preço de tabela do provedor repassado sem margem. Roteie um loop de redação de especificações entre dois ou três modelos e compare a saída em Lean — isso é uma chamada de DSL de roteamento, não um projeto de pesquisa. O que nada disso oferece é uma prova; a etapa de prova é de onde vieram as seis milhões de linhas.

Por que o pareamento ainda vale a pena ser publicado

Porque “code model” se tornou uma categoria sem critério mínimo. Um modelo que escreve slides e um framework que prova um protocolo de mensagens acabam ambos classificados nela, e compradores que os comparam em um ranking não aprendem nada. A pergunta útil não é qual é melhor — é qual evidência você recebe sobre a saída. O AesCode 32B entrega uma página renderizada e uma rubrica do fornecedor. O AlphaProof Code entrega uma derivação verificada por kernel e uma lista excepcionalmente explícita do que ele assume. Um desses é aplicável a código que você preferiria não errar, e não é o que tem a maior contagem de parâmetros.

Se você estiver avaliando o AesCode 32B para um pipeline de design, o que deve ser testado não é a pontuação geral, mas o comportamento de fronteira — a taxa de 4,3% de transbordamento severo é onde um deck silenciosamente se torna errado em vez de feio. Se você estiver avaliando o AlphaProof Code, o que deve ser lido é o catálogo de desvios de especificação no repositório de artefatos: mais de 200 entradas computacionais e cerca de 35 simbólicas, quinze das quais são lacunas ou bugs na análise do Double Ratchet. Esse catálogo é o documento mais honesto do lançamento, porque é uma lista de tudo o que as provas não fecharam.