O STJ rejeitou uma prova por IA. Seu time ainda aceita PR de IA no escuro?

No dia 8 de abril de 2026, a Quinta Turma do STJ recusou usar um relatório produzido com IA generativa como prova em um caso de injúria racial. O motivo interessa muito mais gente além do pessoal do direito: o texto trouxe um elemento que o laudo oficial não encontrou, e a defesa não tinha como auditar aquilo com segurança.

Eu bati o olho nessa decisão e pensei em desenvolvimento na hora.

Tem time usando IA para resumir incidente, explicar log, abrir pull request, sugerir refactor e até escrever teste de regressão. Eu também uso esse tipo de ferramenta. O problema começa quando a saída do modelo entra no fluxo com cara de evidência, não de rascunho.

Fluidez não é prova
Quando o Cursor, o Windsurf ou qualquer outro agente devolve um diff grande com uma explicação redondinha, a tentação é aceitar pelo ritmo. Parece que alguém já pensou por você. Às vezes, pensou mesmo. Às vezes, só escreveu com confiança.

Foi exatamente isso que o STJ tratou com a seriedade certa. Se a origem do resultado é opaca, se ninguém consegue reproduzir de onde saiu aquela conclusão e se o artefato oficial diz outra coisa, não dá para chamar isso de prova confiável.

Em software, a conta é parecida. Um modelo pode:

inventar a causa errada para um bug intermitente
gerar um teste que só confirma caminho feliz
propor um refactor que compila, mas bagunça as invariantes do domínio
resumir um PR de um jeito convincente e mesmo assim esconder o risco real
O texto sai limpo. O problema continua lá.

É assim que nasce a dívida de controle
Eu gosto de pensar nisso como dívida de controle.

Ela aparece quando você aceita uma mudança porque ela parece boa, mas já não consegue responder com calma:

o que foi de fato validado
por que essa implementação é segura
onde estão os limites da mudança
como reproduzir a conclusão sem pedir para a mesma IA explicar de novo
Esse é o lado perigoso do vibe coding. A velocidade sobe muito rápido. A capacidade de auditoria nem sempre acompanha.

Ser sênior em 2026 tem menos a ver com escrever tudo na unha e mais a ver com manter o sistema legível quando a máquina acelera. Se a IA escreve 80% do caminho, alguém precisa continuar dono dos critérios que separam um atalho útil de uma bomba-relógio.

Como usar IA sem terceirizar seu julgamento
O jeito mais seguro que encontrei até agora é tratar a IA como hipótese com ótima interface, não como autoridade técnica.

Peça mudanças menores. Diff de 30 linhas dá para revisar. Diff de 700 linhas com cinco arquivos renomeados vira aposta.
Exija prova junto com a sugestão. Teste que falha antes, comando de reprodução, arquivo afetado, contrato alterado.
Revise fronteiras do sistema antes de revisar estilo. O perigo quase nunca está na indentação.
Desconfie especialmente de resumo automático de incidente, log e PR. É aí que o modelo mais parece certo sem necessariamente estar certo.
Tem uma frase simples que eu acho útil para esse momento: saída de modelo não é observabilidade. No máximo, é palpite informado.

O ponto não é abandonar IA
A decisão do STJ não é um argumento para voltar ao editor sem copiloto. Ela só deixa claro um limite que muita gente na engenharia anda fingindo que não existe.

Modelo gera proposta. Quem transforma isso em decisão ainda é o time.

Se você não aceitaria um laudo opaco como prova em um processo sério, também não deveria aceitar um PR opaco no coração do seu produto só porque a explicação veio bonita e o deploy passou de primeira.

No fim, usar IA bem no desenvolvimento é isso: ganhar velocidade sem abrir mão de autoria técnica.

Referências
STJ | HC 1059475, decisão de 8 de abril de 2026