Um time de backend com quem conversei no fim do ano passado tinha adotado Copilot e Cursor como parte padrão do fluxo, com ganho reportado de trinta a quarenta por cento na entrega de endpoints novos. Seis meses depois, uma auditoria encontrou três handlers de autenticação que validavam tokens JWT sem verificar a assinatura, confiando só na decodificação do payload. Os três foram gerados por assistente em momentos distintos por desenvolvedores diferentes, com prompts parecidos. Nenhum deles sabia explicar por que a verificação foi omitida, porque nenhum escreveu aquele código linha a linha. Na minha avaliação, a leitura mais desconfortável pra liderança foi que o padrão não era isolado: o mesmo antipattern aparecia em código humano anterior à adoção das ferramentas, só que numa frequência menor.
O comportamento é consistente entre times que adotam assistente sem ajustar o pipeline de revisão. O modelo generativo reproduz o corpus de treinamento, que contém a média do código público dos últimos vinte anos, com todas as vulnerabilidades recorrentes. O estudo de Pearce et al. na NYU ("Asleep at the Keyboard?", 2021) avaliou sugestões do Copilot em cenários do MITRE CWE Top 25 e encontrou cerca de quarenta por cento de código inseguro. Pesquisas posteriores em Stanford e Purdue convergem nas mesmas categorias: injection, autenticação quebrada, criptografia mal configurada e desserialização insegura, o que domina o OWASP Top 10 há mais de uma década.
Pra mim, a tese operacional é que código gerado por IA não introduz classes inéditas de vulnerabilidade. Reintroduz as antigas numa velocidade maior, com sintaxe mais limpa, o que reduz o atrito do revisor e aumenta a probabilidade de aprovação em pull request. O problema é o gerador produzir código que parece bom o suficiente pra passar numa revisão superficial, deslocando o ponto de falha do desenvolvimento pra revisão. Quando o revisor opera no mesmo modo cognitivo de antes, avaliando intenção e legibilidade, perde o sinal que vinha do desconforto de ler código mal estruturado. O desenvolvedor aceita o bloco gerado sem reconstruir o modelo mental, e a justificativa em revisão passa a ser "o assistente sugeriu assim e funcionou nos testes".
O trade-off é real e não se resolve proibindo a ferramenta. A proibição elimina o ganho de velocidade sem eliminar o risco, porque os mesmos desenvolvedores continuam escrevendo os mesmos antipatterns manualmente. Na minha análise, a mitigação efetiva passa por tratar o assistente como parte da cadeia de suprimentos de código, sujeito às exigências aplicáveis a fornecedores externos sob o Anexo A.5.21 e A.8.30 da ISO 27001:2022. A lógica é direta: se o código chega ao repositório produzido por um terceiro, as obrigações contratuais e de revisão de desenvolvimento terceirizado incidem sobre ele, seja o terceiro uma software house ou um modelo generativo.
A prática concreta é deslocar a revisão de segurança pra controles automatizados que operam antes do revisor humano, porque a taxa de geração ultrapassou a capacidade de revisão manual. O primeiro controle é análise estática no IDE e no pipeline, com regras calibradas pras categorias que dominam o risco: criptografia depreciada, queries por concatenação, desserialização de input não confiável, validação de JWT sem assinatura, hardcoding de secrets. Semgrep, CodeQL e SonarQube cobrem essas classes com regras públicas, e a diferença operacional está em tratar os findings como bloqueadores de merge. O segundo controle combina SCA e teste dinâmico: validar bibliotecas contra CVEs e política de licenciamento, e rodar DAST em staging focando endpoints recém-criados.
O ajuste cultural é mais difícil que o técnico. Quem usa assistente com fluência precisa operar em dois modos: aceitação rápida pra código de baixo risco, e reconstrução ativa do modelo mental pra código que toca autenticação, criptografia ou dados pessoais. A auditoria passa a verificar não só o código, mas o processo de aceitação da sugestão, e isso exige que o time documente quais categorias exigem revisão reforçada. A ISO 27001 não prescreve essa distinção, mas o Anexo A.8.28 sobre codificação segura exige código seguro de forma demonstrável, e demonstrabilidade no fluxo assistido depende de rastreabilidade da decisão.
O ângulo que pra mim raramente entra na discussão técnica é a responsabilidade jurídica quando código gerado por assistente causa falha em produção. A cadeia de imputação é ambígua por desenho: o desenvolvedor não escreveu o código linha a linha, e o fornecedor do modelo não garante correção funcional. Em jurisdições com regimes de responsabilidade civil por produto digital, como a Diretiva de Responsabilidade por IA da União Europeia, a ausência de rastreabilidade entre sugestão aceita e decisão humana pode transformar uma falha corrigível em exposição regulatória concreta. Na prática, a responsabilidade recai sobre quem colocou o código em produção, e isso torna a rastreabilidade não só boa prática de engenharia, mas exigência de proteção jurídica.
O efeito de segunda ordem, já observável em times que adotaram assistente há mais de um ano, é a erosão da competência de base. Quem aprendeu a programar com assistente presente desde o início tem dificuldade crescente em auditar código gerado, porque lhe falta o repertório pra identificar o que está errado em algo que parece correto. A próxima geração de revisores será treinada pelo mesmo corpus que treina o assistente, e a detecção das vulnerabilidades antigas dependerá cada vez mais de automação, não de julgamento. A auditoria deixa de ser controle complementar e passa a ser a linha primária de defesa contra padrões que o próprio time já não reconhece como problemáticos.