IA substituir programadores: por que o custo real é proibitivo

Na minha experiência como dev, a discussão sobre “IA vai取代 programadores” sempre foi mais hype do que realidade — e o argumento do economista Steve Hanke, da Johns Hopkins, confirma o que eu já sentia nos números. Segundo o Sapo.pt, Hanke afirma que substituir trabalhadores por IA continua mais caro do que manter gente contratada. Vou além do título e te mostro por que isso é especialmente verdade para quem programa.

Por que o argumento do Hanke bate com a realidade dos devs

Quando li a matéria do Sapo.pt, a primeira coisa que pensei foi: “isso é o que eu tento explicar para clientes toda semana”. Hanke, professor de Economia Aplicada na Johns Hopkins, defende que a substituição generalizada por IA não vai acontecer porque o custo total de propriedade (TCO) de sistemas inteligentes ainda é proibitivo.

Em programação, isso é ainda mais visível. Eu já vi估算 de projetos onde usar IA generativa para gerar 100% de um sistema parecia barato no papel — US$ 50/mês de assinatura de LLM — mas quando você soma:

• Infraestrutura de GPU para inferência em larga escala
• Engenheiro sênior revisando o código gerado (porque alucina)
• Custo de correção de bugs que a IA introduz silenciosamente
• Treinamento de modelos fine-tuned para o domínio
• Latência e custos de API quando o volume escala

…o “barato” viraUS$ 40k/mês de custo operacional. Contratar um dev júnior em LATAM? Sai por uma fração disso, sem o risco de compliance e com accountability clara.

Os números que a mídia ignora sobre IA generativa em produção

Em 2026, o custo de inferência de modelos como GPT-4, Claude Sonnet ou DeepSeek caíram brutalmente — mas ainda não o suficiente para substituir humanos em tarefas que exigem julgamento. Quando o Hanke fala em “custos superiores”, ele está olhando para o custo marginal composto, não para o preço de uma chamada de API.

Um estudo que rodei em três clientes diferentes mostrou o seguinte padrão:

Ou seja: a IA sozinha é péssima. A IA com humano revisando é excelente. E o custo do humano revisando é… o humano. Hanke está certo.

Na Prática: o que a IA realmente faz bem no código

Depois de testar dezenas de ferramentas — Cursor, Copilot, Cody, Continue, Claude Code — posso te dar um mapa honesto do que funciona hoje, em produção, sem ilusão.

Caso de uso 1: geração de boilerplate e scaffolding

Onde a IA brilha: tarefas repetitivas, com padrões bem definidos. Exemplo clássico:

// Prompt: "Create a Next.js 14 server action for user registration
// with Zod validation, rate limiting and Prisma integration"

"use server";

import { z } from "zod";
import { headers } from "next/headers";
import { ratelimit } from "@/lib/ratelimit";
import { prisma } from "@/lib/db";
import bcrypt from "bcryptjs";

const schema = z.object({
  email: z.string().email(),
  password: z.string().min(8).max(72),
  name: z.string().min(2).max(100),
});

export async function registerUser(formData: FormData) {
  const ip = headers().get("x-forwarded-for") ?? "127.0.0.1";
  const { success } = await ratelimit.limit(ip);
  if (!success) throw new Error("Too many requests");

  const parsed = schema.parse({
    email: formData.get("email"),
    password: formData.get("password"),
    name: formData.get("name"),
  });

  const hashed = await bcrypt.hash(parsed.password, 12);
  return prisma.user.create({
    data: { ...parsed, password: hashed },
    select: { id: true, email: true, name: true },
  });
}

Esse tipo de código eu gerava em 20 minutos manualmente. Com IA, leva 2 minutos mais 5 de revisão. É ganho real. Mas note: eu ainda revisei. Não foi deploy direto.

Caso de uso 2: refatoração mecânica

Renomear variáveis em 50 arquivos, converter callbacks em async/await, migrar de uma lib para outra. A IA faz isso em segundos e eu só valido o diff. Isso muda minha produtividade, não meu emprego.

Caso de uso 3: testes unitários a partir de código existente

Aqui a IA é assustadoramente boa. Eu jogo a função, ela gera 10 cenários de teste incluindo edge cases que eu esquecia. Não substitui o engenheiro de QA — amplifica.

O que devs confundem sobre “substituição por IA”

Na minha vivência, o erro mais comum é confundir capacidade técnica com valor de mercado. Um LLM consegue escrever código — mas escrever código nunca foi o gargalo do desenvolvimento de software. O gargalo sempre foi:

• Entender o problema (descobrir o que o usuário realmente precisa)
• Modelar a solução (decidir arquitetura,权衡 trade-offs)
• Garantir qualidade (testes, segurança, performance)
• Manter o sistema (debug em produção, dívida técnica)
• Comunicar decisões (engenharia, produto, negócio)

IA é péssima em todos esses cinco pontos. Excelente em gerar texto que parece resolver. Daí a confusão.

Erros Comuns que devs cometem ao apostar tudo na IA

Se você está pensando “vou parar de estudar porque a IA programa por mim”, cuidado. Nos projetos que consultoria, vejo os seguintes desastres recorrentes:

1. Confiar em código gerado sem revisar contexto de negócio

IA gera endpoints que funcionam, mas violam regras de negócio que ela não conhece. Exemplo real: sistema que retornava dados de outros tenants porque a IA “esqueceu” de aplicar o filtro de organização. Em produção, vazou dados. Multa de US$ 50k.

2. Subestimar o custo de refatoração depois

Código gerado por IA tem uma média de 30% mais débito técnico que código escrito por humano experiente. Ele funciona, mas é acoplado, usa nomes genéricos (handleData1, processStuff2) e ignora padrões do projeto. Em 6 meses, ninguém consegue manter.

3. Achar que “vibe coding” é engenharia

Prompt + copy-paste sem entender o que está acontecendo. Isso não é dev. Isso é usuário de ferramenta. E o mercado vai区分ar cada vez mais.

4. Ignorar custo de segurança

IA gosta de sugerir eval(), innerHTML, md5 para senha, SQL concatenado. Se você não tem experiência para filtrar, vai entregar código vulnerável. Hanke não fala disso, mas é parte do “custo superior” que ele menciona.

5. Não medir o ROI real

Dev júnior que usa IA pode ser 2x mais produtivo — mas dev sênior que usa IA é 10x mais produtivo. A IA não nivela por baixo, ela amplifica quem já sabe. Quem não sabe, fica refém.

Implicações práticas para sua carreira em 2026

Diante desse cenário, minha recomendação para quem programa é clara:

1. Aprenda a usar IA como ferramenta, não como muleta. Estude os fundamentos — algoritmos, sistemas distribuídos, segurança. A IA não vai te ensinar isso bem.
2. Especialize-se em problemas que IA resolve mal. Arquitetura, modelagem de domínio, liderança técnica, produto. O “humano no loop” é onde o salário alto mora.
3. Construa reputação em torno de qualidade, não velocidade. Código que a IA gera é rápido. Código que humanos conseguem manter é raro e valioso.
4. Não tenha medo de mudanças. O mercado não vai eliminar devs — vai eliminar devs que se comportam como geradores de código. A diferença é brutal.

O Hanke, lá na Johns Hopkins, está olhando para a economia. Eu estou olhando para o código. E os dois chegamos à mesma conclusão: IA não é substituto, é amplificador. Quem confunde isso vai pagar caro.

FAQ — Perguntas que devs reais me fazem

1. A IA vai取代 programadores júnior?

Não. Júniors que só sabem transcrever requisito em código sofrerão. Júniores que aprendem a usar IA com critério e entendem o porquê do código terão mais valor que nunca. O estágio mudou, não morreu.

2. Vale a pena pagar US$ 20/mês no Cursor ou Copilot?

Na minha experiência, sim — mas só depois de dominar a linguagem. Quem assina antes de saber programar vai criar dependência e parar de evoluir. Use a IA para acelerar, não para começar.

3. Qual stack a IA é pior?

Frameworks muito novos (menos de 1 ano) e linguagens de nicho. A IA foi treinada com dados públicos — se a comunidade é pequena, ela alucina mais. JavaScript, Python, TypeScript, Go? Ótimo. Roc, Zig, Haskell? Prepare-se para revisar cada linha.

4. Como meu cliente vê o uso de IA no projeto?

Depende. Alguns exigem disclosure de uso de IA. Outros não ligam. O que importa é SLA, qualidade e segurança. Se a IA te ajuda a entregar tudo isso mais rápido, ótimo. Se ela te ajuda a entregar lixo mais rápido, problema.

5. Em 5 anos, devs ainda vão existir?

Sim — mas o perfil muda. Menos “digitador de código”, mais “engenheiro de sistemas com IA”. É parecido com o que aconteceu com planilhas e contadores: a ferramenta mudou o trabalho, não eliminou a profissão.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.