Insights · Code review

Código gerado por IA: só aprove o que você sabe explicar, e deixe rastro quando pular a checagem

Publicado em 19 de outubro de 2026

Aprovar código gerado por IA sem conseguir explicar o que ele faz é carimbo, não revisão. Quem assina precisa saber dizer como a mudança se comporta quando algo dá errado. E pular essa checagem precisa deixar registro.

O gancho é o Sphinx, projeto de código aberto com licença MIT (sem relação com o gerador de documentação de mesmo nome), apresentado no Hacker News em 18 de outubro de 2026. É um git hook que faz perguntas sobre o diff antes do push. Ele entra aqui como exemplo de mecanismo, não como recomendação de ferramenta. As descrições vêm do README do projeto, em tradução nossa.

O que o hook faz, segundo o projeto

Pausa o push. Num push para um branch protegido, feito por pessoa ou por agente de código, o Git espera enquanto o Sphinx pede que a pessoa preveja o que a mudança vai fazer. Quem erra recebe uma explicação e um cenário novo; quem passa, segue.
Pergunta sobre comportamento. Modos de falha e invariantes, não nomes de arquivo ou de função. Vale consultar o código.
Usa um revisor separado. As perguntas vêm de outro modelo, que lê o commit com ferramentas de Git somente leitura e não vê a conversa que produziu o código.
Deixa pular, com registro. Dá para pular uma vez ou desligar a checagem no repositório. Pular nunca conta como passar, e cada pulo ou desligamento fica registrado.

O que ele não promete

O próprio README avisa que a ferramenta "é treino, não uma barreira de segurança". Qualquer pessoa com acesso local, inclusive um agente de código, pode contornar hooks. Passar não prova quem escreveu o código nem que a pessoa entendeu sem ajuda, e o examinador é um modelo de linguagem, que pode errar. A versão atual cobre só commits e pushes locais, não merges pela web, checagens exigidas no CI nem deploys. Segundo o projeto, ele testa entendimento em vez de auditar o código.

Por isso, um quiz sobre o diff não substitui testes, revisão nem checagem de segurança. Ele tenta medir outra coisa: se quem vai aprovar entendeu o que está aprovando.

Supervisão não é carimbo

Na nossa leitura, com agentes de código escrevendo a maior parte do diff, o risco não é só o bug que passa. É o PR que mostra um revisor quando ninguém do time sabe explicar o que entrou.

A pergunta que separa revisão de carimbo cabe em qualquer PR, com ou sem ferramenta: o que esta mudança faz quando uma dependência falha, a mesma mensagem chega duas vezes ou o dado vem vazio? Para a Ithaca, quem não sabe responder ainda não terminou de revisar. O agente pode escrever o código e a descrição do PR; a explicação precisa estar com quem assina.

Pular a checagem precisa deixar rastro

Checagem obrigatória tem exceções; o próprio README dá a correção urgente em produção como exemplo de motivo para desligá-la. Na nossa leitura, registrar cada pulo, como o Sphinx faz segundo o projeto, é rastreabilidade mínima: não impede o erro, mas a decisão de pular não some.

Na plataforma da Ithaca, o registro cobre a sessão inteira: cada sessão dos agentes de código guarda pedido, passos, modelo, custo, resultado e autoria (o que registrar em cada sessão). Meses depois, ainda dá para saber quem decidiu o quê.

A outra ponta: testar o revisor de IA

O Sphinx testa a pessoa. Um post de 17 de outubro no TabNews propõe testar a máquina: antes de confiar num revisor de PR por IA, rodá-lo em PRs antigos cujo desfecho o time conhece e anotar o que ele deixa passar. O autor apresenta o roteiro como proposta, não como resultado de um teste feito.

Como um time com agentes escrevendo a maior parte do código organiza a revisão em camadas, com aprovação humana por nível de risco, está na nossa nota sobre code review com IA.

Onde a Ithaca fica

Na plataforma de desenvolvimento agentic, pessoas do time do cliente leem o código que entra em produção, seja qual for o risco. Como escrevemos sobre vibe coding e engenharia agêntica, alguém do time precisa saber explicar o que entrou, e uma pessoa, não o agente, responde pela mudança. Supervisão humana e rastreabilidade são a regra da Ithaca no nível 4 de autonomia, em que a plataforma opera.

Quer agentes de código com leitura humana antes da produção e cada sessão registrada? Agendar demonstração

Perguntas frequentes

Um quiz sobre o diff substitui code review ou testes?

Não. O README do Sphinx diz que a ferramenta é treino, não uma barreira de segurança, e que testa entendimento em vez de auditar o código. Testes, revisão e checagens de segurança continuam necessários.

O que é aprovação carimbo em code review?

É a aprovação dada sem que quem aprova tenha entendido a mudança: o processo registra uma revisão que não aconteceu. Em inglês, a expressão comum é rubber stamp.

Uma ferramenta assim envia código para fora da empresa?

No caso do Sphinx, sim, segundo o README: o provedor do modelo revisor recebe o código alterado, arquivos relacionados e as respostas; arquivos .env e chaves privadas ficam de fora por padrão. Confira antes o que a política de modelos da empresa permite enviar.

Fontes

Sphinx, repositório no GitHub (licença MIT), README consultado em 19 out. 2026, e página do projeto. Descrição do próprio projeto.
Show HN: Sphinx, Hacker News, 18 out. 2026.
Centelha. Antes de confiar na revisão de PRs por IA, teste os bugs que ela deixa passar. TabNews, 17 out. 2026.