Você aprova a spec, a máquina confere o código

GitHub Next e Microsoft Research anunciaram o Proof-Driven Development Kit em 21 de outubro. Está em prévia de pesquisa, só funciona em Rust, e faz um argumento que a maioria dos times com agentes de código vinha evitando: se você não consegue mais ler o diff linha por linha, pare de fingir que consegue e revise outra coisa.

Essa outra coisa é uma especificação. No fluxo do PDD Kit, um humano aprova a spec e uma máquina verifica se a implementação a cumpre para todas as entradas possíveis.

Cinco passos, e onde o humano se senta

O loop roda assim. O time planeja a funcionalidade no Chopin, a ferramenta de planejamento agêntico multiplayer do GitHub Next. Depois o PDD Kit discute o código, infere a intenção e propõe uma especificação formal escrita em Verus, uma linguagem de prova de código aberto que já existe para Rust. Um humano aprova a spec, não o código. O Verus então prova que o código gerado pelo agente satisfaz essa spec para toda entrada. Onde uma prova completa não é possível, o kit cai para testes e agentes computer-use para checagem empírica, e a saída é um pull request verificado.

A inversão é a ideia inteira. Você revisa o requisito. O verificador revisa a implementação. No Verus, uma spec anota funções com pré-condições e pós-condições que o verificador precisa descarregar, e a garantia é mais forte que uma suíte de testes verde de um jeito específico: testes amostram entradas, provas quantificam sobre todas.

A formulação do GitHub é que Chopin mais o kit permitem levar código gerado por IA à produção sem revisar linha por linha, com garantia mais forte que code review e testes sozinhos. Isso é um fornecedor descrevendo sua própria prévia de pesquisa, não um resultado auditado. Segure com leveza.

{{INLINE1}}

O custo mudou de lugar, não sumiu

É tentador ler isso como «o fardo da revisão está resolvido». Não está. Ele se moveu para a frente do pipeline, e ficou mais difícil de um jeito fácil de subestimar.

Escrever uma spec precisa o bastante para ser demonstrável é uma habilidade diferente de revisar um diff. Requisitos vagos produzem specs indemonstráveis, e o verificador vai te dizer isso falhando, o que faz as primeiras semanas de adoção parecerem as de uma ferramenta que não funciona. O que acontece de fato é que a ambiguidade nos seus requisitos aparece mais cedo que o normal, empurrada por algo que não vai cobri-la com uma função de aparência plausível.

Para times que já escrevem documentos de design que ninguém lê, isso é uma mudança real. O documento de design passa a ser estrutural, porque é o artefato que é checado.

Onde as provas param

Três limites importam mais que a lista de recursos.

Só Rust. O Verus checa Rust, e o GitHub Next diz que o kit funciona em Rust hoje, sem linguagem nova e sem mudar como o código é produzido. Se seus agentes escrevem TypeScript ou Python, não há nada para instalar ainda. Considerando quanto código de produção não é Rust, essa é uma restrição enorme numa frase pequena.

Só o que uma spec consegue expressar. Prova formal cobre propriedades que você consegue enunciar com precisão: contratos de entrada e saída, invariantes, transições de máquina de estados. Não cobre comportamento de interface, nem a maior parte da lógica com muito I/O, nem nada em que correto é um julgamento e não uma propriedade. Tudo isso desce para o caminho de fallback de testes e revisão humana, que é exatamente onde o fardo de hoje já mora.

Prévia de pesquisa, com um histórico específico. O Chopin está listado na página de projetos do GitHub Next como protótipo de pesquisa datado de setembro de 2026. O GitHub Next já lançou protótipos antes — Repo Mind, Project Copernicus, SpecLang entre eles — que nunca chegaram à disponibilidade geral. A primeira demo pública em código real está marcada para o GitHub Universe, 28 e 29 de outubro.

A honestidade mora no fallback

A decisão de design que mais diz não é o provador. É o segundo caminho explícito para código que não dá para provar, que vai para testes e agentes computer-use para checagem empírica.

É uma admissão que a maioria das ferramentas de verificação se recusa a fazer. Diz, na arquitetura, que existe código demonstrável e código que não é, e que fingir o contrário seria pior do que entregar dois pipelines. Um time que usa isso acaba com um rótulo por módulo — provado, testado, revisado —, que é um inventário de confiança mais honesto do que qualquer coisa que um relatório de cobertura produza.

O problema é que o caminho de fallback também é onde os agentes corrigem a própria lição de casa. Um agente computer-use clicando por uma interface para checar se uma mudança funcionou continua sendo um agente, continua amostrando e continua capaz de concluir que um fluxo quebrado parece bom. O caminho provado entrega uma prova. O fallback entrega uma demo que passou.

A pesquisa por baixo é a parte tranquilizadora

O kit não é um verificador construído do zero. O Verus é separado e já estabelecido. O repositório verus-proof-synthesis da Microsoft Research guarda a base: dois sistemas movidos por LLM, AutoVerus e VeruSAGE, que geram e reparam provas em Verus, avaliados contra 150 e 849 tarefas de verificação, respectivamente.

O que o kit parece acrescentar é empacotamento. É a primeira vez que essa linha de pesquisa em síntese de provas é dobrada num fluxo de produto que vai do plano ao PR, em vez de um exercício de benchmark. É uma afirmação menor que «a IA consegue provar o próprio código», e mais crível.

Note também que as fontes não concordam sobre o nome. Você vai ver Proof-Driven Development Kit e Property-Driven Development Kit na cobertura da mesma semana, ambos atribuídos ao mesmo anúncio. Escolha um e siga; a sigla faz o branding de qualquer jeito.

O que dá para fazer hoje

A conclusão que fica não é «espere o GA». É que uma base de código com muitos agentes agora se divide em território demonstrável e não demonstrável, e sua configuração já deveria saber qual é qual.

Parsers, máquinas de estado, invariantes de estruturas de dados, aritmética com limites, primitivas de concorrência: isso é território demonstrável, e o Verus é código aberto e dá para usar agora, com ou sem o kit. A maior parte do trabalho de front-end, a maior parte do código de cola e tudo cuja correção depende do que um usuário quis dizer, não.

Duas jogadas práticas vêm daí. Primeiro, etiquete os módulos demonstráveis no seu repositório e aponte seus agentes para o Verus só neles, antes de qualquer fornecedor lançar um fluxo. Segundo, pare de pedir aos agentes que também escrevam os testes que validam o próprio trabalho; esse arranjo sempre foi um conflito de interesse, e é a razão pela qual uma suíte verde significa menos do que antes.

A pergunta desconfortável

Se uma spec pode ser aprovada por um humano e uma prova descarregada por uma máquina, para que exatamente serve o revisor? Não para ler código, e provavelmente não para pegar o bug que o agente introduziu na linha 412.

O trabalho do revisor passa a ser o que sempre deveria ter sido: decidir o que o sistema deve fazer e recusar uma especificação que não diz isso. É mais difícil que clicar em aprovar num diff. É também a única parte do trabalho que um verificador não faz por você.