“O seu grau de empolgação com a IA é inversamente proporcional à quantidade de conhecimento que você tem em relação ao assunto.”

— Fábio Akita

Essa frase me acertou em cheio quando ouvi pela primeira vez. Não porque fosse novidade — eu já sentia isso empiricamente. Mas porque Akita colocou em palavra exata o que eu observava silenciosamente toda vez que alguém me dizia que a IA “vai mudar tudo” ou que em dois anos não vai haver mais desenvolvedor no mercado.

Vou ser direto: IA não vai substituir o meu trabalho. Mas não vou usar essa afirmação como escudo de arrogância corporativa. Vou explicar o raciocínio — com dados, com honestidade, e com a consciência de que, para uma fatia real do mercado, a substituição já está acontecendo.

O contexto que não dá para ignorar

Os números são reais e merecem respeito:

  • GitHub Copilot tem mais de 1,8 milhão de assinantes pagos (GitHub Octoverse 2024). Em empresas que o adotam, desenvolvedores reportam entre 20% e 55% de aumento de produtividade em tarefas de codificação.
  • Cursor, o editor baseado em IA, saiu do zero para mais de 360 mil usuários ativos em menos de dois anos. Em rodadas de investimento recentes foi avaliado em mais de U$2,5 bilhões.
  • Modelos de linguagem como Claude 3.5 Sonnet, GPT-4o e Gemini 2.0 hoje passam em benchmarks técnicos que há dois anos seriam impossíveis: geram testes unitários, arquitetam módulos completos, debugam stacktraces e refatoram código legado com qualidade de senior em tarefas bem delimitadas.
  • O conceito de vibe coding — cunhado por Andrej Karpathy em fevereiro de 2025 — descreve uma nova forma de criar software: você descreve o que quer em linguagem natural, a IA gera, você ajusta no feeling, sem necessariamente entender o que foi produzido.

Vibe coding é real. É produtivo para certos contextos. E é exatamente onde mora o perigo.

O que o vibe coding entrega bem

Para projetos de escopo controlado — um script de automação, um CRUD simples, uma landing page, um protótipo de demonstração — o vibe coding entrega rápido. Rápido mesmo. Uma pessoa com habilidade de prompt engineering consegue em horas o que levaria dias no modelo tradicional.

Isso tem valor. Não vou diminuir isso.

O que o vibe coding não entrega

Vibe coding não entrega decisões. Ele entrega código que parece funcionar. Às vezes funciona de verdade. Às vezes funciona no contexto do desenvolvedor mas falha em produção sob carga, com dados reais, no horário de pico de uma terça-feira às 14h quando o time de vendas empurrou uma campanha não planejada.

A IA não sabe que o banco de dados está em uma VNet privada no Azure e que a connection string não pode ser passada como variável de ambiente plain text porque a política de conformidade da empresa exige Key Vault. A IA não sabe que aquela API de terceiro tem um limite de 100 requisições por minuto e que a solução que ela gerou vai explodir em produção em menos de 15 segundos. A IA não sabe que a empresa já tentou uma abordagem similar dois anos atrás e o resultado foi um incidente que durou 4 horas.

Eu sei. Porque eu estava lá.

Por que especificamente eu não serei substituído

Deixa eu ser preciso. Não é vaidade — é análise.

1. Meu trabalho principal não é escrever código

Escrever código é um meio, não um fim. O fim é entregar uma solução que funcione dentro das restrições reais de um sistema real — constraint de custo, de performance, de compliance, de prazo, de capacidade do time que vai manter.

A maior parte do meu valor profissional está em perguntas que antecederem qualquer linha de código:

  • Esse problema precisa ser resolvido com código? Ou existe um serviço gerenciado que já resolve?
  • Se vou usar um serviço de nuvem, qual tier de SLA está dentro do budget previsto?
  • Esse microsserviço precisa de consistência forte ou consistência eventual basta? Essa decisão muda tudo.
  • Estamos colocando lógica crítica de negócio numa camada que vai mudar toda vez que o provider de cloud lançar uma versão nova da função?

A IA gera código para qualquer uma das escolhas. Ela não tem o contexto para fazer a escolha.

2. Conhecer serviços de cloud — de verdade

Há uma diferença enorme entre saber que um serviço existe e saber usá-lo bem.

Saber que o Azure Service Bus existe: a IA sabe. Saber que mensagens com TTL expirado vão para a Dead Letter Queue e que se você não consumir ela vai acumular e eventualmente gerar alertas de capacidade que vão acordar alguém às 3h: isso é experiência de produção.

Saber que o AWS Lambda tem cold start: a IA sabe. Saber que em determinado contexto com cargas intermitentes o cold start de uma função em .NET pode tornar o P99 de latência inaceitável para o SLA contratado — e que a solução não é provisioned concurrency, é repensar a arquitetura do serviço — isso é julgamento que vem de ter errado antes.

O ecossistema de cloud é gigantesco e muda constantemente. Azure, AWS e GCP cada um tem centenas de serviços, cada serviço tem quirks, limites, gotchas, interações inesperadas com outros serviços. Conhecimento acumulado sobre esse ecossistema não é substituível por um modelo que foi treinado até certa data e que frequentemente alucina detalhes de configuração com convicção absoluta.

3. Conhecimento de múltiplas tecnologias — e saber qual usar

Não é sobre saber tudo. É sobre ter mapa mental suficiente para reconhecer qual ferramenta serve ao problema.

Quando alguém me traz um problema de performance em leitura de banco de dados, eu tenho um repertório de abordagens — cache distribuído, read replica, eventos pré-computados, CQRS, desnormalização estratégica, paginação por keyset — e sei pelo contexto qual delas faz sentido. Não todas. A que faz sentido aqui, agora, com esse time, dentro desse prazo.

A IA me dá as opções. Às vezes as lista bem. Mas ela não tem o peso do contexto. Ela não sabe que o time de manutenção é pequeno e que introduzir event sourcing agora vai criar um problema de onboarding que vai custar mais do que o problema que resolve.

4. Decisões arquiteturais: o que funciona vs. o que parece certo

Essa é a parte mais difícil de explicar para quem não viveu, e a mais importante.

Existem padrões arquiteturais elegantes — CQRS, Event Sourcing, microsserviços granulares, arquitetura hexagonal — que são tecnicamente corretos, academicamente defensáveis, e desastrosos em determinados contextos organizacionais.

Uma equipe de 3 devs mantendo um sistema financeiro legado não vai se beneficiar de uma reescrita em microsserviços assíncronos com event sourcing e uma plataforma de mensageria distribuída. Ela vai produzir um sistema impossível de debugar, com complexidade operacional que o time não consegue absorver, e vai criar débito técnico de novo tipo onde antes havia débito técnico de tipo antigo.

Saber quando não aplicar um padrão é tão valioso quanto saber aplicá-lo. Isso não está nos livros. Está nas cicatrizes.

A IA não tem cicatrizes. Ela tem tokens.

O problema do mentiroso confiante

Há uma dinâmica que observo com frequência — e que me preocupa genuinamente no mercado:

A IA é um mentiroso confiante para quem não tem conhecimento profundo.

Não uso “mentiroso” como insulto ao modelo. Uso como descrição técnica precisa: um LLM gera a resposta mais provável dado o contexto, não a resposta mais correta. Quando o espaço de possibilidades é vasto e o usuário não tem como avaliar a qualidade da resposta, o modelo pode — e frequentemente gera — informações incorretas com o mesmo tom, a mesma formatação e a mesma confiança aparente de quando está certo.

Isso é perigoso quando você não tem conhecimento para distinguir. E isso é extremamente produtivo quando você tem.

1
2
3
4

Developer sem conhecimento profundo + IA = código que parece funcionar
Developer com conhecimento profundo + IA = aceleração real com qualidade

A diferença não é a IA. A diferença é o desenvolvedor.

A IA não substitui a atuação humana na programação, mas amplifica a capacidade de quem programa. Ela não transforma um profissional fraco em alguém melhor — apenas ajuda a produzir resultados fracos mais rápido. Já nas mãos de um desenvolvedor experiente, a IA se torna um acelerador poderoso, permitindo entregar código de alta qualidade em um ritmo que antes exigia equipes inteiras.

Já vi arquitetos experientes usar Claude para gerar scheletons de código em minutos — e depois revisarem, ajustarem, descartarem partes e produzirem algo sólido na metade do tempo que levariam sem a ferramenta. A IA funciona como multiplicador do que eles já sabem.

Já vi desenvolvedores juniores usar a mesma ferramenta para gerar código que passou em todos os testes locais, foi para produção, e causou um problema de N+1 silencioso que só apareceu sob carga real — porque eles não sabiam o que perguntar, não sabiam revisar, e não tinham o repertório para identificar que o código estava errado mesmo quando parecia certo.

Quem deve se preocupar — e com o quê

Vou ser honesto sobre o que me preocupa:

Tarefas altamente repetitivas e bem delimitadas estão sendo absorvidas pela IA. CRUD básico, testes unitários para código simples, documentação, scripts de transformação de dados, código boilerplate. Isso é real. Isso está acontecendo agora.

O que isso implica? Provavelmente duas coisas:

  1. A demanda por desenvolvedores de baixo nível de especialização vai diminuir. Quem se posicionou no mercado como “escrevo código que me pedem” vai sentir pressão. Não porque a IA seja melhor programador — mas porque ela é mais barata para esse perfil de tarefa.

  2. A demanda por desenvolvedores que tomam decisões vai aumentar. À medida que a velocidade de produção de código aumenta, a necessidade de quem sabe o que produzir, em que ordem, e com que arquitetura, cresce proporcionalmente.

O mercado não vai precisar de menos pensamento. Vai precisar de menos digitação.

E o pensamento — o julgamento contextual, a experiência de ter falhado de formas específicas, o conhecimento de como diferentes peças se encaixam em sistemas reais — isso ainda é humano.

Por enquanto. Não vou mentir que esse “por enquanto” é para sempre. Mas estamos longe de um modelo que substitua julgamento técnico contextualizado. E no tempo que isso levar, investir em aprofundar conhecimento real continua sendo a melhor estratégia.

O que fazer com isso

Se você está no começo da carreira ou querendo se reposicionar:

Não use IA como substituto do aprendizado. Use como acelerador do aprendizado.

Há uma diferença crítica entre usar IA para gerar código que você vai estudar e entender — e usar IA para gerar código que você vai entregar sem entender. A primeira abordagem te torna melhor. A segunda cria uma ilusão de proficiência que vai se revelar no pior momento possível.

Aprenda os fundamentos que a IA assume que você já sabe: como sistemas distribuídos falham, como bancos de dados funcionam internamente, como serviços de nuvem realmente se comportam sob carga, o que torna uma arquitetura sustentável versus o que apenas parece elegante no diagrama.

Esses conhecimentos não ficam obsoletos quando sai um novo modelo de IA. Eles ficam mais valiosos.

Conclusão

A IA é a ferramenta mais poderosa que já tive nas mãos em 20 anos de carreira. Uso todos os dias. Ela me torna mais produtivo de formas que não seriam possíveis sem ela.

Mas ela é uma ferramenta. Uma ferramenta extraordinária nas mãos de quem sabe o que está construindo. E uma ferramenta que gera convicção sem fundamento nas mãos de quem não sabe.

O meu diferencial não é digitar código mais rápido. Nunca foi. É saber — depois de anos de experiência, de erros, de incidentes, de refatorações dolorosas e de decisões que funcionaram — o que construir, quando, como e por quê.

Isso a IA ainda não faz por mim. E enquanto não fizer, meu trabalho continua sendo meu.

Leia Também

Referências