ia
engenharia de software
lições aprendidas
O Que Construir Software de Verdade com IA Realmente Me Ensinou
Dez coisas que um ano colocando em produção código escrito por IA realmente me ensinou, sem o hype.
Passei os últimos meses colocando em produção código escrito, em sua maior parte, por uma IA. Eu lia cada mudança e assinava embaixo de cada linha. Aqui está o que isso realmente me ensinou, a parte que não aparece em nenhuma demonstração.
Confiança Não É Sinal de Verdade
A IA vai te dizer que um segredo vazou no histórico do git com a mesma voz que usa para dizer que o céu é azul. Calma. Segura. Impassível. Só uma dessas duas afirmações precisa de verificação. Verifique as duas de qualquer jeito.
“O primeiro princípio é que você não deve enganar a si mesmo, e você é a pessoa mais fácil de enganar.”
— Richard Feynman
Corrija Cada Erro Uma Única Vez, por Escrito
Se você pegar o modelo cometendo o mesmo erro duas vezes, a correção que você fez da primeira vez não serviu para nada. Ele não tem memória de uma tarefa para a outra, exceto pelo que você realmente registra em algum lugar: uma regra, um comentário, um documento curto que ele lê antes de começar. Se a correção fica só na sua cabeça, ele vai repetir o mesmo erro no próximo arquivo, e no seguinte.
“Existir” Não É o Mesmo Que “Funcionar”
Peça para ele construir uma funcionalidade e ele vai dar o trabalho como concluído assim que o código compilar e a função estiver ali. Não quando algo realmente a usa. Certa vez pedi uma função de verificação de status que parecia completa em todos os sentidos. Nenhuma outra parte do sistema jamais a chamou. Ninguém percebeu por semanas.
Dois Agentes, Duas Histórias
Coloque duas sessões de IA para trabalhar no mesmo código e elas vão se contradizer. Não por má intenção, por pura ignorância: nenhuma sabe o que a outra decidiu dez minutos atrás em outra janela. Alguém precisa se sentar e ler as duas mudanças.
O Bug Vive na Costura
O campo no banco de dados foi entregue, e funciona. O toggle na interface foi entregue, e funciona. Ninguém construiu o que esse toggle deveria ligar. Três checkmarks verdes, uma funcionalidade morta. Os piores bugs quase nunca estão dentro de uma única tarefa. Vivem na passagem entre duas tarefas que, cada uma isoladamente, pareciam prontas.
Passar em um Teste Não É Sobreviver em Produção
Código que funciona agora e código que sobrevive três dias em produção não são o mesmo código.
Nada em uma suíte de testes roda tempo suficiente para pegar um vazamento de memória. Você descobre esses do jeito difícil, às duas da manhã, ou descobre a tempo porque já se queimou uma vez antes e sabe exatamente quais padrões procurar: a conexão que nunca fecha, o cache que nunca limpa.
Ter uma Chave Não Significa que Toda Porta Abre
A brecha de segurança mais comum que encontrei em código escrito por IA nunca foi “quem é você.” Essa pergunta quase sempre é feita. A que fica de fora é “você tem permissão para mexer nisso especificamente.” As primeiras versões deixam isso de fora, sempre.
“Segurança é um processo, não um produto.”
— Bruce Schneier
Um Linter É um Estagiário, Não um Juiz
Ele sinalizou código perfeitamente correto só porque a forma dele pareceu estranha para uma máquina que não faz ideia de por que você escreveu daquele jeito. Na engenharia de software existe um nome para o erro mais profundo aqui: a Cerca de Chesterton, o hábito de derrubar algo antes de entender por que foi colocado ali. Entenda o código primeiro. Obedeça a ferramenta depois, se for o caso.
Plausível Não É Correto
Strings de protocolo, chaves de configuração, formatos de data: compilam, leem bem, e às vezes estão simplesmente errados, porque a IA copiou a forma geral de especificações parecidas em vez da exata que você precisa. Confira contra a documentação real. Não contra o quão limpo o código parece.
O Bug Mais Barato É Aquele Que Você Nunca Chega a Escrever
Todo erro caro que vi acontecer remontava a uma decisão que ninguém disse em voz alta no início: uma suposição sobre escopo, formato ou responsabilidade que cada um interpretou à sua maneira, em silêncio.
“A parte mais difícil de construir um sistema de software é decidir com precisão o que construir.”
— Fred Brooks, No Silver Bullet
Perguntar primeiro parece lento. Ainda assim é a jogada mais barata do tabuleiro. Todas essas lições se resumem à mesma instrução: vá mais devagar bem no momento em que a máquina soa mais segura de si mesma.