A inteligência artificial vai substituir os programadores?

TL;DR

IA generativa já substituiu tarefas que programadores faziam há cinco anos, mas arquitetura, responsabilidade e decisão de negócio permanecem humanas.

• Geração de código acelerou 10x, mas sem entendimento de contexto vira dívida técnica em velocidade.
• Testes gerados por IA têm cobertura alta e validação baixa — quem não revisa mergeia bug bonito.
• Documentação automática descreve o que o código parece fazer, não o que o sistema realmente faz.
• Erros sintáticos a IA acha; erros semânticos de regra fiscal exigem humano que já passou por obrigação acessória.
• Sistemas antigos sem documentação deixam a IA sem contexto — e quem operou o ERP em 2003 sabe onde ela desiste.
• Decisões arquiteturais exigem trade-offs que a IA não pesa porque não carrega a consequência da escolha.
• Quando código gerado por IA quebra em produção, quem responde não é o modelo — é o programador que aprovou o merge.
• ~ 8 min de leitura · ~ 1.700 palavras
• Se IA escreve código, testa, documenta e identifica erros — o que sobra para o programador? O que sobra é exatamente o que a IA não pode fazer: definir o problema, arquitetar a solução, e assinar com o nome a responsabilidade pelo resultado.

~ 8 min de leitura · 1349 palavras

Geração de código: velocidade sem entendimento

Em 2024 eu precisei migrar um módulo de nota fiscal do nosso ERP de 2003 para um serviço novo. O agente de IA gerou 80% da sintaxe em duas horas. O que eu teria levado três dias escrevendo manualmente, a IA entregou em tempo de café. O problema veio depois: o código compilava, os testes unitários passavam, mas o cálculo de base de PIS/COFINS estava errado em casos de transferência interestadual com redução de base.

A IA não sabia que a redução de base mudou em 2023 e que o sistema legado usava uma regra transitória que só existia em um memorando interno de 2019. Sintaxe é o que a IA domina. Contexto fiscal, regra de negócio escondida em documento que nunca virou código — isso ela não adivinha.

O ensinamento é simples: velocidade de geração não é velocidade de entrega. Código plausível é mais perigoso que código ruim, porque passa por todas as validações automáticas e explode onde ninguém está olhando.

Se você está usando IA para gerar código e ainda não definiu quem valida antes do merge, você não tem produtividade — tem dívida diferida.

Criação de testes: cobertura alta, validação baixa

A mesma IA que gerou o módulo fiscal propôs testes unitários com 94% de cobertura. Impressionante na métrica, inútil na prática: os testes validavam que a função retornava um número, não que o número era o correto segundo a legislação tributária. Cobertura de linha sem cobertura de regra de negócio é maquiagem para auditoria, não garantia de qualidade.

Eu já revisei suites de teste geradas por IA onde 60% das asserções eram tautológicas — verificavam que `true == true` embrulhado em uma função. Bonito no relatório, inútil na produção.

Testes que a IA escreve sozinha testam o que o código parece fazer, não o que o sistema deve fazer segundo quem entende o negócio. A barreira subiu: antes o programador precisava saber escrever teste. Agora precisa saber validar se o teste gerado testa a coisa certa.

Quando seu pipeline mostrar 90%+ de cobertura, a pergunta não é “quantas linhas cobrimos?”. É “quantas regras de negócio críticas esse teste realmente exercita?”.

Documentação automática: o que a IA descreve vs. o que o sistema realmente faz

Documentar código com IA é tentador. Ela lê o método, infer uma descrição, e produz texto legível em segundos. O problema é o mesmo da geração de código: a IA documenta o que vê, não o que o autor original quis dizer.

No nosso ERP de 2003, há um método chamado `CalculaImpostoRetido` que, pela assinatura, parece calcular ISS retido. Na verdade, ele também aplica uma exceção de inscrição municipal que só existe para um cliente específico de 2011, e o autor nunca renomeou o método quando adicionou a regra. IA que documenta por análise estática vai descrever “calcula ISS retido” e nunca vai mencionar a exceção que quebra o cálculo em 2% dos casos.

Documentação útil não descreve código. Documentação útil explica intenção, limitação, e o porquê de uma escolha que parece errada a quem não conhece a história. A IA não tem acesso à história.

Se a documentação do seu sistema não conta o que o código deveria fazer e por que desvia do óbvio, você tem descrição, não documentação.

Identificação de erros: padrão sintático vs. erro semântico

A IA encontra erros de sintaxe, variável não declarada, e race condition óbvios com eficiência que nenhum humano alcança. Erro de compilação a IA resolve antes de eu terminar de ler a mensagem. Mas erro semântico — aquele onde o código executa e produz resultado errado — é onde a IA tropeça.

Em um módulo de faturamento, a IA sugeriu uma otimização de query que reduziu o tempo de execução de 400ms para 30ms. Impressionante. Só que a query otimizada omitia uma condição de filtro de empresa que era obrigatória em multi-tenant. Em teste com dados de uma empresa só, funcionava. Em produção, expôs dados de cliente A para cliente B.

Erro sintático quebra o deploy. Erro semântico quebra o negócio. A primeira é inconveniente. A segunda é demissão.

A IA não pode revisar criticamente código que não compreende; portanto, não pode aceitar código que não compreende sem que essa aceitação seja, em si, ato de negligência.

Análise de sistemas antigos: onde a IA encontra e onde desiste

Migração de sistema legado é o teste definitivo de onde a IA para. Em 2023 eu liderei a migração de um ERP que cresceu desde 2003, passou por Clipper, Delphi, .NET Framework, e nunca teve um plano de modernização porque sempre havia uma feature mais urgente.

A IA conseguiu ler o código, inferir estruturas de dados, e sugerir mappings para o novo modelo. O que ela não conseguiu — e nunca vai conseguir sem contexto humano — foi entender por que uma tabela chamada `TEMP_MOVIMENTO` era, na verdade, a tabela mais importante do sistema, mantida com nome temporário por 18 anos porque ninguém teve coragem de renomear.

Sistemas antigos carregam decisões que só fazem sentido para quem viveu a época. A IA não tem memória institucional. Quem operou o ERP em 2003 sabe onde ela desiste.

Se você está modernizando legado e acha que IA vai substituir o entendimento do sistema, você vai preservar o código e destruir o comportamento.

Tomada de decisões arquiteturais: a linha que separa sugestão de comando

Arquitetura é escolha entre males conhecidos. Microserviço vs monolito, eventual consistency vs ACID, cache distribuído vs estado local — cada decisão carrega um custo que só aparece em escala, e a IA não paga o preço da escolha errada.

A IA sugere. Ela não arquiteta. Sugerir Kafka para event sourcing é fácil. Saber que o time tem dois devs, zero experiência com streaming, e um SLA de 99.9% que não tolera reprocessamento manual — isso é informação que a IA não tem.

Eu já recebi sugestões arquiteturais de IA que eram tecnicamente corretas e operacionalmente impossíveis. A IA não sabe que o cliente não renovou o contrato de infraestrutura, que o time vai perder um dev em 30 dias, ou que a regra de compliance exige audit trail em banco relacional, não em log de eventos.

Arquitetura é decisão sob incerteza com restrições que mudam semana a semana. Quem arquiteta carrega a consequência. A IA não carrega — por isso não arquiteta.

Responsabilidade sobre o código: quem responde quando a IA escreve e dá errado

Aqui chegamos na fronteira que não se discute o suficiente. Se uma IA generativa escreve código, testa, documenta, e o sistema quebra em produção — quem responde?

Não é o modelo. Os termos de serviço de todo provedor de IA descarregam responsabilidade. Não é a empresa que licenciou a ferramenta — ela vende produto, não assume risco operacional. Quem responde é o profissional que aprovou o merge, o tech lead que assinou o deploy, e a empresa que paga a indenização se houver dano ao cliente.

Eu opero ERPs para clientes que processam nota fiscal, movimentação fiscal, e dados sensíveis. Não existe “foi o Copilot” como resposta para auditoria. Não existe “a IA sugeriu” como defesa em processo de responsabilidade civil por vazamento de dados.

Responsabilidade não é gerada por prompt. Responsabilidade é assumida por quem entende o sistema o suficiente para dizer “este código está correto segundo o que sei do negócio”.

Se você está usando IA para gerar código e ainda não definiu quem valida antes do merge, você não tem produtividade — tem dívida diferida. E quando essa dívida vencer, quem paga a conta não é a IA.

Leitura relacionada

• AI não vai substituir programador — vai substituir o que você faz no fim de semana — o precursor desta discussão, com o framework das 4 camadas do trabalho de desenvolvimento.
• Dependência de IA na revisão de código — aprofunda a governança de revisão que este post toca na seção de responsabilidade.
• Programação em par com IA: aceleração evolutiva — o lado positivo do mesmo fenômeno, com métrica de Microsoft Research 2024.