IA no workflow de engenharia — o que mudou de verdade no meu dia a dia depois de 1 ano usando
Depois de um ano usando ferramentas de IA no trabalho de engenharia, aqui está uma avaliação honesta: o que mudou, o que não mudou, e onde eu ainda erro.
Comecei a usar ferramentas de IA no trabalho de engenharia quando eram novidade. Continuo usando. Mas o que eu uso, como uso, e o que espero delas mudou bastante em um ano.
O que melhorou mais: escrita de código boilerplate. Quando preciso criar um novo serviço com uma estrutura padrão, gerar testes para uma função com múltiplos casos de borda, ou escrever configuração repetitiva de infraestrutura, IA acelera de forma significativa. Não porque o código é difícil — é porque é tedioso, e tédio consome atenção que poderia ir para o problema real.
O que não melhorou como eu esperava: decisões de arquitetura. Quando o problema é genuinamente ambíguo — múltiplas abordagens viáveis com trade-offs que dependem de contexto específico da empresa, do time, dos sistemas existentes — IA gera opções, mas a avaliação de qual é melhor ainda exige julgamento que é difícil de delegar.
Um padrão que aprendi a reconhecer: quando IA dá resposta com muita confiança sobre algo que eu sei ser complicado, desconfio. O modelo não sabe o que não sabe — não tem incerteza bem calibrada. Em engenharia, saber quando não saber é tão importante quanto saber.
Isso não é crítica. É característica que você precisa entender para usar a ferramenta de forma eficaz.
O que mais mudou no meu workflow não foi velocidade de escrita de código. Foi velocidade de exploração. Quando preciso entender um sistema que não conheço, uma API que nunca usei, um padrão de design que vejo pela primeira vez — conversa com IA acelera o processo de formular as perguntas certas. Não é que as respostas sejam sempre corretas — às vezes não são. É que o processo de checar se a resposta está correta me força a entender o suficiente para avaliar.
Paradoxalmente, usar IA às vezes me faz aprender mais rápido do que não usar — porque o processo de verificar a saída é ativo, não passivo.
O risco que vejo mais nos times que adotam IA sem reflexão: aceitação de código que parece certo mas não está. IA gera código plausível. Código plausível que não foi lido com atenção vai para PR, passa por review distraído, entra em produção, e causa incidente em produção.
A velocidade extra de escrita não vale nada se o código resultante tem qualidade menor. O bar de revisão precisa subir, não cair, quando IA está na equação.
O que eu diria para alguém começando: use IA como colaborador de primeiro rascunho, não como oráculo. Primeiro rascunho é para ser revisado, questionado, melhorado. Oráculo é para ser seguido. Código de IA é primeiro rascunho — às vezes muito bom, às vezes com problemas sutis que só aparecem quando você entende o problema profundamente o suficiente para identificá-los.
Essa distinção muda como você usa a ferramenta. Você mantém o julgamento ativo. Você não delega a decisão — você delega a geração de opções.
Onde eu ainda erro: quando estou com pressa e aceito output de IA sem verificação suficiente. Pressa é o estado em que mais propenso a cometer esse erro. É exatamente quando você não deveria confiar no primeiro rascunho sem revisão — porque é quando a penalidade de erro em produção é maior.
Esse padrão não é específico de IA. É como funciona qualquer ferramenta que acelera sem exigir que você desacelere para verificar.
Essa semana: se você usa IA para escrever código, pega o último trecho gerado que você usou em produção e lê linha por linha com atenção. Não para encontrar bug necessariamente — mas para verificar se você entende o que cada linha está fazendo e por quê. Se encontrar algo que não entende, esse é o ponto de aprendizado.