AI não vai substituir programador. Vai substituir o que você faz no fim de semana.

Última semana, um dev sênior me mandou um código pra revisar. Tinha sido gerado pelo Claude. Estrutura correta, testes passando, lint limpo. Tudo certo. Até eu abrir o laço principal e ver que a variável de iteração se chamava i num lugar onde devia ser userId.

Sintaxe perfeita. Contexto errado. E o pior: o código passava em CI.

Esse é o tipo de coisa que assusta e tranquiliza ao mesmo tempo. Assusta porque mostra que a AI generativa já escreve código indistinguishable do bom. Tranquiliza porque o erro é precisamente o que diferencia um dev de um operador de ferramenta. E aí a pergunta muda. Não é mais “AI vai me substituir?”. É “AI vai substituir o que você faz hoje, ou o que você deveria estar fazendo?“.

Se a resposta for a primeira, você tem motivo pra se preocupar. Se a resposta for a segunda, a AI acabou de te dar um aumento.

O que AI generativa faz muito bem

Não é força de expressão. AI generativa é genuinamente boa em:

• **CRUD.** Endpoint, validação, ORM, paginação, ordenação, filtro. Tudo isso é combinatória bem mapeada.
• **Refatoração mecânica.** Renomear, extrair método, mover classe, ajustar imports. AI faz isso sem cansar e sem esquecer.
• **Geração de testes pra código que ela mesma escreveu.** Se você pede pra AI gerar a função e o teste junto, a cobertura sobe.
• **Documentação.** Docstrings, README, JSDoc. Texto bem estruturado a partir de código bem estruturado.
• **Migração de sintaxe entre versões.** Python 2 → 3, Java 8 → 17, callbacks → async. AI decorou os mapas.
• **Boilerplate repetitivo.** Controllers, serializers, DTOs, migrations, configuração de Docker.

Nenhuma dessas tarefas exige que o dev entenda o porquê de cada linha. Exige que ele conheça o como — que é exatamente o que AI generativa aprendeu com bilhões de linhas de código aberto.

Onde AI generativa quebra (a maldição da sintaxe perfeita)

O problema aparece em três pontos. Os três são sutis porque o código parece certo.

Primeiro: AI não lê regra de negócio. Ela lê o código que já existe. Se o sistema não tem a regra explícita, AI não inventa — ela improvisa. No ERP que vi semana passada, o sistema tinha uma validação de estoque que dependia do tipo de operação fiscal (remessa, venda, transferência, bonificação). Cada tipo tem uma trava diferente. Nenhuma estava documentada no código — estava na cabeça do analista sênior que saiu em 2019. AI gerou a validação “óbvia”. Errada em 3 dos 4 casos.

Segundo: AI generaliza errado quando o domínio é específico. Se você pede um “endpoint de criação de usuário”, AI entrega 20 linhas limpas. Mas o seu domínio exige que esse endpoint dispare um evento no Kafka, invalide cache de três regiões, marque o usuário em uma fila de revisão manual, e respeite a LGPD com anonimização em 30 dias. AI não vai adivinhar isso. AI vai entregar o UserController genérico.

Terceiro: AI não pergunta. AI responde. E responde rápido. Isso parece produtividade, mas é o oposto quando a pergunta certa ainda não foi feita. Boa parte do trabalho de dev sênior é fazer a pergunta antes. “Por que esse endpoint existe? Qual a expectativa de carga? O que acontece se essa chamada falhar no meio?” AI pula direto pra resposta. É onde mora a maior parte do retrabalho.

O framework: 4 camadas do trabalho de dev

Pra entender onde AI ajuda e onde AI atrapalha, eu divido o trabalho de dev em quatro camadas. Cada uma tem um perfil diferente de exposição à automação.

Camada 1 — Sintaxe

Escrever a linha em si. Declarar variável, fechar chave, montar JSON, configurar decorator. É 100% substituível por AI. Se você passa o dia aqui, AI te substitui em 6 meses.

Camada 2 — Lógica

Pensar o algoritmo. “Como eu percorro essa lista?”, “Qual a complexidade disso?”, “Esse loop tem que rodar uma vez ou N?”. AI é forte aqui também, mas com asterisco: ela resolve o problema genérico, não a sua variante específica. Exige revisão humana pra checar se a lógica genérica serve pro seu contexto.

Camada 3 — Contexto

Saber como esse pedaço de código conversa com o resto do sistema. Qual o banco? Qual a versão? Qual o contrato da API externa? Qual a expectativa de carga no horário de pico? AI infere contexto a partir do código adjacente, mas erra quando o contexto tá em outro lugar — numa planilha, num ticket, num e-mail de 2017, na cabeça de um colega.

Camada 4 — Intenção

Saber por que esse código existe. Qual o problema do usuário que isso resolve? Qual a estratégia de negócio que isso viabiliza? Qual o trade-off que foi aceito? AI não tem como inferir isso. Está fora da janela de contexto, do training set, do codebase. Só existe na cabeça de quem toma decisão de produto.

Onde você passa seu dia define se AI é aliada ou ameaça. Camadas 1 e 2: AI te multiplica. Camada 3: AI te ajuda mas exige supervisão constante. Camada 4: AI não chega perto. Se você vive na 4, AI te devolve tempo pra ficar mais ainda.

Por que contexto de negócio não cabe em janela de contexto

A janela de contexto de Claude, GPT, Gemini hoje gira em torno de 200k a 1M de tokens. Parece muito. Não é.

O contexto de negócio de um sistema de ERP legado é:

• A história de cada decisão regulatória dos últimos 12 anos
• As integrações com sistemas terceiros que ninguém documenta
• As exceções de cliente que viraram caso especial
• O ticket #3421 que justifica aquele `if (cliente == “X”) return;`
• A regra que o contador pediu em 2019 porque a Receita mudou a instrução normativa
• A fila de eventos que cresce 10x no fim do mês e ninguém sabe por quê
• O desenvolvedor que saiu em 2022 e levou com ele o conhecimento de 6 features

Tudo isso somado dá 200M tokens facilmente. Não cabe. E mesmo que coubesse, muito desse conhecimento tá em formato que AI não ingere bem: PDF escaneado, planilha com 30 abas, conversa de Slack, reunião sem ata.

AI generativa é o que cabe na janela. Contexto de negócio é o que não cabe. E o que não cabe é exatamente o que te torna insubstituível.

O caso real do ERP: a regra tributária invisível

Esse aqui é o que motivou o post. O dev sênior me chamou pra revisar um módulo de fechamento fiscal que ele tava reescrevendo com ajuda do Claude. AI gerou bonito. Classe FiscalClosureService, com métodos calculateICMS, calculatePIS, calculateCOFINS. Todos com testes. Todos passando.

Aí eu abri a regra do estado de Goiás pra PIS/COFINS em 2024, e tinha uma exceção pra operações com código CFOP 5.556 que o sistema não tratava. AI não gerou a exceção porque não tinha como saber que ela existia — tava num PDF da SEFAZ-GO, mudou em abril de 2024, e o dev que sabia disso tava de férias.

Resultado: o código que AI gerou era “corretamente estruturado, testado, até lint passava”. E ia reprocessar 18% das notas fiscais errado em produção. Pego em revisão, fácil. Pego em produção, com cliente, com multa da Receita, é outra conversa.

O dev que entende por que aquela validação existe — nunca vai ser substituído por AI. AI não vai abrir SEFAZ-GO, cruzar com o histórico de mudanças, inferir que aquela operação é crítica, e te avisar antes de commitar. Você vai ter que fazer isso. E é exatamente esse trabalho que tem valor.

O dev que copia Stack Overflow vai ser substituído (e tá tudo bem)

Dizer isso em 2026 soa agressivo. Não é. É uma constatação.

Copiar Stack Overflow em 2010 era uma habilidade. Significava que você sabia encontrar a resposta — e encontrar era 80% do problema. Em 2026, AI encontra, adapta, e gera. Copiar virou commodity. O valor de “saber copiar” caiu pra quase zero.

Não tem nada de errado nisso. É o que acontece com toda automação: tarefas mecânicas viram código, código vira serviço, serviço vira commodity. O mecânico de hoje não conserta carro com chave de fenda; ele lê sensor. O dev de hoje não vai copiar código da internet; ele vai definir o problema e validar a solução.

A pergunta real não é “será que AI me substitui?”. A pergunta é: você tá evoluindo na direção que AI não substitui, ou na direção que AI substitui em 6 meses?

Se você passa o dia implementando o que o PO pediu, sem questionar o pedido, sem entender o contexto, sem negociar o escopo — AI faz isso. Mais rápido, mais barato, sem almoço.

Se você passa o dia entendendo o problema, mapeando o contexto, identificando o que tá implícito, e entregando a coisa certa em vez da coisa pedida — AI te multiplica. Porque ela tira de você a parte mecânica e te devolve tempo pra parte que importa.

O dev que entende o “porquê” não vai ser substituído

O “porquê” mora em três lugares:

No produto. Por que esse endpoint existe? Qual problema do usuário ele resolve? Qual métrica de negócio ele mexe? Se você não sabe, você tá escrevendo código pra uma abstração que pode ser trocada por outra na próxima sprint.

No domínio regulatório. Por que essa validação existe? Qual regra fiscal, contratual ou de compliance ela implementa? Se você não sabe, AI vai gerar uma validação plausível e errada, e você não vai ter como validar.

Na operação. Por que esse código tá nesse caminho crítico? Qual o SLA? Qual o impacto se ele cai? Se você não sabe, você vai tratar como qualquer outro endpoint, e quando cair em produção no fim do mês, a desculpa de “tava no backlog” não vai colar.

Quando você entende os três, AI vira uma ferramenta de aceleração, não de substituição. Você pede pra AI gerar a primeira versão, e usa seu tempo pra validar contexto, intenção e impacto. O ciclo encurta. A qualidade sobe. O risco despenca.

O que muda no seu dia a dia a partir de agora

Três ajustes práticos que eu faria hoje se eu fosse um dev pleno começando 2026:

Pare de pedir “escreve X código”. Comece pedindo “explica o problema X”. A explicação força você a entender o contexto. O código vem depois, e vem melhor.

Use AI pra aumentar sua fluência em domínio, não pra evitar ela. Peça explicação de regra tributária. Peça pra ela mapear regulação. Peça pra ela te ensinar o domínio. Você tá treinando seu modelo mental, não o modelo dela.

Revise código gerado por AI com a pergunta “isso tá certo pro MEU contexto?” Não “isso tá certo?”. Os dois vão parecer iguais em 90% dos casos. Os 10% diferentes são onde mora seu emprego.

Se você fizer isso, AI vira a melhor ferramenta da sua carreira. Se não fizer, AI vira a evidência usada pra te substituir. Mesma tecnologia. Resultado oposto. Depende de você.

Como aumentar sua fluência em domínio de negócio

Poucos devs têm isso mapeado. Eu também não tinha até parar de aceitar “tarefa é isso, código é isso, fim”.

Três coisas que funcionam:

Fale com o cliente. Não com o PO, com o cliente. Uma hora de call por semana com o usuário real vale mais que 10 sprints de feature. Pergunta: por que você usa isso? O que dói? O que você faria se pudesse mudar uma coisa?

Leia código antigo. Não código bom — código antigo. Vai no git log, abre commit de 2018, lê o PR description, lê a discussão. Você vai entender o histórico das decisões. E vai entender o que era prioridade ontem, e porque mudou.

Mapeie o que tá implícito. Pega o sistema que você trabalha, e escreve um documento: “coisas que esse sistema faz que não tão em lugar nenhum, e que se eu mudar isso aqui, ninguém vai entender por que até quebrar em produção”. Esse documento é ouro. AI não consegue gerar. Só você consegue.

E aqui mora o ponto que une esse post com o anterior sobre clean code que destruiu a produtividade do seu time: dogma de livro aceito sem medir, e ferramenta de moda usada sem medir, dão no mesmo lugar. Código perfeito de coisa errada. A qualidade do código não salva o sistema da falta de contexto. O post sobre ERP lento mostrou isso do lado da infraestrutura: a consultoria entregou RDS, Redis, oito servidores. Sistema continuou lento porque o problema era o código, não a máquina. Mesma família. Sintaxe boa, contexto errado.

A frase de fechamento

Existe uma versão do seu trabalho que AI faz melhor que você. Reconhecer isso é o primeiro passo. Existe outra versão que AI não faz, e que é exatamente o que te torna valioso. Reconhecer isso é o segundo.

A primeira versão é o que você faz no fim de semana. Tarefa chata, deadline apertado, copy de Stack Overflow, gerador de CRUD, conversor de JSON, mais um endpoint que é igual aos outros trinta. AI faz isso em segundos. Você leva horas. É justo. A conta é simples.

A segunda versão é o que justifica seu salário. Entender por que aquele sistema foi feito daquele jeito. Saber que aquela exceção tributária existe. Questionar o pedido antes de implementar. Reconhecer o que tá implícito. Mapear o contexto que AI não tem. É trabalho de dev sênior, e é trabalho que não cabe em janela de contexto.

AI não vai te substituir. Mas vai substituir o que você faz no fim de semana. E se você não gostar do que sobra, a culpa não é da AI. É de como você usou ela.

Sua segurança profissional não é código. É compreensão de negócio. Invista nisso.