Vibe coding era para projetos descartáveis

Em fevereiro de 2025, Andrej Karpathy, criador do termo vibe coding, publicou um tweet que ele mesmo descreveu como "um pensamento de banho que disparei sem pensar." O conceito era simples: você descreve o que quer em linguagem natural, a IA constrói e itera, e você esquece que o código existe. O termo ganhou vida própria — virou a palavra do ano de 2025 no dicionário Collins, ganhou artigo na Wikipedia e passou a definir como uma geração inteira pensa sobre desenvolvimento com IA. Um ano depois, Karpathy escreveu sobre o aniversário do conceito. O que ele disse muda a conversa.

O que Karpathy disse de fato: vibe coding era para protótipos, não para produção

Nas palavras do próprio Karpathy, ao revisitar o conceito:

"Na época, a capacidade dos LLMs era baixa o suficiente para que o vibe coding fosse usado principalmente em projetos descartáveis, demos e explorações. Era divertido e quase funcionava."

Projetos descartáveis. Quase funcionava.

Não é o que a maioria das pessoas entendeu pelo caminho. O frame "esqueça que o código existe" foi aplicado em sistemas com usuários reais, dados reais e regras de negócio que custam dinheiro quando falham. A linha entre demo e produto sumiu — e o vibe coding atravessou junto.

Agentic engineering: o que Karpathy propõe para quem trabalha com código de verdade

Para o que está acontecendo agora com profissionais que levam desenvolvimento a sério, Karpathy propôs outro nome: agentic engineering. A diferença que ele desenha é precisa: você não escreve o código 99% do tempo — você orquestra agentes que fazem isso e age como supervisão. A palavra engineering é intencional: há uma arte, uma ciência, uma profundidade que se aprende e se desenvolve.

Não é sobre esquecer que o código existe. É sobre entender o código bem o suficiente para saber quando a IA errou.

Esse é o mesmo princípio que usamos quando implementamos agentes de IA para empresas: contexto bem definido, arquitetura prévia, validação humana nas decisões que custam caro quando falham.

Por que engenheiros sênior entregam 2,5x mais código de IA do que juniores

A Fastly entrevistou 800 desenvolvedores sobre o uso de IA no trabalho. O resultado vai na direção contrária da narrativa de equalização que domina a conversa:

Não porque os juniores não sabem usar os modelos. Às vezes sabem até melhor. O gap não está na geração do código — está na validação.

Quando a IA entrega mil linhas que compilam, passam nos testes e parecem corretas, o sênior identifica a consulta escondida que vai travar o banco sob volume, o ciclo de dependência que vai explodir daqui a três meses, a lógica de negócio tecnicamente certa mas operacionalmente errada. O junior aceita — porque ainda não tem o histórico de ter visto essas coisas falharem em produção.

A IA reduziu o custo de criar código para quase zero. O custo de avaliar o que foi criado ficou com quem tem anos de contexto. E esse contexto só se constrói fazendo, errando, consertando.

O colapso silencioso do desenvolvedor júnior: o que os dados mostram

Os números são diretos:

A conta é fácil: uma licença de assistente de código custa $10–$39 por mês. Um junior nos EUA custa $70k–$90k por ano, mais seis a doze meses até gerar valor real. As empresas estão otimizando. Faz sentido no curto prazo.

O problema é o prazo seguinte.

O modelo tradicional de formação era quase medieval: o sênior arquitetava, o junior implementava, e pelo atrito diário de code reviews e problemas reais o conhecimento se transferia. O junior de 2024 era o arquiteto de 2032. Essa cadeia foi cortada. A McKinsey projeta escassez de até 14 milhões de desenvolvedores seniores até o final desta década se o ritmo de formação não for reinventado. A empresa que economizou $90k cortando um junior em 2025 pode estar comprando uma crise de liderança técnica que vai custar muito mais em 2035.

O degrau mais baixo da escada foi removido. A escada ainda existe.

Para os times que continuam crescendo nesse cenário, a saída não é esperar a formação se reinventar — é automatizar o trabalho repetitivo que não exige julgamento e concentrar o time humano nas decisões que realmente custam caro quando erram.

O que os bootcamps não estão contando sobre IA como diferencial

Quando a IA explodiu, muitos bootcamps pivotaram para "Engenharia de Prompt" e "Integração de IA." Faz sentido como estratégia de marketing. Mas uma pesquisa com lideranças de engenharia de ex-Meta, Netflix e startups avançadas mostrou que:

O que eles continuam procurando é o que sempre procuraram: alguém que entenda o que acontece quando a abstração falha. A IA não substituiu essa exigência — ela só tornou mais visível quem tem e quem não tem.

Vender "aprenda IA e entre no mercado" para quem não tem base técnica é, hoje, uma promessa de marginalização com embrulho de oportunidade.

Como apliquei agentic engineering em produção — e o que isso mostrou

Recentemente implementei uma feature complexa no EpicFlow — a plataforma de automação de WhatsApp que desenvolvemos — em uma tarde. Antes levaria dias.

Não foi vibe coding.

Usei o Claude Code, mas com contexto específico: arquitetura do repositório, dependências existentes, regras de negócio do produto. Limitei o acesso da IA aos arquivos relevantes. E auditei cada decisão antes de qualquer commit.

Um desenvolvedor com menos contexto técnico usando a mesma ferramenta geraria código parecido. Talvez até mais rápido. Mas sem o histórico para reconhecer o que está errado numa saída que parece certa, estaria empilhando dívida invisível.

A vantagem não era a ferramenta. Era saber o que perguntar para ela — e o que rejeitar quando ela respondia.

É exatamente essa arquitetura de decisão que aplicamos quando trabalhamos com clientes em consultoria estratégica de IA: o diagnóstico do que a IA deve e não deve fazer dentro da operação específica de cada empresa.

O que muda para times que adotam IA a partir de agora

Karpathy não abandonou o conceito que criou. Ele deixou claro que era para um momento específico, com ferramentas de capacidade específica, para projetos de um tipo específico.

O que veio depois — e o que profissionais precisam dominar agora — exige mais. Não mais cliques ou mais prompts. Mais julgamento, mais arquitetura, mais responsabilidade pelo que os agentes produzem.

É mais difícil de aprender e mais difícil de vender num post. Mas é o que vai separar quem realmente entende de quem só surfou a onda.

Para equipes que querem construir essa capacidade internamente, o caminho mais rápido não é um curso de IA genérico — é um workshop estruturado a partir dos processos reais do negócio, com foco em julgamento operacional, não em features de ferramentas.