Num dos meus projetos, precisei construir um gateway que traduz chamadas REST/JSON modernas para o formato XML/SOAP que um ERP legado espera. É o tipo de trabalho que envolve muito boilerplate: parsing de XML, geração de envelope SOAP, mapeamento de campo por campo. Usei um assistente de IA para acelerar boa parte disso. Funcionou bem, mas não do jeito que a propaganda de "IA escreve seu código sozinha" sugere.
Onde a IA acelerou de verdade
Gerar o cliente SOAP inicial com uma biblioteca como zeep, escrever os testes repetitivos de serialização de cada campo, montar o esqueleto de validação de schema: tudo isso a IA fez rápido e bem. É trabalho mecânico, bem documentado publicamente, sem ambiguidade de negócio. Nessa parte, o ganho de velocidade foi real, provavelmente cortei uns dois dias de trabalho braçal.
Os três erros que só peguei porque conhecia o domínio
O problema aparece na parte que exige contexto que não está em nenhuma documentação pública. Três exemplos concretos:
1. Formato de data
A IA assumiu, sem perguntar, que o campo de data deveria ir em ISO 8601 (2026-08-20). O webservice legado espera AAAAMMDD sem separador. O código compilava, os testes unitários passavam (porque os testes também foram gerados com a mesma suposição errada), e só quebraria em produção com uma mensagem de erro genérica do lado do ERP.
2. Exceção de timeout engolida
No tratamento de erro, a IA gerou um bloco genérico de try/except que capturava qualquer exceção e retornava uma resposta de "sucesso parcial" para não quebrar o fluxo do chamador. Isso incluía timeouts de rede reais. Ou seja: uma falha de conexão de verdade seria reportada como sucesso. Esse é o tipo de bug que não aparece em teste, só em produção, silenciosamente, até alguém notar que dados sumiram.
3. Paralelismo que o webservice não aguenta
Pedi para otimizar a performance, e a sugestão foi paralelizar as chamadas SOAP com um pool de conexões. Parece razoável, é a otimização óbvia. O problema é que o webservice legado do outro lado processa uma fila internamente e trava com múltiplas conexões simultâneas do mesmo usuário. Isso teria causado esgotamento de conexão em produção, um efeito colateral que só faz sentido pra quem já leu (ou sofreu com) a documentação de limitação desse ERP especificamente.
Nenhum dos três é um "bug de código" no sentido tradicional. É código sintaticamente correto, bem estruturado, que passa em teste unitário e ainda assim está errado, porque a IA não tem (e não pode ter) o contexto de negócio específico de um sistema legado com trinta anos de decisões arbitrárias acumuladas.
O que ficou comigo dessa experiência
A conclusão não é "não use IA para escrever integrações". É que a habilidade que mais importa mudou de lugar. Antes, boa parte do valor estava em escrever o código. Hoje, está em saber exatamente onde revisar com desconfiança: nos pontos de contato com sistemas legados, no tratamento de erro, e em qualquer suposição implícita sobre formato de dado que ninguém documentou.
Uso IA para acelerar a parte mecânica todos os dias. Mas cada linha que toca uma regra de negócio específica do ERP, eu leio como se tivesse sido escrita por um estagiário talentoso que nunca trabalhou com aquele sistema: provavelmente está bem escrita, e ainda assim pode estar sutilmente errada.