A IA pode escrever o código. Não pode responder por ele.

Os agentes de programação mudaram a economia de escrever software mais rápido do que a maioria das equipes mudou sua forma de trabalhar. O resultado é previsível: mais código, mais cedo, com o mesmo número de pessoas responsáveis por saber se está correto. Algumas equipes entregam melhor do que nunca. Outras acumulam um novo tipo de dívida técnica —código que ninguém da equipe leu por inteiro— e só descobrirão daqui a um ano.

A diferença não é qual modelo usam. É se mantiveram a disciplina que o modelo não pode fornecer.

O modelo é rápido e erra com convicção

Um agente escreverá uma função, seus testes e uma mensagem de commit no tempo que leva para descrevê-los. Também inventará uma API que não existe, satisfará o teste que escreveu em vez do comportamento que você pretendia e ampliará silenciosamente o escopo de uma mudança porque a instrução era vaga. Nada disso é motivo para não usá-lo. É o motivo pelo qual o processo ao redor dele importa mais do que antes, não menos.

Uma forma útil de pensar nisso: o agente é o engenheiro júnior mais produtivo com quem você já trabalhou, e nunca se tornará sênior sozinho. Tudo o que uma boa equipe faz para tornar seguro o trabalho de um júnior —instruções claras, revisão, testes, uma pessoa que aprova— é exatamente o que torna seguro o trabalho de um agente.

O que se mantém

A especificação vem primeiro e fica no repositório. A maior alavanca é a qualidade das instruções. "Adicione exportação para CSV" produz um palpite; uma especificação escrita com os estados, os casos de borda e o significado de "concluído" produz a funcionalidade. Escrever essa especificação é a habilidade difícil que a maioria das equipes pula, e os agentes tornam essa omissão cara. Mantenha-a versionada junto ao código para que a intenção e a implementação sejam revisadas juntas.

Cada linha é lida. Não examinada rapidamente pelo estilo: lida pelo que faz. A revisão detecta a API inventada, o teste que não testa nada, a mudança que mexeu em um arquivo sem motivo para isso. Se o volume de código gerado torna impossível a revisão completa, a resposta são mudanças menores, não revisões mais leves.

Os testes são o contrato, então uma pessoa escreve o que eles verificam. Agentes são excelentes em montar a estrutura dos testes e péssimos em decidir o que significa estar correto. Deixe o agente gerar os casos; uma pessoa decide o que a funcionalidade deve e não deve fazer e rejeita testes que apenas espelham a implementação.

Os controles verificam antes de qualquer entrega. Verificações de tipos, linters, a suíte de testes, análise de segurança e uma verificação de que a mudança permanece dentro do escopo declarado: são executados automaticamente a cada mudança, em CI, antes de uma pessoa dedicar sua atenção. Um controle que só roda na máquina do desenvolvedor é uma sugestão.

Observabilidade desde a primeira versão. Se uma mudança escrita por um agente se comportar mal em produção, você precisa ver isso naquele dia, não na retrospectiva trimestral. Logs, rastreamento de erros e um caminho de qualquer resultado até a mudança que o causou.

Verificações de licença e procedência. O código gerado pode reproduzir trechos licenciados. Procure isso como procura vulnerabilidades e trate como a mesma classe de problema.

Um nome em cada entrega. O agente não decide. Um engenheiro decide e responde pelo que foi entregue, como sempre. Essa é a regra que sustenta as outras: quando uma pessoa precisa responder pela entrega, a especificação é escrita, a revisão é feita e o teste é lido.

Como isso funciona na prática

A intenção se torna uma especificação no git. Um agente constrói a partir dela, em uma branch, com os testes cuja estrutura montou e os que uma pessoa escreveu. Os controles são executados. Um engenheiro sênior revisa a mudança em relação à especificação, não apenas ao diff. A versão é entregue com o nome desse engenheiro, de forma aberta, onde o cliente pode ver cada commit. Para trabalhos em que o código e os dados do cliente não podem sair de um ambiente controlado, os agentes rodam em nossa própria plataforma de inferência, construída internamente, em vez de uma API de terceiros. Com o tempo, os tipos de mudança que o agente acerta deixam de precisar de revisão linha por linha, e os que ainda surpreendem você a mantêm. A autonomia é conquistada por tipo de mudança, nunca concedida de forma geral.

Nada disso é novo. É o que boas equipes de engenharia já faziam, aplicado a um colaborador que digita mais rápido do que qualquer um deles. As equipes que mais aproveitam a IA não são as que mais confiaram nela. São as que nunca deixaram de verificar.