Engenharia de software com IA: como garantir qualidade, segurança e rastreabilidade quando parte do código não é escrito por humano

Código gerado por IA passa no review, vai para produção e quebra meses depois. É um cenário comum de acontecer. O problema aqui não é a IA errar, mas sim tratar engenharia de software com IA como um atalho, e não como uma disciplina.

Copilot, Cursor, Claude Code: a ferramenta pode mudar, porém o risco continua. Sem um critério de aceitação explícito, qualidade, segurança e rastreabilidade viram aposta, deixando a engenharia de lado.

Neste artigo, você encontra o que muda no code review, os vetores de segurança que a IA introduz e como estruturar rastreabilidade dentro da engenharia de software com IA. Boa leitura.

O problema real: código gerado por IA não é código revisado por IA

O modelo que gera o código não garante, sozinho, que ele está correto, seguro ou alinhado com a arquitetura do projeto: gerar código plausível é o que o modelo faz bem; validar que ele está certo continua sendo trabalho de outro processo, com outro critério. É por isso que a validação não vira opcional só porque a geração ficou mais rápida. Engenharia de software com IA exige tratar geração e validação como duas etapas distintas, com donos e critérios próprios.

Times que tratam os dois como uma coisa só criam um ponto cego previsível: o reviewer humano começa a confiar no volume de código que passa, não na qualidade dele. Um pull request de 400 linhas gerado por IA em minutos recebe o mesmo tempo de revisão que um PR de 40 linhas escrito à mão, e a atenção por linha despenca exatamente onde o risco é maior.

O efeito já aparece nos números. Um estudo da GitClear que analisou 211 milhões de linhas de código entre 2020 e 2024 encontrou o code churn (código reescrito em até duas semanas após ser criado) dobrando, de 3,05% para 6,87%, enquanto a proporção de código refatorado caiu de cerca de 25% para menos de 10% no mesmo período, com o volume de código duplicado crescendo oito vezes em 2024. É a assinatura de times que geram rápido e revisam devagar.

Qualidade: o que muda no processo de revisão quando a engenharia de software com IA entra no workflow

Fazer code review com IA sem redesenhar o critério de aceitação é aplicar engenharia de software com IA como se fosse a engenharia de software de sempre, só que mais rápida. O tipo de erro muda: um dev júnior erra por falta de conhecimento; o modelo erra por padrão estatístico plausível, que parece certo, compila, passa em teste superficial e falha na borda que ninguém testou. Por isso, é importante ter no processo de revisão:

• Critério de aceitação específico: código gerado por IA precisa de checklist próprio: a mesma exigência de complexidade ciclomática, cobertura de teste e aderência à arquitetura que se aplicaria a qualquer código novo, mais verificação explícita de que a lógica de negócio foi entendida, não só reproduzida. 

• Static analysis como portão, não como opcional: linting, análise estática (SAST) e cobertura de testes não são substituídos pela IA. São reforçados por ela, rodando em cada PR, humano ou gerado, antes do review humano começar. 

• Atenção por linha proporcional ao risco: o tempo de revisão precisa ser proporcional ao risco da mudança, não ao esforço de quem escreveu. Um PR gerado em três minutos pode exigir trinta minutos de revisão se tocar autenticação, pagamento ou dado sensível. 

• Confiança calibrada: o maior risco de qualidade é aquele código que é plausível. Revisar com menos atenção porque "a IA fez e parece certo" é o erro mais caro dessa transição. 

Nenhuma dessas mudanças é sobre desconfiar da ferramenta. A questão é redesenhar o processo de code review com IA para o tipo de erro que ela de fato produz: silencioso, plausível e concentrado nas bordas do sistema que o time menos testa.

Segurança: os vetores de risco que a IA introduz no código

Segurança em engenharia de software com IA está relacionada a superfície de ataque nova que ele cria quando entra em runtime. Duas classes de risco importam aqui: o que a IA gera de errado, e o que a IA permite que outros explorem depois, e essas classes se dividem nos seguintes problemas:

• Vulnerabilidades no código gerado: modelos de geração reproduzem os padrões inseguros presentes na base em que foram treinados: SQL injection por concatenação de string, XSS por template literal sem escape, uso inseguro de eval(). São erros conhecidos, que um linter ou uma revisão atenta pega, mas que passam quando ninguém está olhando com o rigor certo. 

• Dependências alucinadas: modelos de geração de código podem sugerir nomes de pacotes que simplesmente não existem. Atacantes que monitoram esse comportamento registram esses nomes alucinados em repositórios públicos antes que alguém perceba o erro, o chamado slopsquatting, e o pacote malicioso entra no projeto como se fosse dependência legítima. 

• Prompt injection como superfície de ataque: em sistemas que usam IA em runtime (agentes e assistentes com acesso a ferramentas), entradas manipuladas, diretas ou indiretas, podem alterar o comportamento do modelo e disparar ações não autorizadas em sistemas conectados. É hoje um dos riscos mais citados por frameworks de segurança voltados a aplicações com LLM. 

• Proveniência de dependência: toda biblioteca sugerida por IA precisa da mesma verificação de proveniência que qualquer dependência nova: manutenção ativa, histórico de releases, presença em SBOM, antes de entrar no lockfile. 

SAST e DAST continuam obrigatórios e agora precisam cobrir explicitamente o que a IA produziu, não como camada extra, mas como parte inegociável do workflow. O time que trata isso como responsabilidade de uma ferramenta externa é o time que descobre o vetor de risco em produção.

Rastreabilidade: como documentar e auditar código dentro da engenharia de software com IA

Rastreabilidade em engenharia de software com IA vai além de comentar o código ou registrar o autor no commit. Envolve reconstruir, meses depois, a cadeia completa de decisão: qual prompt gerou qual trecho, qual versão de modelo foi usada, qual contexto foi fornecido e qual humano aprovou aquilo antes do merge. Ter essa visibilidade demanda:

• Registro de prompt e contexto: o prompt que gerou uma função crítica deveria ser tão rastreável quanto o autor de um commit, versionado, vinculado ao PR, recuperável em auditoria. 

• Versão do modelo: modelos podem mudar de comportamento entre versões sem mudanças visíveis no contrato de API; saber qual versão gerou qual trecho é pré-requisito para reproduzir ou investigar um bug meses depois. 

• Decisão humana registrada: quem aprovou o PR precisa constar como decisão consciente, não como carimbo. Em ambientes regulados, essa distinção já é auditada linha a linha. 

• Sem burocracia: rastreabilidade não é formulário manual. É metadado automático capturado no próprio pipeline (commit, PR, CI) que o time já usa, agora também registrando a origem do código gerado. 

Em setores regulados, fintech, saúde, jurídico, esse nível de rastreabilidade já é exigência, não diferencial: reguladores e auditores esperam explicar por que uma decisão de sistema aconteceu, mesmo quando parte da lógica nasceu de um prompt. Para os demais setores, é questão de tempo até isso virar exigência contratual de cliente enterprise.

Leia também: Como a Lughy usa IA para desenvolvimento de software com segurança, criticidade e foco em qualidade

O que um processo maduro de engenharia de software com IA parece na prática

Em um processo maduro, o modelo entra no ciclo como acelerador de execução, nunca como substituto de critério técnico. A pergunta que times maduros respondem antes de qualquer prompt não é "a IA consegue gerar isso?": é "quem decide se isso está certo?".

Existe território onde a IA contribui sem revisão intensa, como testes unitários repetitivos e boilerplate. Existe território onde o humano revisa obrigatoriamente: lógica de negócio, autenticação e qualquer código que toque dinheiro ou dado pessoal. E existe território onde a IA simplesmente não entra: decisões de arquitetura e definição de contrato de API entre serviços, que exigem contexto de negócio que nenhum prompt carrega sozinho.

É essa lógica que a Lughy segue internamente: engenharia de software com IA não é decisão de ferramenta, é decisão de processo, e o processo precisa existir antes do primeiro prompt ser escrito, não depois do primeiro incidente em produção.

Engenharia de software com IA responsável não é mais lenta: é mais previsível. O tempo que parece "perdido" em critério de aceitação, code review com IA mais rigoroso e rastreabilidade estruturada é o mesmo tempo que não vira incidente, rollback ou auditoria emergencial seis meses depois. Se você quer entender como a Lughy estrutura esse processo no dia a dia de desenvolvimento de software, critério de aceitação, segurança e rastreabilidade incluídos, fale com o time.