A IA escreveu o código. Quem vai manter?

O problema não termina quando o código compila

Gerar uma função em segundos é útil. Mas o custo de um software não é medido apenas pelo tempo gasto na primeira versão. Ele aparece quando precisamos corrigir um incidente, alterar uma regra de negócio, atualizar uma dependência ou explicar por que uma decisão foi tomada.

O problema não é usar inteligência artificial na programação. É confundir velocidade de produção de código com capacidade de evolução do produto. A IA pode ajudar a escrever uma implementação; a responsabilidade por compreendê-la, validá-la e mantê-la continua sendo da equipe.

Quando vejo uma alteração gerada por um agente, faço uma pergunta simples: se ela quebrar daqui a três meses, alguém conseguirá entender o que mudou, por que mudou e como recuperar o comportamento correto?

Quatro custos que não aparecem no primeiro diff

1. Contexto ausente

Um agente pode sugerir uma solução tecnicamente plausível que desconhece regras anteriores, limites contratuais ou o histórico de um sistema. Um trecho elegante pode violar uma invariável que ninguém colocou no prompt. Não basta avaliar a função isoladamente: é preciso olhar para os fluxos que dependem dela.

2. Contratos implícitos

Um endpoint que responde com sucesso pode alterar silenciosamente uma ordenação, um valor padrão, um tratamento de erro ou uma regra de autorização. Esses detalhes muitas vezes não aparecem no happy path. A revisão deve explicitar o que a mudança preserva e o que ela modifica.

3. Testes que verificam a implementação, não o comportamento

Uma bateria verde é uma evidência limitada. Se os testes foram produzidos com as mesmas suposições incorretas do código, eles podem apenas confirmar o equívoco. Vale incluir exemplos de fronteira, casos negativos, contratos e invariantes independentes da implementação.

4. Falta de dono para a decisão

Quem aceita a mudança também precisa aceitar seus trade-offs. Se ninguém consegue explicar o motivo de adicionar uma abstração, uma dependência ou um mecanismo de cache, o resultado pode virar um débito de manutenção difícil de enxergar.

Um exemplo de revisão que muda a conversa

Imagine um agente alterando uma função que decide se uma matrícula pode ser processada. A sugestão simplifica o código e passa pelos testes unitários existentes. Antes de aprovar, eu verificaria:

• Contrato: as condições de elegibilidade continuam iguais?
• Autorização: a operação ainda valida o contexto do usuário e da instituição?
• Concorrência: dois pedidos simultâneos podem violar uma restrição?
• Reversão: conseguimos desativar a alteração sem migração arriscada?
• Observabilidade: um erro novo seria detectável sem expor dados pessoais?

Esse tipo de checklist é mais valioso do que perguntar apenas se a resposta parece correta. Ele transforma uma revisão superficial de texto em análise de comportamento.

Como eu estruturaria a colaboração com agentes

Não começaria por pedir uma implementação completa sem contexto. Dividiria o trabalho em decisões pequenas e observáveis.

Primeiro, definiria o resultado esperado, as restrições e as interfaces que não podem mudar. Depois, pediria alternativas com custos e riscos. Com o caminho escolhido, solicitaria uma alteração incremental e testes que exercitem os limites do comportamento.

O último passo seria revisar o diff como se tivesse sido escrito por qualquer integrante da equipe. Código gerado não deve ter um caminho privilegiado até a produção.

O agente pode acelerar a execução. O critério de aceitação não deve acelerar na mesma proporção.

O que muda no trabalho de quem revisa código

Durante muito tempo, o code review também foi uma oportunidade de ensinar padrões, discutir alternativas e compartilhar contexto. Isso continua valendo, mas a escala muda quando um agente consegue produzir alterações em vários arquivos antes de uma pessoa terminar de ler o primeiro diff.

Minha preocupação não é que a IA escreva código ruim por definição. Pessoas também cometem erros. O risco é a equipe passar a medir produtividade pelo volume de alterações aceitas, sem reservar tempo para investigar suas consequências.

Para o desenvolvedor, isso exige saber formular hipóteses, questionar decisões e testar comportamentos. Para o tech lead, exige definir limites claros: o que pode ser delegado, quais mudanças precisam de revisão especializada e quando é melhor reduzir o escopo de um pull request. Para quem lidera engenharia, exige reconhecer que revisar bem é trabalho produtivo — não um atraso entre a implementação e o deploy.

Uma revisão feita às pressas pode parecer eficiente hoje e custar semanas de manutenção depois.

Cinco critérios antes de colocar agentes no fluxo de engenharia

Não começaria a adoção escolhendo a ferramenta mais impressionante. Começaria respondendo a cinco perguntas:

1. Contexto: o agente recebe requisitos, contratos, padrões e limites suficientes para trabalhar sem inventar regras?
2. Escopo: as tarefas são pequenas o bastante para que alguém consiga compreender o resultado e reverter uma mudança?
3. Verificação: existem testes, análise de segurança e critérios de aceitação independentes da resposta gerada?
4. Responsabilidade: está claro quem decide, aprova e responde pela alteração em produção?
5. Aprendizado: a equipe registra falhas recorrentes e transforma essas descobertas em padrões, documentação e melhoria do processo?

Se uma dessas respostas for vaga, eu trataria a adoção como um experimento controlado, não como um novo padrão obrigatório para toda a empresa.

O papel da liderança e da capacitação

A mudança não se resolve com uma palestra sobre prompts ou com a instalação de um assistente no editor. É preciso ensinar a equipe a identificar uma boa decisão técnica, reconhecer uma resposta plausível porém incorreta e discutir os trade-offs de uma implementação.

Isso passa por exemplos reais do sistema, revisões colaborativas, critérios de segurança e espaço para questionar o resultado. Um profissional menos experiente pode usar agentes para aprender, desde que não seja pressionado a aprovar mudanças que ainda não consegue explicar.

Acredito que a mentoria técnica ganha relevância nesse cenário: não para ensinar pessoas a competir com a velocidade da máquina, mas para desenvolver repertório, autonomia e capacidade de julgamento.

Quando essa abordagem não é necessária

Nem toda linha precisa virar uma cerimônia arquitetural. Um protótipo descartável, um script isolado ou uma prova de conceito admitem verificações mais leves. O esforço de revisão precisa ser proporcional ao impacto, à exposição dos dados e ao custo de reversão.

O risco aumenta quando a alteração envolve dinheiro, identidade, permissões, dados sensíveis, integrações externas ou contratos difíceis de migrar. Nesses casos, trabalhar em etapas costuma ser mais seguro do que aceitar uma grande mudança opaca.

Um checklist antes do merge

• Eu consigo explicar o comportamento sem repetir o texto do agente?
• Os contratos e as regras de autorização permanecem explícitos?
• Os testes representam o problema real, inclusive falhas e limites?
• A nova dependência é necessária e sustentável?
• Há observabilidade suficiente para identificar regressões?
• Existe um caminho razoável para reverter?

IA é ferramenta de engenharia. Ela pode ampliar nossa capacidade de execução, mas não substitui entendimento, responsabilidade e manutenção. O objetivo não é produzir mais código. É construir um sistema que outras pessoas consigam evoluir.

Se a sua equipe está começando a usar agentes ou já percebeu que o volume de pull requests cresceu mais rápido que a capacidade de revisão, vale discutir o processo antes de simplesmente adicionar outra ferramenta. Trabalho com arquitetura de software, IA aplicada e mentoria para ajudar equipes a transformar essa adoção em decisões sustentáveis.

A pergunta não é apenas quem escreveu o código. É quem consegue explicar, validar e manter o que foi entregue.