--- title: "Vibe coding: como começar bem | CommitCycle" description: "O que é vibe coding, onde ele funciona de verdade, onde para de funcionar e as respostas ao que as pessoas perguntam antes da primeira tentativa séria." url: https://commitcycle.com/pt-br/insights/vibe-coding-first-steps/ language: pt-BR --- # Vibe coding, e a primeira semana que não termina em bagunça > O que é vibe coding, onde ele funciona de verdade, onde para de funcionar e as respostas ao que as pessoas perguntam antes da primeira tentativa séria. 14 de agosto de 2026 · atualizado 18 de agosto de 2026 [Paulo L.](https://commitcycle.com/pt-br/about/) AI Growth Hacker Vibe coding é construir descrevendo o que você quer e aceitando o que o modelo escreve sem ler tudo. Funciona quando errar custa pouco e o feedback é imediato — protótipos, scripts, ferramentas descartáveis. Para de funcionar quando o código sobrevive à sessão, porque o que você pulou é justamente o que depois vai precisar ser entendido. Vibe coding é construir descrevendo o que você quer e aceitando o que o modelo escreve sem ler tudo. O termo é do Andrej Karpathy, e o que distingue não é a IA ter escrito o código — isso hoje é comum — mas que **ninguém revisou linha por linha**. Isso é uma troca, não um erro. Se é uma boa troca depende inteiramente de uma pergunta: por quanto tempo esse código precisa viver? ## Onde o vibe coding funciona de verdade? **Protótipos que você pretende apagar.** O custo de errar é jogar fora, que era o que você ia fazer de qualquer jeito. **Scripts e ferramentas de uso único.** Uma coisa que reformata um CSV, popula um banco de dados, faz scraping de uma página uma vez só. Se produz a saída certa, acabou; ninguém vai manter aquilo. **Aprender o formato de algo desconhecido.** Conseguir um exemplo funcionando de uma biblioteca que você nunca usou é mais rápido assim do que ler a documentação antes, e você pode ler a documentação depois com uma coisa concreta na frente. **Qualquer coisa em que o feedback seja imediato e total.** Se funciona, funciona, e você descobre em dez segundos. O fio comum é que **errar é barato e óbvio**. Essa é a condição. Não o tamanho do projeto, nem a linguagem, nem se é “de verdade” — só se um erro aparece na hora e custa pouco. ## Quando ele para de funcionar? No momento em que o código sobrevive à sessão que o produziu. Isso não é um julgamento moral. É aritmética: você comprou velocidade pulando o entendimento, e a conta chega quando alguém precisa mudar código que ninguém entendeu quando foi escrito. Se ninguém nunca mudar, a conta nunca chega e a velocidade saiu de graça. Esse é um desfecho real e acontece muito. O que faz dar errado é não saber em qual dos dois casos você está. Quase toda experiência ruim começa como um protótipo que virou crítico em silêncio, sem ninguém decidir nada. ## Como sei em qual caso estou? Três perguntas, e elas são sobre a situação mais do que sobre o código: | Pergunta | Vibe coding vale quando | Deixa de valer quando | | --------------------------------------- | --------------------------- | ---------------------------------------- | | **Com que rapidez descubro que errei?** | Em segundos. Você roda e vê | Em semanas, por um cliente | | **Quanto custa errar?** | Você apaga e começa de novo | Dinheiro, dados ou a confiança de alguém | | **Quem mais depende disso?** | Ninguém | Qualquer pessoa que não seja você | As três apontando para o mesmo lado é o caso para o qual isso foi feito. As três apontando para o outro lado e você não está fazendo vibe coding, está apostando com passos a mais. O útil é que **isso se decide por peça de trabalho, não por projeto**. A mesma tarde comporta um script descartável que você nunca lê e uma mudança de permissões que você lê duas vezes. Tratar um repositório inteiro como um ajuste único é o que produz os dois erros comuns: ler tudo num protótipo, e não ler nada na parte que morde. ## O que eu nunca deveria fazer com vibe coding? Uma lista curta, e o motivo é o mesmo em todos os itens: - **Autenticação e permissões.** Errar aqui não lança erro. Deixa a pessoa errada entrar em silêncio, e você descobre por outra pessoa. - **Dinheiro.** Preços, cobranças, estornos, moeda. Um off-by-one num laço é um bug; um off-by-one em centavos é um chargeback e um e-mail que você não quer escrever. - **Qualquer coisa que apague.** Exclusões em cascata principalmente. O teste dessa categoria é se existe um desfazer. - **Migrações de banco de dados.** Rodam uma vez, contra dados reais, e a falha é descoberta depois que os dados já se foram. - **Tudo que lida com dados pessoais dos outros.** Errar aqui vem com um regulador junto. Repare no que _não_ é o critério: dificuldade. Alguns desses são código fácil. A propriedade que compartilham é que **errar não se anuncia sozinho** — que é exatamente a suposição sobre a qual o vibe coding roda. Isso não é “escreva você mesmo”. É “leia esse aqui”. Deixe o modelo escrever, depois leia de verdade o que ele escreveu, e peça que explique as partes que você não conseguir acompanhar. A leitura é todo o custo, e nessas cinco vale a pena pagar. ## A primeira semana **Mantenha as sessões curtas, e termine cada uma em algo que funciona.** Esse é o hábito de maior retorno e não tem nada a ver com a IA. Uma sessão longa acumula decisões que ninguém escreveu, e quando enfim algo está errado não existe ponto para voltar. Sessões curtas com um commit que funciona no fim te dão um lugar para onde voltar. **Leia as partes caras.** Não tudo — isso derrubaria o propósito. Leia qualquer coisa que toque dinheiro, autenticação, exclusão de dados, ou código em que outra pessoa também trabalha. O resto, passe o olho. A habilidade construída aqui é triage, e é uma habilidade real: saber onde errar sai caro é a maior parte do que engenheiros seniores sabem. **Diga o que ele não pode fazer.** Quase todo mundo descreve o que quer e para por aí. A instrução que mais economiza tempo é a que exclui coisas — _não toque no módulo de auth, não adicione dependências, não mude o schema do banco_. Modelos são prestativos e vão fazer com prazer uma coisa útil que você não queria. **Rode antes de acreditar.** Código gerado que parece certo e não roda é a falha isolada mais comum, e a mais barata de pegar. **Perceba quando o protótipo deixou de ser protótipo.** Costuma existir um momento específico: outra pessoa abre, ou vai para a frente de um usuário, ou você faz deploy. Esse é o momento em que a troca muda, e a resposta honesta é voltar e ler direito. ## Como é uma boa sessão, do começo ao fim Concretamente, porque “mantenha as sessões curtas” é um conselho com o qual você concorda e mesmo assim não aplica: 1. **Comece de um commit.** Não de um repositório arrumado — de um com commit. Esse é o ponto de save, e leva dez segundos. 2. **Diga o objetivo e o limite na mesma mensagem.** O que você quer, e o que está fora de alcance. A segunda metade é a que as pessoas pulam. 3. **Deixe trabalhar sem interromper.** Corrigir o rumo no meio do voo produz uma mudança que é metade de um plano e metade de outro, o que é mais difícil de ler do que qualquer um dos dois. 4. **Leia o diff, não a base de código.** Quantos arquivos, quais arquivos, e se apagou algo que você não pediu para apagar. 5. **Rode.** Antes de acreditar em qualquer parte. 6. **Faça commit, ou jogue a sessão inteira fora.** Os dois são desfechos aceitáveis. O que não é aceitável é carregar um estado meio pronto para a próxima sessão. Cerca de uma hora é onde isso costuma cair para a maioria, e o número importa menos que o formato: **a sessão é a unidade que você pode jogar fora.** Assim que uma sessão está longa a ponto de descartá-la ser impensável, você perdeu a propriedade que tornava toda a abordagem segura — e isso acontece de forma gradual, que é justamente por que vale a pena ficar de olho. ## As perguntas que as pessoas realmente fazem ### “Eu ainda sou um desenvolvedor de verdade fazendo isso?” A pergunta por baixo é se você está construindo uma habilidade ou fugindo de uma. Está construindo uma — triage, especificação, saber onde o risco mora — e não é a mesma habilidade de escrever a sintaxe você mesmo. As duas são reais. Nenhuma se basta sozinha. ### “Como impeço que ele invente bibliotecas que não existem?” Rode o código. Imports alucinados falham na hora, o que faz dessa a classe de erro menos perigosa. Preocupe-se mais com os que rodam. ### “Ele reescreveu algo que eu não pedi para tocar.” Muito comum, e a correção normal é dizer o que está fora de alcance antes de começar. Num repositório em que outras pessoas trabalham, isso deixa de ser um incômodo e vira o problema de verdade — o que tem [um post próprio](https://commitcycle.com/pt-br/insights/vibe-coding-shared-repository/). ### “Devo fazer commit de código que não li?” Em algo descartável, sim. Em algo compartilhado, você está entregando aos seus colegas um diff sobre o qual não consegue responder perguntas, e isso é um problema social antes de ser técnico. ### “É assim que times profissionais trabalham agora?” Em parte, e honestamente a resposta ainda está se movendo. O que está claro é que a restrição saiu de _com que rapidez isso pode ser escrito_ para _com quanta confiança isso pode ser mudado depois_, e os times que vão bem são os que tratam isso como o eixo do desenho. ## Para onde isso está indo, e o que a gente faz a respeito Tudo acima funciona para uma pessoa sozinha na própria máquina. As falhas interessantes começam quando o repositório é compartilhado — quando o código gerado é localmente razoável e globalmente errado porque o modelo não conseguia ver uma convenção que mora na cabeça de alguém. Esse é o problema em que o CommitCycle trabalha: cada agente ganha um grant preso a uma task e a um branch que expira sozinho, os paths que doeriam carregam um owner, e cada task fecha com um registro do que declarou contra o que tocou. Sendo direto sobre onde isso está: o plugin instala hoje o enforcement, e o pacote `commitcycle` no npm instala a CLI — o processo sem o muro. O board hospedado é só por convite enquanto isso é pequeno. E nada disso é o que você precisa na sua primeira semana de vibe coding — na primeira semana você precisa de sessões curtas e do hábito de ler as partes caras. Na semana seguinte, quando você já tiver decidido que a coisa vai existir além da sexta, a pergunta sai de hábitos e vai para setup: [o que ter no lugar antes do primeiro prompt](https://commitcycle.com/pt-br/insights/vibe-coding-setup/), e por que cada peça está ali. ## Perguntas que esta página responde ### O que é vibe coding? Construir descrevendo o que você quer e aceitando o que o modelo escreve sem ler tudo. O termo foi cunhado por Andrej Karpathy. O que distingue não é a IA ter escrito o código, é ninguém ter revisado linha por linha — o que é uma troca deliberada, não um acidente. ### Vibe coding é má prática? Não por natureza. É uma troca: velocidade agora em troca de entendimento depois. Num protótipo que você vai apagar na sexta essa troca sai de graça, e recusar só te deixa mais lento. Em código que ainda vai estar rodando daqui a seis meses, você está tomando emprestado contra uma dívida que alguém vai ter que pagar. ### Quando o vibe coding para de funcionar? Quando o código sobrevive à sessão que o produziu. No momento em que alguém precisa mudar código que ninguém entendeu quando foi escrito, a velocidade que você comprou já foi gasta e os juros começam. ### Eu preciso ler o código que o modelo escreve? Não todo, e é esse o ponto. Leia as partes onde errar sai caro: qualquer coisa que toque dinheiro, auth, exclusão de dados ou o código de outro time. O resto, passe o olho. A habilidade é saber o que é o quê, não ler tudo nem não ler nada. ### Qual é o erro mais comum da primeira semana? Deixar uma sessão se estender demais. Sessões longas acumulam decisões que ninguém escreveu, e quando algo enfim está errado não existe ponto nenhum para voltar. Sessões curtas com um commit que funciona no fim de cada uma são o hábito de maior retorno que existe. ### Dá para fazer vibe coding numa base de código já em produção? Dá, e é de onde vem a maioria dos relatos de dor. A falha raramente é código ruim: é código localmente razoável e globalmente errado, porque o modelo não conseguia ver uma convenção que mora na cabeça de alguém e não no repositório. ### Como sei se o vibe coding é seguro para o que estou construindo? Três perguntas decidem: com que rapidez você descobre que errou, quanto custa quando descobre, e se mais alguém depende desse código. Feedback rápido, mais um erro barato, mais ninguém mais mexendo nele é o caso para o qual o vibe coding foi feito. Mude qualquer um dos três e a troca se desloca. ### O que eu nunca deveria fazer com vibe coding? Qualquer coisa cuja falha é silenciosa, atrasada ou paga por outra pessoa: autenticação e permissões, dinheiro, qualquer coisa que apague, migrações de banco de dados, e tudo que lida com dados pessoais dos outros. A propriedade em comum não é a dificuldade, é que errar não se anuncia sozinho. ### Como é uma boa sessão de vibe coding? Comece de um estado com commit, diga o que você quer e o que está fora de alcance, deixe trabalhar, leia o diff em vez do código todo, rode, e faça commit antes de começar a próxima coisa. O commit em cada ponta é o que transforma a sessão numa unidade que você pode jogar fora.