Código gerado por IA entrou no pipeline de desenvolvimento — e a revisão de segurança não acompanhou

Assistente de código por IA deixou de ser experimento de produtividade e virou parte normal do fluxo de trabalho em boa parte das equipes de engenharia — sugerindo função inteira, gerando teste, escrevendo integração com API em segundos. O volume de código que entra no pipeline cresceu de forma real e mensurável. O que não cresceu na mesma proporção, na maioria das empresas, foi a capacidade de revisar esse código com critério de segurança.

Isso não é um problema sobre se IA deveria ou não escrever código — essa decisão já foi tomada, de forma distribuída, por milhares de desenvolvedores. É sobre o que acontece no intervalo entre geração instantânea e revisão humana que continua no ritmo de antes.

Código gerado não é código revisado

Código produzido por IA costuma parecer limpo, idiomático, e passa em teste funcional básico sem esforço — o que cria uma falsa sensação de que também é seguro. O modelo otimiza pra código que funciona, não pra código que resiste a ataque, e pode reproduzir padrão inseguro presente no próprio material de treinamento — concatenação de string em consulta de banco, validação de entrada ausente, segredo em texto plano como placeholder que acaba indo pro commit real — com a mesma fluência sintática de um padrão seguro.

A diferença entre os dois só aparece sob revisão de verdade, e é exatamente aí que o gargalo se formou.

Volume quebra o modelo de revisão manual

Quando um desenvolvedor escreve 50 linhas à mão, revisar 50 linhas é proporcional. Quando um assistente de IA propõe 500 linhas num único pull request, porque gerar é quase instantâneo, a capacidade de revisão não escala junto — o time ou desacelera a entrega, criando atrito, ou aprova por confiança, assumindo risco silencioso. Esse descompasso de volume é parte do mesmo problema mais amplo de superfície de supply chain de software que cresce mais rápido do que o monitoramento.

Ferramenta de SAST tradicional não foi calibrada pra esse padrão

Análise estática de código foi desenhada pensando no ritmo e no padrão de erro de código escrito por humano — e código gerado por IA costuma ter uma característica específica que escapa dessa calibração: parece correto o suficiente, sintaticamente, pra não disparar alerta que um padrão obviamente malformado dispararia. Ajustar regra de SAST e processo de revisão especificamente pra esse tipo de entrada deixou de ser otimização e virou necessidade básica.

Prompt carrega intenção, não responsabilidade de segurança

A pessoa que pede "escreve uma função de login" raramente especifica resistência a ataque de timing ou limite de taxa de tentativa — não porque não se importa, mas porque requisito de segurança raramente é o que vem à mente ao descrever intenção funcional. Isso vale também pra identidade de máquina e credencial usada no próprio pipeline de CI/CD, que cresce em volume junto com a automação gerada por IA. Esperar que o modelo infira esse requisito sozinho é aposta ruim — ele precisa estar explícito em política e guardrail, não implícito na esperança de que o assistente adivinhe certo.

Gerar rápido não é o mesmo que gerar seguro

Assistente de código por IA já faz parte do fluxo de engenharia pra ficar — a pergunta que resta é se a revisão de segurança escala junto ou fica pra trás. A UNIQ ajuda equipes de tecnologia a calibrar esse processo, como parte da mesma governança de uso de IA que já deveria cobrir toda ferramenta de IA generativa na empresa. Fale com o time técnico antes que o volume de código gerado ultrapasse de vez a capacidade real de revisar.