IA não substitui engenharia: código gerado pode acelerar uma tarefa, mas não decide sozinho limites, dependências, segurança ou manutenção. Sem arquitetura e revisão, a velocidade inicial pode apenas transformar decisões frágeis em passivo técnico.

IA não substitui engenharia porque contexto vem antes do código

Um modelo pode sugerir uma função, uma rota de API ou uma consulta. Ele não conhece, por conta própria, a regra de negócio que não está documentada, a tolerância a falhas da operação, o contrato com sistemas existentes ou o custo de manter aquela decisão.

Considere uma solicitação para “criar o endpoint de pagamento”. Uma resposta plausível pode tratar o caminho feliz, mas deixar em aberto autorização, idempotência, conciliação, reprocessamento e registro de eventos. O código pode compilar e ainda assim não estar pronto para o produto.

Essa é a diferença entre gerar código e fazer engenharia: engenharia explicita contexto, escolhe limites, avalia riscos e decide como a mudança convive com o que já existe. O relatório DORA de 2025 trata a adoção bem-sucedida de IA como um problema sistêmico, que envolve capacidades organizacionais e gestão do fluxo.

O passivo aparece nas conexões que ninguém revisou

Arquitetura não é um desenho separado da implementação. Ela aparece em decisões como onde validar uma regra, quem pode acessar um dado, como uma falha será repetida e qual módulo pode depender de outro.

Quando cada pedido à IA é tratado como tarefa isolada, regras podem ser duplicadas, integrações podem ganhar comportamentos diferentes e a equipe passa a corrigir sintomas em pontos espalhados. A manutenção fica mais difícil porque o próximo desenvolvedor precisa reconstruir as premissas que não foram registradas.

Um exemplo concreto: uma aplicação calcula frete em uma tela e também em uma rotina de fechamento de pedido. Se a lógica for gerada separadamente, os dois caminhos podem divergir quando há cupom, alteração de endereço ou indisponibilidade do serviço externo. A questão não é se a IA escreveu o código; é se o produto tem uma regra única, um limite claro e testes que protejam esse comportamento.

Como usar IA sem terceirizar a responsabilidade

O uso responsável começa antes do prompt. A equipe precisa fornecer contexto suficiente, restringir a mudança e manter uma pessoa responsável por aceitar ou rejeitar a solução.

  • Defina o problema e os critérios: entrada, saída, regras, dependências, segurança e o que não pode mudar.
  • Peça uma mudança pequena e verificável; prefira alterações que possam ser lidas e revertidas.
  • Revise a solução contra a arquitetura existente: nomes, limites, tratamento de erros, autorização, dados sensíveis e observabilidade.
  • Execute testes relevantes e inclua casos de falha, não apenas o caminho feliz.
  • Registre a decisão e o motivo, para que a próxima evolução não dependa do histórico da conversa com o modelo.

A orientação SP 800-218A do NIST recomenda práticas, tarefas e considerações específicas para IA generativa ao longo de todo o ciclo de vida de desenvolvimento seguro, em conjunto com o SSDF. A IA entra no processo; não substitui esse processo.

O que revisar antes de colocar código gerado em produção

Antes de aprovar, faça perguntas que o código sozinho não responde:

  • Qual problema de produto esta mudança resolve?
  • Que parte da arquitetura ela altera e quais dependências cria?
  • Como o sistema se comporta com dados inválidos, repetição, indisponibilidade e permissões insuficientes?
  • Como a equipe vai detectar e corrigir uma falha depois da publicação?
  • Os testes demonstram o comportamento esperado ou apenas confirmam que a implementação atual executa?

A documentação do GitHub Copilot Chat alerta que código gerado pode conter vulnerabilidades ou erros e não refletir a intenção do desenvolvedor. Revisão humana, testes e práticas de código seguro continuam necessários quando a ferramenta participa da implementação.

Próximo passo: se o sistema está acumulando retrabalho, integrações frágeis ou decisões difíceis de manter, converse com a LYPES sobre o gargalo atual. A equipe pode ajudar a mapear prioridades e discutir a evolução mais adequada — por contrato de horas ou por escopo fechado, conforme o problema.