Você teria coragem de aprovar um PR escrito por IA?

Você abre um pull request.

A implementação parece boa. O código está organizado, os nomes fazem sentido, os testes passam e, à primeira vista, nada parece fora do lugar.

Até que surge um detalhe durante a revisão: boa parte daquele código foi gerada por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →.

Talvez o desenvolvedor tenha escrito o prompt, analisado a resposta e ajustado algumas linhas. Talvez tenha usado a ferramenta apenas para completar tarefas repetitivas. Ou talvez quase toda a implementação tenha saído de um modelo e sido integrada ao projeto depois.

A pergunta mais interessante não é:

“Quem escreveu esse código: uma pessoa ou uma IA?”

A pergunta é:

Quem está disposto a colocar o próprio nome nessa mudança e dizer que ela pode ir para produção?

Press enter or click to view image in full size

A IA pode gerar o código.

A responsabilidade continua sendo nossa.

Escrever e responder pelo código já não são a mesma coisa

Durante muito tempo, autoria e responsabilidade andaram quase juntas.

• Você escrevia o código.
• Abriria o pull request.
• Outra pessoa faria a revisão.
• O time aprovaria a mudança.

A responsabilidade sempre foi compartilhada, claro. Ainda assim, era relativamente fácil identificar quem havia criado a implementação e quais decisões levaram até ela.

As ferramentas de IA embaralharam essa relação.

Hoje, um desenvolvedor consegue produzir em poucos minutos uma quantidade de código que levaria horas para escrever à mão. É um ganho de produtividade difícil de ignorar, mas ele traz uma distinção importante:

Gerar código não significa entender o código.

E entender o código ainda não significa estar disposto a responder por ele.

Se um trecho gerado por IA abrir uma vulnerabilidade, derrubar um serviço ou corromper dados, dificilmente a retrospectiva terminará com:

Foi o Copilot que escreveu.

Para a empresa, existe um sistema, um time responsável, um pull request aprovado e um grupo de pessoas que decidiu colocar aquela mudança em produção.

A responsabilidade não foi automatizada.

“Funcionou” nunca foi evidência suficiente

Código gerado por IA tem uma característica perigosa: muitas vezes, ele parece convincente.

• Compila.
• Executa.
• Resolve o exemplo apresentado.
• Usa nomes razoáveis.
• Às vezes, já vem acompanhado de testes.

Tudo isso produz uma sensação de segurança que pode ser maior do que a qualidade real da implementação.

Só que desenvolver software nunca foi apenas fazer o caminho feliz funcionar. Antes de aprovar uma mudança, ainda precisamos perguntar:

• O que acontece com entradas inesperadas?
• Quais casos extremos ficaram de fora?
• Existe concorrência envolvida?
• O comportamento continua correto sob carga?
• Há risco de vazamento de dados?
• O tratamento de erros ajuda ou esconde o problema?
• O código respeita a arquitetura do projeto?
• Estamos adicionando uma dependência sem necessidade?
• Outra pessoa conseguirá entender isso daqui a seis meses?

Press enter or click to view image in full size

Uma IA pode produzir uma resposta bastante plausível sem conhecer todas as decisões que moldaram aquele sistema.

E esse contexto faz diferença.

Às vezes, um trecho aparentemente estranho está daquele jeito porque alguém descobriu, depois de um incidente em produção, que a alternativa “mais elegante” não funcionava naquele ambiente. O modelo que acabou de gerar vinte linhas mais bonitas provavelmente não conhece essa história.

O desenvolvedor precisa conhecer.

O problema não é usar IA. É terceirizar o julgamento.

Uma reação comum a essa discussão é concluir que código gerado por IA deve ser evitado.

Não é esse o ponto.

Copiar uma resposta do Stack Overflow sem entendê-la sempre foi perigoso. Instalar uma biblioteca porque ela apareceu em um tutorial também. O mesmo vale para aceitar uma sugestão da IDE sem olhar o que ela faz.

A IA não inventou esse comportamento. Ela apenas o tornou muito mais rápido — e muito mais fácil de repetir em escala.

Antes, alguém copiava dez linhas ruins. Agora, consegue gerar centenas em poucos minutos.

Por isso, quanto maior a nossa capacidade de produzir código, maior precisa ser a nossa capacidade de julgá-lo.

A produtividade trazida pela IA não diminui a importância da engenharia. Faz o contrário.

O desenvolvedor pode gastar menos tempo digitando cada linha, mas passa a dedicar mais atenção a uma pergunta bem mais importante:

Essas linhas deveriam existir?

Talvez essa seja uma das mudanças mais profundas que a IA trouxe para o desenvolvimento de software.

Revisar código gerado por IA exige mais do que ler o diff

Quando revisamos código escrito por outra pessoa, partimos de uma suposição silenciosa: alguém pensou sobre o problema.

Podemos discordar da abordagem, encontrar bugs ou sugerir outro caminho, mas presumimos que houve um raciocínio até chegar àquela implementação.

Com código gerado por IA, essa suposição precisa ser confirmada.

Não basta avaliar o resultado. O autor do pull request também precisa conseguir explicar por que aquela abordagem foi escolhida.

Uma pergunta simples pode melhorar bastante a revisão:

Por que esta é a melhor abordagem para este caso?

Não se trata de testar ou constranger ninguém. Trata-se de confirmar que existe uma pessoa responsável pela decisão.

Quem envia uma mudança precisa entender o que está propondo. Se a resposta for:

Se a resposta for:

“Não sei bem. A IA sugeriu e os testes passaram.”

Testes também podem estar errados

Imagine o seguinte fluxo:

A IA gera o código. Depois, você pede:

Agora crie testes para essa implementação.

Ela escreve os testes. Todos passam.

Parece ótimo. Mas há um problema: código e testes podem compartilhar a mesma interpretação errada do requisito.

Nesse caso, você terá uma implementação incorreta, validada com perfeição por testes igualmente incorretos.

Os testes continuam indispensáveis. O que não podemos é confundir duas coisas diferentes:

• testar a implementação;
• Validar o comportamento esperado.

Testar a implementação e validar o comportamento esperado.

O segundo depende do entendimento do domínio.

• Quais regras realmente precisam ser respeitadas?
• Quais situações deveriam falhar?
• Quais condições não aparecem no prompt inicial?
• Quais comportamentos são importantes para o negócio?

A segunda depende do conhecimento do domínio.

• Quais regras precisam ser respeitadas?
• O que deveria acontecer em caso de falha?
• Quais condições não apareceram no prompt?
• Que comportamento é importante para o negócio?
• Que erro causaria prejuízo real?

É justamente aí que a participação humana pesa mais.

Segurança pede ainda mais atenção

Código produzido depressa também pode introduzir riscos depressa.

Uma sugestão aparentemente inocente pode adicionar uma biblioteca. Uma função pode usar a API errada. Uma validação pode cobrir apenas os exemplos mais óbvios. Um fluxo pode funcionar sem considerar autenticação, autorização ou exposição de dados sensíveis.

O risco não está em imaginar que a IA produzirá código inseguro de propósito.

Está em acreditar que código plausível também é código seguro.

Não é.

Se fazemos revisão de arquitetura e segurança em código escrito manualmente, precisamos manter o mesmo cuidado com código produzido com assistência de IA. Em alguns casos, vale redobrar a atenção justamente porque o volume de mudanças cresceu.

Um desenvolvedor que antes entregava 100 linhas por dia talvez agora consiga entregar 500. A capacidade de revisão do time, porém, não aumentou automaticamente na mesma proporção.

Esse descompasso merece cuidado.

E quem vai manter esse código daqui a seis meses?

Depois que a empolgação com a produtividade passa, sobra uma questão menos chamativa: manutenção.

Imagine que uma IA produza uma implementação sofisticada e correta. O desenvolvedor faça alguns ajustes, os testes passem e o PR seja aprovado.

Seis meses depois, aparece um bug.

Quem precisar investigar o problema conseguirá entender o raciocínio por trás daquela implementação? O time saberá por que certas decisões foram tomadas? Ou terá apenas um grande volume de código que funcionava no dia em que foi criado?

Software não termina no merge.

Em sistemas importantes, escrever a primeira versão representa apenas uma parte do custo. O código ainda será lido, alterado, depurado, migrado e, em algum momento, removido.

Por isso, não basta perguntar:

A IA consegue escrever isso?

Também precisamos perguntar:

Nosso time consegue manter isso?

Talvez autoria passe a significar outra coisa

Boa parte da discussão sobre IA tenta descobrir quem “escreveu” o código.

Talvez essa pergunta perca importância com o tempo.

Em vez de tratar a autoria como o ato de digitar cada linha, podemos entendê-la como responsabilidade pelas decisões tomadas.

Você pode não ter escrito manualmente todos os caracteres. Ainda assim, foi você quem:

• entendeu o problema;
• definiu as restrições;
• avaliou a abordagem;
• descartou alternativas inadequadas;
• verificou os riscos de segurança;
• validou o comportamento;
• revisou os testes;
• analisou o impacto na arquitetura;
• Decidiu que a mudança estava pronta.

Nesse cenário, a IA é uma ferramenta de produção.

O julgamento continua sendo humano.

Uma regra simples para código assistido por IA

Cada time provavelmente criará suas próprias políticas.

Alguns registrarão no pull request quando uma ferramenta de IA tiver sido usada. Outros adotarão regras diferentes conforme a sensibilidade do sistema. Projetos financeiros, médicos ou de infraestrutura crítica podem exigir revisões adicionais.

Mas há uma regra que funciona independentemente da ferramenta ou do processo:

Não envie código que você não consegue defender.

Se a mudança está no seu pull request, você deveria conseguir explicar:

• o que ela faz;
• por que foi implementada dessa forma;
• quais alternativas foram consideradas;
• onde pode falhar;
• quais riscos apresenta;
• como foi testada;
• Por que está pronta para produção.

Isso vale para código escrito à mão, copiado de uma documentação, adaptado de outra biblioteca ou gerado por IA.

Se está no seu PR, também é sua responsabilidade.

Press enter or click to view image in full size

A IA pode escrever. Alguém ainda precisa assinar embaixo.

Escrever software com ajuda de IA tende a se tornar cada vez mais comum.

Talvez, em pouco tempo, perguntar se um desenvolvedor usou IA seja tão pouco interessante quanto perguntar se ele usou autocomplete.

Quanto mais fácil ficar gerar código, maior será o valor de quem sabe separar código convincente de código correto.

• De quem entende a arquitetura.
• De quem conhece o domínio.
• De quem enxerga os riscos.
• De quem faz as perguntas que não estavam no prompt.

E, acima de tudo, de quem aceita responder pela decisão.

Quando aquele pull request chegar à produção, a empresa não estará confiando na IA.

Estará confiando nos engenheiros que aprovaram a mudança.

Então fica a pergunta:

Se uma IA escrevesse 80% do seu próximo pull request, você assinaria embaixo dos outros 20% — ou dos 100%?