Meta detalha o JiTTesting em produção: testes gerados por LLM pegam bugs antes do merge

Fala aí, beleza? Em 29 de outubro de 2026 a Meta publicou no blog Engineering at Meta como os Catching JiTTests saíram do protótipo de pesquisa e viraram infraestrutura interna em produção

O sistema usa LLM pra gerar testes sob medida pra cada mudança de código (o tal do diff), pensados pra FALHAR quando a mudança traz um bug, e tudo isso com os engenheiros no modelo human-on-the-loop

Já deixando claro logo de cara: segundo as fontes, o JiTTesting é infraestrutura interna da Meta: nenhum dos posts ou do artigo de pesquisa menciona produto, API ou versão em código aberto disponível pra uso externo 🙂

O que é o JiTTesting e o que é um catching test

JiTTesting (Just-in-Time Testing) é a geração automática de testes pouco antes do envio do código, feitos especificamente pra mudança que está sendo enviada

Nada de suíte genérica que vive pra sempre no repo: o teste nasce pra checar aquele diff e pronto

E aí entra a sacada principal, que é o catching test

Que diferença tem pra um teste comum?

Segundo o artigo de pesquisa da Meta no arXiv, um teste de hardening protege contra regressões futuras e passa quando é gerado

Já o catching test serve pra pegar uma regressão ou falha introduzida pela mudança atual, e por isso ele DEVE falhar diante do bug

É tipo a diferença entre um alarme que fica instalado na casa e um cão farejador que entra só pra checar a mala que acabou de chegar haha

Esse conceito não é novidade de agora: em fevereiro de 2026 a Meta já tinha apresentado os JiTTests no post The death of traditional testing como resposta ao desenvolvimento agêntico

A proposta ali: testes sob medida pra cada mudança, gerados por LLM pouco antes do envio, que não exigem manutenção nem revisão do código de teste

O post de outubro é a continuação, mostrando o sistema rodando em escala

Como o sistema funciona: dois fluxos de geração e o filtro de falsos positivos

O JiTTesting da Meta tem dois fluxos pra gerar testes, mais uma camada de filtro antes de qualquer coisa chegar num engenheiro

Fluxo dodgy diff:

Aqui cada diff é tratado como se fosse um mutante

Se tu conhece mutation testing, é bem semelhante: a geração de testes com LLM é guiada por mutação e produz testes que diferenciam o comportamento do diff do comportamento da versão anterior

Fluxo intent-aware:

Nesse fluxo um LLM deduz a INTENÇÃO do diff olhando as mudanças no código, o título e o resumo

A partir dessa intenção, o LLM descreve os riscos: as formas como implementar aquela intenção poderia dar errado: e usa esses riscos pra construir mutantes

Depois ele gera testes pra matar cada mutante e roda esses testes no diff real: os que falham viram weak catches, candidatos a bug

A Meta não divulgou, no texto publicado, números comparando diretamente quantos weak catches cada fluxo gera. O que fica claro é que os dois fluxos são complementares: um ataca a diferença de comportamento bruta (dodgy diff), o outro usa a intenção declarada no diff (título, resumo, código) pra guiar a busca por risco

O filtro de falsos positivos:

Candidato a bug não é bug confirmado, e mandar tudo pro engenheiro seria spam puro

Então os weak catches passam por um ensemble de LLMs atuando como juízes (LLM-as-Judge) e por um sistema baseado em regras chamado RubFake (Rule-Based False-Positive Killing Environment), que dá julgamentos determinísticos e verificados

Juntos eles ranqueiam os candidatos, e só os mais bem colocados chegam aos engenheiros

E o human-on-the-loop?

No human-in-the-loop clássico, alguém revisa cada saída da IA

No human-on-the-loop da Meta, os engenheiros definem os critérios e avaliam os resultados de forma agregada, sem supervisionar item por item

O humano sai da linha de montagem e vai pro painel de controle, sacou? 😀

Quando isso roda, na prática:

Em produção, o sistema roda durante a noite, aproveitando capacidade ociosa, e mira os diffs enviados no dia anterior que um mecanismo parecido com o Diff Risk Score (DRS) classifica como arriscados: tudo antes de o código ser integrado (land)

Os números divulgados pela Meta

Todos os números abaixo foram divulgados pela própria Meta, não são verificação independente

E vale separar o que é produção do que é pesquisa

Em produção (primeiro semestre de 2026):

• Os Catching JiTTests tiveram papel central na detecção de 74 bugs graves de privacidade (nível SEV) ainda na fase de diff
• As ocorrências de SEVs de privacidade caíram 20% no período
• 589 engenheiros (64% dos que a equipe procurou) interagiram com o sistema e relataram uma taxa de 60% de verdadeiros positivos

Na pesquisa (arXiv 2601.22832):

O artigo "Just-in-Time Catching Test Generation at Meta" foi enviado em 30 de janeiro de 2026, tem Mark Harman entre os autores e trata de sistemas de backend com centenas de milhões de linhas de código

• Análise de 22.126 testes gerados
• Métodos que levam em conta a mudança de código geraram 4x mais candidatos a catch do que testes de hardening e 20x mais do que testes que falham por coincidência
• Os avaliadores baseados em regras e em LLM reduziram em 70% a carga de revisão humana
• 41 candidatos foram reportados aos engenheiros, 8 se confirmaram como verdadeiros positivos e 4 deles teriam causado falhas graves

O que a Meta NÃO detalhou nas fontes: quais modelos de LLM o sistema usa, quanto custa rodar tudo isso e quais linguagens ou plataformas a versão de produção cobre

O que o caso da Meta ensina para quem usa agentes de código

Não tem nada pra instalar aqui, beleza?

Mas tem decisão de design MUITO aproveitável pra quem valida código gerado por IA, seja com agente solto ou com um sistema de meta-prompting tipo o GSD no Claude Code

Se liga nos pontos:

• Teste que precisa falhar: a maioria das suítes só tem teste que passa. A ideia do catching test é escrever o teste pensando no bug que aquela mudança pode ter introduzido
• A intenção do diff é sinal: a Meta criou um fluxo dedicado que usa título e resumo do diff pra inferir riscos antes de gerar os testes. Descrição bem escrita no PR deixa de ser formalidade e vira insumo pra validação
• Filtro em camadas: LLM como juiz sozinho é probabilístico, então a Meta colocou regras determinísticas do lado. Uma camada cobre o ponto cego da outra
• Revisão agregada: em vez de olhar cada saída, o humano define critério e acompanha o resultado no todo. Isso escala melhor quando o volume de código gerado explode

Agora, a parte que o hype costuma pular…

Os resultados são do ambiente da Meta e relatados pela própria empresa

E uma taxa de 60% de verdadeiros positivos significa que parte dos alertas que chegam aos engenheiros ainda é ruído

Ou seja, ajuda muito, mas não é bala de prata, e como o sistema é interno da Meta, tu não tem como rodar ele no teu projeto pra conferir esses números

E por falar em qualidade do que a IA entrega, no canal tem um vídeo sobre a skill hallmark, focada em eliminar o AI slop no design de sistemas (outro ângulo do mesmo problema: não aceitar de olho fechado o que o modelo cospe)

Onde ler os detalhes

Pra metodologia completa, o caminho é ler o post de 29 de outubro no Engineering at Meta e o artigo arXiv 2601.22832, que traz os detalhes da fase de pesquisa

E se tu valida código gerado por agentes, faz o teste com a tua própria suíte: quantos testes ali só passam e quantos foram pensados pra pegar o bug da mudança atual?

Se a resposta for "todos só passam", já tem um bom ponto de partida aí =)

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.