Vibe coding morreu? O próprio criador do termo diz que sim

Essa é a pergunta mais importante. Vou ler teu post.

As pessoas param nas 12 semanas porque batem no muro da manutenção. Criar é empolgante, manter é tedioso. A IA resolve a criação, mas quando o bug aparece, não tem prompt que salve se você não entende o código.

O padrão que vejo: semana 1-4 euforia, semana 5-8 frustração (bugs, performance), semana 9-12 desistência. Quem sobrevive geralmente teve que aprender o mínimo de fundamentos.

Justo sobre o título. O objetivo era provocar, e o texto tenta entregar mais nuance.

Sobre o dado dos 92%, vem do GitHub Developer Survey 2025. O Stack Overflow Developer Survey 2024 já mostrava 76%. A questão do rótulo "vibe coding" é boa: na prática, a maioria desses devs está usando Copilot como autocomplete glorificado, não "vibing" de verdade. A fronteira entre assistência e vibe tá cada vez mais borrada.

Sobre se são devs "de verdade": acho que essa distinção vai perder sentido rápido. Se o cara entrega software funcionando, importa como ele escreveu?

Ótima pergunta, tenho lidado com isso nas últimas semanas, e cheguei num ponto que tem me atendido bem.

Costumo dividir a documentação dos meus projetos nas seguintes partes:

1. Estilo de código
   Aqui ficam as regras de como a IA deve escrever código, padrão de nomenclatura de classes, funções e variáveis. Vai criar um novo ebdpoit? Divida nesses 3 arquivos: service, view e serializer. Vai criar uma tabela nova no banco de dados? Escreva o nome das tabelas e colunas em português brasileiro. Essas regras ficam num diretório docs/styleguide e com um arquivo pra cada área, como python, django e banco-de-dados
2. Decisões de arquitetura
   Na pasta docs/adr deixo uma lista de arquivos listando quais as decisões de arquitetura foram tomadas e porque. Usa redis pra filas e não Rabbitmq? Aqui é o local ideal para descrever o porquê.
3. Decisões de funcionalidades
   Na pasta docs/fdr deixo as principais decisões relacionadas à funcionalidades específicas. Tem uma integração com sistema legado que roda de forma assíncrona? Aqui é o local ideal pra explicar o porquê.
4. Diagramas
   Na pasta docs/diagrams ficam os principais diagramas do projeto, normalmente usando markdown e mermaid. C4, DER e alguns diagrams de fluxo ficam aqui.

Com essa estrutura, dá pra trazer bastante contexto pra IA antes dela começar a gerar código. Para novas funcionalidades, começamos escrevendo a FDR (Feature Description Record), junto com a própria IA, e com base nela a IA gera o código.

Se algo fugir das especificações, como por exemplo, a IA escreveu toda a implementação na view, podemos pedir pra ela revisar o styleguide e decisões de arquitetura e começar novamente.

A ideia dessa abordagem é trazer o máximo de decisões que normalmente estão espalhadas em diversos lugares, ou até mesmo decisões verbais que são passadas entre os membros do time, para dentro do repositório, visando facilitar esse processo de desenvolvimento mais focado em especificações do que em código fonte.

Exatamente, spec-driven development é o nome formal. Na prática é isso: quanto mais contexto você dá pro modelo antes de pedir código, melhor o resultado.

Sobre até onde vale detalhar: minha regra é focar no COMPORTAMENTO esperado, não na implementação. Tipo: "quando o usuário clica em X, acontece Y" em vez de "crie um onClick handler que chama a API". O modelo decide o como, você define o quê.

Se a spec está grande demais, provavelmente o escopo está grande demais. Quebra em pedaços menores.

O número de 76% vem do Stack Overflow Developer Survey 2024 (uso de IA no workflow). Mas a velocidade assusta: em 2023 era ~44%, em 2024 saltou pra 76%. Se a tendência seguir, 80% em 2030 seria pessimismo demais.

Mas tem um detalhe: "usar IA" é amplo. Vai de autocomplete básico até gerar sistemas inteiros com prompt. A adoção superficial já é quase universal, a adoção profunda (agentes autônomos, vibe coding real) ainda tá em early adopter.

Entendo o incômodo. Tem muito conteúdo genérico que parece saído de uma linha de montagem. Mas acho que o problema não é a ferramenta, é a preguiça de quem usa. Dá pra usar IA como base e depois colocar opinião, contexto, personalidade. O ruim não é usar IA pra escrever, o ruim é publicar sem ler o que a IA escreveu.

Ponto válido. Todo mundo tem incentivos, inclusive quem criou o termo. O Karpathy trabalhou na Tesla e na OpenAI, é investidor anjo e tem audiência pra monetizar. Não significa que a análise dele esteja errada, mas é saudável ter esse filtro.

Por isso tentei trazer dados de outras fontes no texto (Stack Overflow, Lovable, etc.) pra não depender só da narrativa de uma pessoa.