Eu passei 15 anos achando que meu diferencial era saber escrever código limpo. Que dominar design patterns, arquitetura hexagonal e testes automatizados me tornava insubstituível. Até que um estagiário com 3 meses de experiência gerou, usando Claude Code, uma API REST completa em 40 minutos — com testes, documentação e CI/CD configurado. Funcionou de primeira.

Aquilo doeu. Mas me ensinou algo que deveria ter percebido antes: o código em si deixou de ser o diferencial. A capacidade de verificar se o resultado está certo é que separa quem entrega valor de quem só gera pull requests.

O Dia em que o Código Perdeu Valor

Quando o GPT-4 apareceu em 2023, muita gente tratou como curiosidade. “Ele erra muito”, diziam. “Não entende contexto de negócio.” Tudo verdade — naquela época.

Três anos depois, o cenário é outro. O Claude Opus 4.8 resolve 88,6% dos issues reais do GitHub. O Kimi K2.6 usa 300 agentes simultâneos para escrever código. O DeepSeek Reasonix custa 94% menos que o Claude Code e produz resultados comparáveis.

A realidade é brutal: se seu trabalho consiste em pegar um ticket do Jira, traduzir para código e abrir um PR, você está competindo com algo que faz isso mais rápido, mais barato e sem reclamar de reunião desnecessária.

Mas calma — isso não significa que devs vão desaparecer. Significa que o tipo de dev que tem valor mudou radicalmente.

O Modelo Antigo: Codificar Era Entender

Antes da IA generativa, havia um vínculo direto entre saber programar e entender um domínio. Se você construía sistemas para a bolsa de valores, precisava entender ordem a mercado, order books, latência em microsegundos. Se desenvolvia software para hospitais, precisava saber o que é um CID-10, como funciona prescrição eletrônica, o que significa HL7 FHIR.

Esse conhecimento vinha naturalmente com o trabalho. Cada bug corrigido, cada edge case descoberto, cada conversa com o usuário construía um modelo mental do domínio que era inseparável do código.

O artigo de Bret Horsting, que viralizou no Hacker News esta semana com mais de 600 votos, coloca de forma certeira: “Agentic AI severed the link between the two. You can now produce the software without ever building the model.”

E aí mora o perigo.

O Problema que Ninguém Está Discutindo

Imagine o seguinte cenário: uma fintech contrata um dev sênior, excelente em arquitetura de microsserviços, que usa Claude Code para gerar toda a lógica de cálculo de juros compostos para um produto de crédito.

O código compila. Os testes passam. O PR é aprovado. Vai para produção.

Três meses depois, a fintech descobre que está cobrando 0,3% a menos de juros de todos os clientes. A diferença? O modelo usou juros simples em um trecho onde deveria usar juros compostos com capitalização diária. O dev não percebeu porque não sabia a diferença — e a IA não avisou porque gerou código sintaticamente perfeito.

# O que a IA gerou (parece certo)
def calcular_juros(principal, taxa_anual, dias):
    taxa_diaria = taxa_anual / 365
    return principal * (1 + taxa_diaria * dias)

# O que deveria ser (juros compostos com capitalização diária)
def calcular_juros(principal, taxa_anual, dias):
    taxa_diaria = taxa_anual / 365
    return principal * (1 + taxa_diaria) ** dias

A diferença entre essas duas funções é uma operação: multiplicação vs exponenciação. Qualquer um que entende matemática financeira pega isso em 2 segundos. Mas um dev que só sabe “fazer funcionar”? Não tem chance.

Esse é o novo risco da indústria: código que funciona, mas está errado. E só quem tem expertise de domínio consegue detectar.

Os 3 Perfis de Dev na Era da IA

A nova realidade cria três perfis distintos, e só um deles tem futuro a longo prazo:

1. O Dev-Operador (em risco)

Pega tickets, gera código com IA, abre PR. Alta produtividade aparente, mas zero capacidade de validação. É o equivalente moderno do “code monkey”, só que agora nem precisa digitar. Quando a empresa perceber que pode substituir esse perfil por um agente autônomo com guardrails, o cargo desaparece.

2. O Especialista de Domínio (em ascensão)

Não é o melhor programador do time, mas entende o negócio como ninguém. Sabe que aquele cálculo de imposto precisa considerar o regime cumulativo vs não-cumulativo. Sabe que o campo “data de vencimento” na API do banco central tem timezone UTC, não local. Sabe que o fluxo de cancelamento tem 47 regras de negócio que nenhum prompt vai capturar.

Esse profissional agora pode usar IA para multiplicar sua capacidade. O que antes levava semanas de codificação manual, agora leva horas — mas com a garantia de que o resultado é correto, porque quem valida entende o que está olhando.

3. O Híbrido (ouro puro)

Combina expertise técnica profunda com conhecimento de domínio. Sabe que o código gerado pela IA tem um race condition no processamento de pagamentos porque entende tanto concorrência quanto o fluxo de compensação bancária. Esse perfil é o mais raro e o mais valioso.

“The binding constraint has moved from can you build it to can you tell whether it’s right.”

— Bret Horsting

Na Prática: Onde Expertise de Domínio Já Define Tudo

Não estou falando de teoria. Veja áreas onde a verificação humana é insubstituível:

Healthcare / Saúde

Um modelo de IA pode gerar um sistema de prescrição eletrônica perfeito do ponto de vista técnico. Mas se não considerar interações medicamentosas (dipirona com anticoagulantes, por exemplo), o sistema é uma bomba-relógio. O dev que entende farmacologia pega esse erro. O que só sabe React, não.

Finanças / Banking

Regulação bancária muda a cada trimestre. O Banco Central publica circulares que alteram regras de cálculo, limites de exposição, requisitos de capital. Um agente de IA treinado em dados de 2024 não sabe que a Circular 3.978 foi atualizada em março de 2026. O dev que lê as circulares sabe.

Jurídico / LegalTech

Gerar um contrato com IA é fácil. Gerar um contrato válido que sobreviva a uma contestação judicial? Isso exige entender jurisprudência, cláusulas abusivas, competência de foro, e cinquenta outros conceitos que nenhum modelo de linguagem domina com 100% de confiança.

DevOps / Infraestrutura

Configurar um cluster Kubernetes com IA é trivial. Mas saber que aquele PodDisruptionBudget precisa ser minAvailable: 2 (e não 1) porque o serviço de pagamentos não pode ter menos de 2 réplicas durante um rolling update? Isso vem de ter acordado às 3 da manhã com o PagerDuty tocando.

# O que a IA gera (genérico)
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-service-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: payment-service

# O que o especialista sabe que precisa ser
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-service-pdb
spec:
  minAvailable: 2  # Nunca menos de 2 réplicas - SLA de 99.99%
  selector:
    matchLabels:
      app: payment-service

O Que Muda na Sua Carreira (Agora)

Se você é dev e está lendo isso, a pergunta prática é: o que eu faço com essa informação?

1. Escolha um domínio e vá fundo

Pare de colecionar frameworks. Sério. Saber Next.js, Remix, SvelteKit, Astro, Nuxt e mais 15 meta-frameworks não te diferencia — a IA sabe todos eles melhor que você.

O que a IA não sabe é como funciona o sistema tributário brasileiro. Ou as regras de compliance do BACEN. Ou o workflow de um hospital de campanha. Ou a lógica de pricing dinâmico de uma companhia aérea.

Escolha uma indústria. Leia seus regulamentos. Converse com os usuários finais. Entenda os edge cases que não estão em nenhuma documentação técnica.

2. Aprenda a ser o “verificador final”

O papel mais valioso no desenvolvimento de software em 2026 não é quem escreve código — é quem faz a última revisão antes de ir para produção. Quem olha o output da IA e diz “isso aqui está errado porque no cenário X, a regra Y se aplica diferente”.

Esse é o novo senior. Não o que escreve o código mais elegante, mas o que impede a catástrofe.

3. Documente o que a IA não sabe

Toda empresa tem conhecimento tribal — aquelas regras que estão na cabeça do João que trabalha lá há 12 anos. “Ah, esse cliente tem um contrato especial que não segue a tabela padrão.” “Esse fornecedor manda o XML com encoding errado, a gente precisa tratar.”

Esse conhecimento é ouro. Documente-o. Transforme-o em testes. Crie guardrails que a IA possa usar. Quem faz isso se torna indispensável.

4. Pare de competir com a IA em velocidade

Você não vai gerar código mais rápido que um LLM. Aceite isso. Sua vantagem é qualidade de julgamento, não velocidade de output. Um médico não compete com o Google em velocidade de diagnóstico — compete em acurácia e responsabilidade.

Os Números Que Assustam (e os Que Tranquilizam)

O cenário parece sombrio, mas os dados contam uma história mais nuançada:

O gap salarial entre quem tem expertise de domínio e quem é “generalista” está aumentando, não diminuindo. Empresas estão percebendo que não adianta ter 10 devs com IA se nenhum deles sabe dizer se o resultado está certo.

O Erro das Empresas: Demitir os Especialistas

A ironia é que muitas empresas estão fazendo exatamente o contrário do que deveriam. Estão demitindo os devs seniores (caros, com conhecimento de domínio) e mantendo os juniores (baratos, “produtivos com IA”).

A Wix demitiu 1.000 funcionários e culpou a IA. A Cloudflare cortou 1.100. Em quase todos os casos, os primeiros a sair são os seniors — justamente os que têm o conhecimento de domínio que a IA não consegue replicar.

É como demitir todos os pilotos de avião porque o piloto automático ficou bom. Funciona 99% do tempo. No 1% que não funciona, as consequências são catastróficas.

Dê 18 meses. Essas mesmas empresas vão estar contratando consultores a $500/hora para resolver os bugs que os agentes de IA introduziram — porque ninguém na equipe sabe mais o que o sistema deveria fazer.

Como Identificar Se Você Está na Zona de Risco

Faça este teste rápido:

1. Se alguém te pedir para explicar por que o código faz X e não Y, você consegue justificar pela regra de negócio? Se a resposta é “porque o ChatGPT gerou assim”, você está na zona de risco.

1. Você sabe quais são os 5 cenários mais perigosos do sistema em que trabalha? Não cenários técnicos (race condition, deadlock) — cenários de negócio (cobrança duplicada, cálculo errado de imposto, violação de LGPD).

1. Quando o cliente liga reclamando, você entende o problema antes de olhar o código? Se precisa debugar para entender o que o cliente está falando, falta conhecimento de domínio.

1. Você lê as atualizações regulatórias da sua indústria? Circulares do BACEN, resoluções da ANVISA, portarias do MEC — dependendo do seu setor, ignorar isso é como programar sem ler a documentação da API.

Se respondeu “não” para 3 ou mais, o momento de mudar é agora. Não daqui a 2 anos. Agora.

O Fosso Que a IA Não Consegue Cruzar

A IA generativa é extraordinária em padrões. Ela viu milhões de CRUDs, milhares de implementações de autenticação, centenas de arquiteturas de microsserviços. Se o problema se parece com algo que já foi resolvido antes, a IA resolve.

Mas expertise de domínio é, por natureza, contextual. É saber que naquele hospital específico, o fluxo de emergência pula a triagem quando o paciente chega de ambulância do SAMU. É saber que naquele banco específico, transferências acima de R$ 100.000 precisam de aprovação dual. É saber que naquele e-commerce específico, o cálculo de frete para o Amazonas tem uma regra diferente porque o fornecedor não cobre a última milha.

Isso não está em nenhum dataset de treinamento. Está na cabeça de quem conhece o negócio. E esse conhecimento é, literalmente, o único fosso que a IA não consegue cruzar — porque ele muda a cada empresa, a cada contrato, a cada regulação nova.

A pergunta que fica: você está construindo expertise no que a IA já sabe fazer, ou no que ela ainda não consegue verificar?

—

Fonte de inspiração: Domain expertise has always been the real moat — Bret Horsting, Hacker News trending com 644+ votos