A inteligência artificial está escrevendo para quem não quer escrever e resumindo para quem não quer ler.

No meio dessa operação, alguém ainda precisa entender.

Eu acho essa ironia particularmente boa quando ela aparece numa revisão de código — o trabalho de examinar uma alteração de software, procurar problemas e discutir o que precisa mudar antes de incorporá-la. É o que chamamos de code review, ou apenas review.

Você economiza alguns minutos para gerar o parecer. O colega recebe uma pequena enciclopédia e precisa descobrir o que ali é problema real, repetição, hipótese ou apenas parágrafo com boa postura.

Parabéns. A escrita foi automatizada. A leitura ganhou um novo responsável.

TL;DR

IA pode investigar código, testar hipóteses e tornar uma revisão mais clara. Publicar sua saída sem ler, conferir e eliminar duplicatas pode transferir o trabalho para o restante do time. O critério de uma boa revisão é a contribuição verificável: qual problema existe, onde, em que condição, com que consequência e o que o comentário acrescenta ao que já foi levantado. Texto longo pode ser necessário. Volume, sozinho, não prova análise. Quem publica o review precisa responder pelo que decidiu manter.

O comentário já estava lá. Vieram outros parecidos.

Em uma revisão, fiz uma análise direcionada e usei IA para tornar o texto mais objetivo. O julgamento continuava meu: o que investigar, o que estava sustentado e o que merecia chegar à discussão.

Depois, um colega publicou uma revisão extensa gerada por outra IA. Na minha leitura, ela repetia três ou quatro vezes pontos que já tinham sido levantados.

Essa é minha lembrança e minha interpretação do episódio, não uma auditoria independente. Empresa, pessoas e detalhes da alteração ficam fora deste texto. O hábito me interessa mais que a identidade do colega.

O incômodo estava na contribuição: mais texto não significava, naquele caso, mais problema descoberto ou mais decisão esclarecida.

A revisão precisava revisar também o que já havia sido revisado.

A economia aparece para um. A conta chega para o time.

Produzir texto com IA pode ser rápido. Receber esse texto não torna sua avaliação instantânea.

Alguém precisa abrir a alteração, entender o contexto, localizar o trecho, verificar se o risco existe e comparar o comentário com o que a discussão já contém.

Se o mesmo problema aparece com quatro formulações, o destinatário precisa perceber que não são quatro problemas. Se uma sugestão depende de uma premissa não confirmada, alguém precisa descobri-la. Se o comentário chega depois de uma correção, alguém precisa notar que ele já perdeu o objeto.

A geração saiu barata para quem enviou. A triagem ficou com quem recebeu.

Esse custo pode virar atenção interrompida, resposta duplicada, investigação repetida e retrabalho. Não tenho uma porcentagem para atribuir a isso. Tenho um critério: a economia de quem gera não deveria ser avaliada ignorando o trabalho de quem precisa conferir.

“Meu review ficou pronto mais rápido” descreve uma etapa. Ainda falta saber se o time chegou mais rápido a uma alteração melhor.

Repetir o achado não é confirmar o problema

Um achado é o problema específico que uma revisão afirma ter encontrado.

Se duas análises chegam à mesma suspeita e uma delas traz um teste que a reproduz, uma condição antes ignorada ou uma consequência diferente, existe contribuição nova.

Se a segunda apenas troca o vocabulário e repete a conclusão, existe mais texto.

Uma hipótese também pode ser útil, desde que continue apresentada como hipótese e explique o que falta verificar. O que não ajuda é dar a uma suspeita o tom de um defeito comprovado porque o comentário fica mais imponente assim.

Eu quero que a revisão ajude a decidir. Para isso, importa ler o código, os critérios da mudança, os comentários existentes e as correções que já aconteceram.

Gerar um parecer sobre um recorte e despejá-lo numa discussão viva sem reconciliar esse contexto é um jeito eficiente de chegar atrasado com muita convicção.

“Então peça para a IA resumir”

Claro que posso pedir.

A primeira IA escreve demais. A segunda resume. Uma terceira compara os resumos. Enquanto isso, alguém tenta descobrir se a primeira tinha razão.

A cena é irônica. O recurso pode ser útil.

Um resumo bem feito ajuda a navegar um parecer necessário. Mas reduzir o tamanho não verifica o conteúdo. Pode até apagar justamente a condição que separava um risco real de uma suspeita genérica.

Também não quero trocar um texto enorme por um comentário curto e errado.

O trabalho continua sendo selecionar, conferir e julgar. A responsabilidade pelo que se publica permanece com quem coloca o parecer na discussão.

Uma revisão longa pode ser a revisão certa

Há mudanças complexas. Às vezes uma explicação longa é necessária para mostrar uma sequência de falhas, uma restrição de compatibilidade ou um risco que atravessa vários componentes.

Meu critério não é contar linhas nem impor um comentário minimalista a todo problema.

É perguntar o que cada trecho faz pelo leitor e pela decisão.

O guia de revisão de código do Google sobre comentários recomenda explicar o raciocínio e tornar explícito por que uma sugestão importa. Essa é uma referência de comunicação, não uma medição do episódio que relatei.

Uma boa justificativa pode precisar de espaço. Quatro versões da mesma cobrança continuam precisando de edição.

Objetividade é entregar informação suficiente para a próxima decisão, com a menor carga desnecessária possível.

IA útil entra antes do botão de publicar

Eu quero usar IA para investigar melhor e escrever com mais precisão.

Posso pedir que procure casos que escaparam à minha análise, confronte uma hipótese, prepare um teste, compare a alteração com seus requisitos ou encontre duplicatas nos meus próprios comentários. Posso pedir uma explicação mais clara depois que o raciocínio está sustentado.

Mas o resultado precisa voltar para uma conferência concreta:

• Qual trecho e qual condição sustentam este achado?
• O efeito foi demonstrado, inferido ou ainda precisa de teste?
• Isso já foi levantado ou corrigido? O que esta análise acrescenta?
• A proposta cabe no escopo e no comportamento esperado da alteração?
• Eu li e consigo defender o comentário que vou publicar?

Se várias observações descrevem o mesmo problema, eu as consolido e preservo a evidência nova. Se não há contribuição adicional, descarto a duplicata. Se falta contexto, digo qual, em vez de transformar incerteza em acusação técnica.

Isso também pode entrar no fluxo de trabalho da revisão. Geração não precisa ser a última etapa antes do envio.

Alguém precisa entender antes de assinar

A provocação sobre escrever menos e ler menos descreve um atalho que quero questionar. Não é uma estatística sobre todas as pessoas nem um diagnóstico da intenção do colega.

Há usos excelentes de IA para ler, investigar e revisar mais. Eu quero esses usos.

O que recuso é tratar a facilidade de produzir um parecer como autorização para deixar sua compreensão com o destinatário.

Antes do próximo review, confira o que já foi dito, retire o que apenas repete, marque o que ainda é hipótese e assuma o que ficou.

Você pode automatizar uma parte enorme do trabalho.

Só não chame de revisão concluída o pacote que ainda precisa ser revisado por quem o recebeu.

Referência e limites de uso

O guia de comentários de revisão do Google sustenta a orientação de explicar o raciocínio e a relevância das sugestões. Não avalia ferramentas de IA, não mede produtividade nem prova o comportamento do episódio. O relato é autoral; a transferência de custo de atenção e os critérios propostos são a interpretação prática deste texto.

A capa é uma ilustração editorial sintética, sem texto e independente de idioma. Não representa o ambiente de trabalho nem os participantes do relato.