Revisão crítica de código gerado

Os módulos anteriores cobriram como dar bom contexto e onde aplicar IA com mais segurança. Este módulo trata do último filtro antes de qualquer código gerado entrar no repositório: a revisão. E ela precisa de uma checklist diferente da que você usaria para revisar o código de um colega.

Por que a checklist muda

Quando você revisa código de outra pessoa, parte do trabalho é entender a intenção dela — o que ela estava tentando fazer, e se a abordagem faz sentido para o problema. Com código gerado, a "intenção" foi sua, no pedido que você fez — então essa parte já está resolvida. O que sobra para checar é diferente: se o código realmente faz o que você pediu, e se o que você pediu era, de fato, o que o problema precisava.

Isso reflete diretamente o critério de verificação do curso de Fundamentos de IA: quanto custa se essa resposta específica estiver errada, e o erro seria visível ou silencioso.

Quatro pontos que merecem atenção extra

1. Casos de borda não mencionados no pedido. Um assistente responde ao que foi pedido literalmente. Se você pediu "processar uma lista de pedidos" sem mencionar o que fazer com uma lista vazia, o código pode ou não tratar isso bem — e você não vai saber sem checar especificamente esse caso.

2. Tratamento de erro genérico demais. É comum código gerado capturar qualquer erro de forma ampla e seguir em frente, mascarando um problema real em vez de deixá-lo aparecer. Isso é particularmente perigoso porque o código "funciona" nos testes rápidos e só falha de um jeito confuso mais tarde.

3. Dependências ou padrões que não existiam no projeto antes. Um assistente pode introduzir uma biblioteca nova ou um padrão diferente do que o resto do projeto usa, porque não tinha contexto suficiente sobre as convenções (o problema central do módulo 1). Vale conferir se o que foi gerado é consistente com o que já existe, não só se funciona isoladamente.

4. Alegações sobre o próprio código que soam plausíveis. Um comentário ou explicação dizendo "isso lida com concorrência de forma segura" ou "isso está otimizado para esse caso" merece o mesmo ceticismo do padrão de confiança desacoplada de acerto, do curso de Fundamentos de IA: a afirmação soar convincente não é evidência de que ela é verdadeira.

O nível de revisão depende do que o código faz

Nem todo trecho gerado merece o mesmo nível de escrutínio — o critério é o mesmo do módulo de humano no circuito, do curso de IA para Produtividade, aplicado a código:

• Código que lida com dados sensíveis, segurança, ou dinheiro exige revisão total, sempre.
• Código de interface visual, sem lógica de negócio embutida, tolera mais confiança direta — o erro, se existir, costuma ser visível na tela.
• Código intermediário (lógica de negócio comum, sem dado sensível) fica bem servido por amostragem: revisão cuidadosa nas primeiras vezes, mais leve depois que o padrão se mostrar consistente.

Um hábito que compensa: pedir a explicação antes de aceitar

Para trechos não triviais, pedir ao próprio assistente para explicar o que o código faz, linha por linha, antes de aceitar, costuma revelar problemas que uma leitura rápida não pega — porque força você a confirmar, item por item, que o comportamento descrito bate com o que você realmente queria. Se a explicação e o código não baterem entre si, isso já é um sinal de problema, independente de qual dos dois está errado.

Exercício

Pegue o último trecho de código gerado por IA que você aceitou sem revisão detalhada. Aplique os quatro pontos deste módulo a ele: existe caso de borda não tratado? o tratamento de erro é genérico demais? introduziu algo fora do padrão do projeto? alguma alegação no código ou comentário merece verificação?

O que fica

• Revisar código gerado é diferente de revisar código humano: a intenção já foi resolvida no seu pedido — o que resta é checar se o código cumpre e se o pedido era o certo.
• Quatro pontos de atenção: casos de borda não mencionados, tratamento de erro genérico demais, padrões fora do que o projeto já usa, e alegações sobre o próprio código que soam plausíveis sem prova.
• O nível de revisão depende do que o código faz — dado sensível exige revisão total; interface visual tolera mais confiança direta.
• Pedir a explicação do código antes de aceitar revela inconsistências que uma leitura rápida não pega.