A Microsoft Research provou um login escrito por IA para toda entrada. O que ela não provou é a lição
O PDD Kit transforma o pedido de um desenvolvedor em especificação formal, faz agentes escreverem código e provas e marca o que segue testado mas não provado. Um protótipo com um hábito útil.
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.
Um desenvolvedor pede algo simples: que os usuários façam login com senha e recebam um token que expira depois de um dia. Duas frases. No novo experimento da Microsoft Research, essas duas frases viraram oito condições formais que o código de login precisa satisfazer para toda entrada possível, e um agente de IA escreveu tanto o código quanto a prova matemática de que ele cumpre isso.
O projeto se chama PDD Kit, do Catalyst Lab da Microsoft Research, do GitHub Next e do grupo RiSE. É um protótipo de pesquisa, e os autores dizem isso. Ainda assim, é a imagem mais clara até agora de como a checagem de código escrito por IA pode parecer quando os testes não bastam.
Como funciona
O PDD Kit usa o Verus, uma ferramenta de verificação para Rust. A equipe demonstrou o kit no Pet Store, uma loja full-stack em Rust de cerca de 5 mil linhas dentro do projeto Chopin, do GitHub Next, e focou na lógica de login.
- Planejar
- Especificar
- Estressar a especificação
- Provar
- Entregar
Duas escolhas de design se destacam.
A checagem de mutação ataca um problema que os autores chamam de vibe verification: uma especificação tão fraca que quase qualquer código a satisfaz. Ao plantar um bug para cada condição e confirmar que a prova então falha, o PDD Kit testa a própria especificação.
A fronteira confiável é explícita. Algumas peças não podem ser provadas e são marcadas como confiáveis, e o desenvolvedor aprova cada uma delas. Para o fluxo de login, havia seis. Testes que passam são rotulados como evidência, não como prova.
A parte honesta
Os autores listam o que o PDD Kit não consegue provar, e a lista é a coisa mais útil do post para quem roda código gerado por IA em produção:
- bibliotecas de terceiros, como as crates bcrypt, sqlx e jsonwebtoken;
- fatos sobre o mundo externo, como o que está no banco SQLite ou o que o relógio marca;
- se uma operação termina, ou quanto tempo ela leva; uma consulta assíncrona que trava não quebra nenhuma condição;
- requisitos que ninguém escreveu.
Eles também dizem que a checagem de senha e duas consultas, as peças que carregam a maior parte do peso de segurança, são testadas mas não provadas. E as provas ainda exigem esforço real, principalmente na elaboração da própria prova. Hoje funciona apenas para Rust.
O que tirar de um protótipo
Poucas empresas vão rodar o Verus no seu sistema de gestão de pedidos no próximo ano. Mas o hábito que o PDD Kit impõe é transferível agora, e ele ataca o problema que descrevemos em capacidade de verificação de IA se tornando o novo gargalo: agentes barateiam o código, e checá-lo não.
Escreva a intenção antes do código. O pedido de duas frases virou oito condições porque um agente fez perguntas. A maioria das sessões de código com IA pula essa etapa, e o revisor depois precisa adivinhar o que o código deveria fazer.
Teste os testes. O teste de mutação existe há décadas e é pouco usado. Se agentes escrevem tanto o código quanto os testes, uma checagem de que os testes conseguem de fato falhar é a proteção mais barata contra testes que não provam nada.
Mantenha uma lista do que é confiável. Para cada componente escrito por IA, registre o que foi provado, o que foi testado e o que é simplesmente confiável, com o nome de uma pessoa ao lado de cada item confiável. É o que prova de fora do modelo parece em uma revisão de código: não certeza, mas um relato claro de onde a certeza acaba.