Executando verificação de segurança...
4
zilvodev
2 min de leitura ·

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

Se você acompanha o mundo de tecnologia, provavelmente já ouviu falar de "vibe coding". A ideia era simples: você descreve o que quer, a IA escreve o código, e você aceita sem entender muito o que tá acontecendo.

O termo foi criado pelo Andrej Karpathy, ex-diretor de IA da Tesla e cofundador da OpenAI.

E agora, em fevereiro de 2026, o próprio Karpathy declarou: vibe coding já era. O novo termo? Agentic engineering.

O que mudou em 1 ano

Quando Karpathy cunhou "vibe coding" no início de 2025, as IAs de código eram boas, mas não tão boas.

Em 2026, a coisa mudou. Modelos como Claude Opus 4.6, GPT-5.3 e Gemini 3 não só escrevem código: eles planejam, testam, corrigem e refatoram. Sozinhos.

Nas palavras do Karpathy: "Programar via agentes LLM está se tornando o fluxo de trabalho padrão para profissionais, mas com mais supervisão e escrutínio."

Não é mais sobre "vibes". É sobre orquestrar agentes que fazem o trabalho pesado.

O que é "agentic engineering"

Em vez de escrever código linha por linha (ou pedir pra IA escrever e aceitar de olhos fechados), você gerencia agentes de IA que executam tarefas específicas.

Um agente cuida da implementação. Outro testa. Outro revisa segurança. Você, o humano, é o arquiteto e supervisor.

Segundo o Karpathy: "Agêntico porque você não está escrevendo código diretamente 99% do tempo. Você orquestra agentes. E engenharia porque existe arte, ciência e expertise nisso."

Os números que confirmam a mudança

  • Lovable atingiu US200 milhões de receita anual em 12 meses. Valuation de US6,6 bilhões.
  • 92% dos devs nos EUA usam IA pra programar diariamente.
  • 41% de todo código escrito no mundo é gerado por IA.
  • 100.000 novos projetos por dia só no Lovable.

Mas os problemas também são reais:

  • 76% das pessoas que começam param em 12 semanas.
  • 45% do código gerado por IA tem vulnerabilidades de segurança.
  • 2,74x mais vulnerabilidades comparado com código humano.

O que muda pra quem tá criando produto com IA

1. Descreva melhor o que você quer

Quanto mais específico, melhor o resultado.

2. Não aceite tudo de olhos fechados

Você não precisa entender cada linha de código. Mas precisa entender a LÓGICA.

3. Segurança não é opcional

Nunca deixe chaves de API no frontend. Sempre use autenticação em rotas sensíveis.

4. Pense como arquiteto

Você define O QUE quer, POR QUE quer, e COMO deve funcionar. A IA cuida do COMO IMPLEMENTAR.

Vibe coding não "morreu". Evoluiu.

A essência está mais viva do que nunca. O que mudou é a maturidade do processo.

Se 2025 foi o ano do hype, 2026 é o ano da realidade.

Post completo: https://blog.zilvo.app/posts/vibe-coding-morreu-karpathy-agentic-engineering/

Fontes: The New Stack, Glide Blog, TechCrunch

Fonte: https://blog.zilvo.app/posts/vibe-coding-morreu-karpathy-agentic-engineering/

Carregando publicação patrocinada...
1
1
1
teknolista
  1. Descreva melhor o que você quer

Seria por acaso o tal spec-driven-develop, ou algo do tipo?

Uma dúvida que tenho é até onde vale a pena detalhar a especificação; ainda to trilhando isso...

1
cleitonper

Ó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.