Vibe coding vs agentic coding: o guia de decisão para o fundador não-técnico

Um fundador com quem trabalhamos, ex-PE associate e hoje CEO de um SaaS vertical para clínicas, abriu um Loom no mês passado com a frase “vibe codei isso no fim de semana, dá pra terminar?”. O Loom mostrava um fluxo de agendamento funcionando, um gerador de notas fiscais funcionando, e o começo de um produto de verdade. Mostrava também três versões do mesmo schema de banco em três arquivos diferentes, duas implementações concorrentes de auth e uma pasta chamada final_v3_actually_final com um app React inteiro que ele tinha esquecido que começou.

Vibe coding levou ele a uma demo em dois dias. Agentic coding teria levado ele a um produto. Ele usou a ferramenta certa para o estágio errado, e a conta da limpeza foi oito semanas do nosso time.

Este é o texto sobre vibe coding vs agentic coding para fundadores não-técnicos. Os dois são reais. Os dois funcionam. A escolha entre eles é uma decisão de estágio, não um debate de metodologia, e errar essa escolha virou um dos erros mais caros que um fundador pode cometer no primeiro ano.

O que vibe coding é, na prática

Vibe coding é o termo que Andrej Karpathy popularizou no começo de 2025 para descrever um jeito específico de escrever software com um LLM. Você descreve em linguagem natural o que quer, aceita o código que o modelo produz, roda, e quando quebra você descreve o bug de volta para o modelo e aceita o conserto. Você não lê o código com cuidado. Você “se entrega às vibes”, como ele mesmo disse, e julga o resultado por se a tela faz o que você queria.

A entrega do vibe coding é um artefato funcionando. O custo é que você não sabe o que tem dentro. O modelo escolheu a estrutura, o modelo escolheu as bibliotecas, o modelo escolheu o padrão de auth, e você é o product owner de um código que você não sabe ler.

Para um protótipo de fim de semana, está ótimo. Para uma demo clicável testar uma hipótese com cinco clientes, está mais que ótimo. Para qualquer coisa que precise continuar rodando enquanto clientes dependem dela, isso é um instrumento de dívida.

O que agentic coding é, na prática

Agentic coding é o que acontece quando os mesmos LLMs são embrulhados em um loop de planejamento, um loop de uso de ferramentas e um loop de feedback, e apontados para uma codebase real sob práticas de engenharia reais. O agente lê o código existente, planeja as mudanças, escreve testes, roda, e itera até o trabalho estar comprovadamente pronto. Um engenheiro sênior revisa e dá merge.

A entrega do agentic coding é software no ar. O modelo digitou, mas as decisões de engenharia (o que construir, onde colocar, como testar, como falhar com segurança) foram feitas por uma pessoa que responde por elas. A codebase tem forma. O trabalho novo encaixa nessa forma. Quando algo quebra, alguém consegue achar a causa sem precisar chamar o Karpathy.

Se vibe coding é esboço, agentic coding é projeto. Os dois deixam linhas no papel. Só um deles é uma coisa que você consegue entregar para um construtor.

Vibe coding e agentic coding são a mesma coisa?

Não, e a confusão entre os dois é o que faz a ferramenta errada continuar sendo escolhida na Series A.

A confusão até faz sentido. Os dois envolvem uma pessoa digitando em uma caixa de chat e uma IA produzindo código. A ação mecânica é idêntica. A diferença está no que acontece em volta da saída da IA.

Vibe coding não tem superfície de revisão. O autor é juiz e jurado, e o critério é “a tela fez a coisa”. Agentic coding tem as mesmas superfícies de revisão que um time de engenharia de verdade sempre teve: code review, suite de testes, pipeline de deploy, plantão. A IA fica dentro dessa máquina. A máquina continua funcionando.

Um teste útil: se a entrega quebrar daqui a seis meses, quem conserta, e como essa pessoa entende o que foi construído? No vibe coding, a resposta é “reescreve a partir do histórico de prompts, se alguém lembrar o que foi pedido”. No agentic coding, a resposta é “lê o código, lê os testes, lê os PRs”.

Onde vibe coding realmente funciona

Já usamos vibe coding aqui. Vamos continuar usando. Tem três lugares onde ele paga o que vale.

Protótipos descartáveis que existem para matar uma ideia. Se você consegue construir a coisa em um sábado e a resposta é “não, cliente nenhum quer isso”, você economizou um trimestre de engenharia de verdade. O descartável é o ponto. Não bota cliente em cima. Não bota a sua rodada em cima.

Experimentos internos onde você é o único usuário. Um script de admin improvisado, uma limpeza pontual de dados, um substituto temporário de Google Sheets que vive seis semanas durante um lançamento. Se quebrar, você conserta ou abandona. Ninguém mais depende daquilo.

O primeiríssimo MVP, com prazo de validade firme. Esse é o perigoso. Vibe coding produz um MVP crível em um fim de semana, e a credibilidade da demo seduz o fundador a deixar cliente pagante usando. A regra que damos para clientes: se você vibe codou o MVP, tem noventa dias para trocar a fundação ou matar o produto. Qualquer outra coisa é acidente em câmera lenta.

O padrão nos três casos é o mesmo. A entrega tem vida curta conhecida e a consequência dela quebrar é limitada. No instante em que o produto cruza para “tem gente dependendo disso e a gente não vai parar”, vibe coding é a ferramenta errada.

Onde agentic coding realmente funciona

Agentic coding é a ferramenta certa em todo lugar onde vibe coding é a errada. E isso inclui a maior parte do que uma startup de fato entrega.

O ganho sobre um time puro de humanos não é “a IA escreve código, então não precisamos de engenheiros”. É que um time pequeno de seniores produz consideravelmente mais. A gente já mediu algo como 40 a 60 por cento de aumento de output por engenheiro no tipo de trabalho de produto CRUD-pesado que enche a maior parte de um roadmap early-stage. O engenheiro sênior continua fazendo o pensamento que sustenta tudo: a arquitetura, o modelo de dados, os modos de falha, os limites de segurança. O agente absorve a digitação, o boilerplate e uma parte significativa da escrita de testes.

A armadilha a evitar é usar agentic coding sem o sênior. Agentes vão alegremente produzir código arquiteturalmente errado com toda confiança e cobertura de testes completa da coisa errada. Eles não são revisores que sustentam decisão. São colaboradores juniores muito rápidos. O engenheiro sênior continua sendo o revisor que sustenta a decisão, e a startup que demite os seniores porque “agora os agentes fazem o trabalho” está repetindo o mesmo erro que a onda de no-code ensinou. Confunde a aparência de alavanca com a substância dela.

Isso conecta direto com um conselho que já escrevemos: o CTO que você não consegue contratar quase nunca é o seu problema real no Pre-Seed e Seed. O engenheiro sênior é. Vibe coding não muda essa conta. Agentic coding deixa o sênior mais produtivo, o que de fato torna a conta menos dolorosa, mas não elimina a necessidade.

Vibe coding é melhor que codar?

Essa é a pergunta errada, e a gente recebe alguma versão dela em toda call de fundador este ano.

É a pergunta errada porque “codar” não é uma única atividade. Escrever a primeira prova de que um fluxo é possível é diferente de escrever a versão em que um hospital vai confiar. A primeira quer velocidade e baixa penalidade por estar errada. A segunda quer correção e baixa penalidade por mudar depois. Ferramentas diferentes ganham em estágios diferentes.

Um enquadramento mais útil: vibe coding é mais rápido que agentic coding na primeira hora de um projeto, e mais lento que agentic coding em toda hora seguinte. O ponto de virada acontece em algum lugar perto da terceira feature, quando a codebase é grande o bastante para o modelo precisar de um contexto que o prompt não consegue entregar facilmente, e mudanças em uma parte do sistema começam a quebrar outras partes que o modelo nunca soube que existiam.

Os fundadores que mais tiram valor de codificação assistida por LLM são os que usam vibe coding como teste de viabilidade e depois trocam para um processo de engenharia de verdade (agentic ou não) para a construção. Os fundadores que se machucam são os que nunca fazem essa troca.

Vibe coders entendem o próprio código?

Resposta honesta: geralmente não, e esse é o desenho.

A proposta inteira do vibe coding é que você não precisa entender o código para entregar o artefato. Isso é uma economia real para um esboço. Vira um passivo real no momento em que você precisa mudar o artefato. Toda mudança é mais uma rodada de descrever-e-rezar. Todo bug é debugado pelos sintomas, não pelas causas. E toda pressão externa (uma revisão de segurança, uma auditoria SOC 2, um parceiro de integração pedindo para ver a sua spec de API) expõe a lacuna.

A gente já reconstruiu três sistemas vibe-coded este ano. O padrão foi idêntico nos três. O fundador ficou sem vibes mais ou menos no terceiro mês, quando o modelo começou a insistir em mudanças que quebravam produção e se recusava a lembrar restrições que estavam dois prompts atrás. Pedir para o modelo consertar o trabalho do próprio modelo a partir de certo nível de complexidade é uma esteira. Em algum momento você desce e paga um engenheiro para ler a coisa toda.

Cobramos menos para reconstruir um sistema vibe-coded do que para resgatar um no-code, mas mais do que para construir o mesmo produto do zero. O caso do meio é o mais caro dos três. A codebase tem forma, mas a forma está errada, e desfazer essa forma demora mais do que começar limpo teria demorado.

Uma regra de decisão por estágio

O jeito mais limpo que a gente achou de pensar em vibe coding vs agentic coding é por estágio e por usuário.

Se a pergunta é “essa ideia funciona, e só eu vou tocar nela”, vibe code. Vai rápido, joga fora, e trate qualquer coisa que sobrar como acidente feliz.

Se a pergunta é “quero colocar isso na frente de cinco clientes para ver se eles puxam da minha mão”, vibe code a demo, mas escreva o contrato com você mesmo antes de começar. Você não vai deixar a demo virar o produto. No instante em que o quinto cliente diz sim, você começa a construção real.

Se a pergunta é “isso vai pra produção, clientes vão depender, e a gente não vai desligar em seis semanas”, isso é território de agentic coding, com um engenheiro sênior segurando a caneta e o LLM segurando o teclado. O sênior é não-negociável. A suite de testes é não-negociável. A pipeline de deploy é não-negociável. Nenhuma dessas coisas vira negociável só porque tem uma IA no loop.

Se a pergunta é “a gente já vibe codou o MVP e clientes estão usando”, você tem um relógio. Noventa dias, e ou a fundação é trocada ou o produto é desligado. Quanto mais o relógio corre, mais cara fica a reconstrução, e a reconstrução vai acontecer de qualquer jeito. Vimos isso se desenrolar em seis engagements de cliente no último ano. Sempre se desenrola. Se desenrola mais rápido do que você espera.

A escolha real do fundador não-técnico

A pergunta sobre vibe coding vs agentic coding é enquadrada como uma briga entre duas técnicas de IA. Não é. É uma pergunta de estágio vestida de roupa de ferramenta.

Você está decidindo, em cada superfície de produto, quanto você quer que o trabalho dure. Vibe coding otimiza para a primeira versão de uma resposta. Agentic coding otimiza para a versão que sobrevive à segunda versão. Os dois têm lugar. Nenhum dos dois é religião.

Os fundadores que acertam isso tratam vibe coding do mesmo jeito que tratam um modelo financeiro de guardanapo: útil, rápido, joga fora antes que ele tome uma decisão de verdade por você. Agentic coding é o demonstrativo auditado. Você não toca uma empresa pelo guardanapo. Você também não toca uma empresa pelas vibes.

Se você quer uma versão mais afiada desse raciocínio aplicada ao seu produto, é metade das conversas que estamos tendo com fundadores agora. Leia nosso texto sobre o que um MVP de fato é para o enquadramento que usamos para traçar a linha. E se você está decidindo se traz uma software house para o jogo, a mesma lógica de estágio vale. Escolha o parceiro cujo padrão é o próximo estágio, não o atual.

A síntese cabe em uma frase. Vibe coding constrói a pergunta. Agentic coding constrói a resposta. Não entregue a pergunta.