Cursor vibe coding: como conduzir uma tarefa descrevendo o que você quer em vez de digitar o código?

Descrever a tarefa e deixar o editor escrever o código deixou de ser curiosidade e virou rotina de muita gente 🙂

O termo vibe coding foi cunhado pelo Andrej Karpathy num tweet de 2 de fevereiro de 2025, aquele do "There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists"

E o exemplo que ele citou no tweet era justamente o Cursor Composer com Sonnet

Ou seja: o Cursor não pegou carona nessa história, ele estava lá no marco zero

Só que "esquecer que o código existe" funciona MUITO melhor quando você sabe conduzir a conversa

Neste post eu mostro o fluxo completo: dar contexto, planejar, rodar, revisar o diff e corrigir o rumo quando a IA sai da linha

Bora ver na prática?

O que você precisa antes de começar

O Cursor é feito pela Anysphere, e é um editor que você instala na máquina e abre um projeto dentro, igual você já faz hoje

Pra testar sem dor, o plano Hobby é gratuito, não pede cartão de crédito e tem uma quantidade limitada de requisições ao Agent

Quem cria conta também ganha um teste Pro de 14 dias, então dá pra sentir o fluxo completo antes de decidir qualquer coisa

Os planos individuais na página oficial estão assim:

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O modelo da casa é o Composer 2.5, disponível no Cursor desde 18 de maio de 2026, com melhora em tarefas longas e em seguir instruções complexas

O preço por token divulgado pelo próprio Cursor é US$ 0,50/M de entrada e US$ 2,50/M de saída no Standard, e US$ 3,00/M de entrada e US$ 15,00/M de saída no Fast, que é o padrão

E o Git, precisa mesmo?

Precisa, e essa é a parte que muita gente pula

O Cursor tem checkpoints pra desfazer o que o agente fez, mas a documentação diz com todas as letras que checkpoints não são controle de versão

Então abra o projeto num repositório Git, com tudo commitado, antes do primeiro prompt

Já me ferrei uma vez por confiar no "desfazer" da ferramenta em vez do meu próprio histórico

Passo a passo: conduzindo uma tarefa no Cursor pela descrição

A ideia aqui não é mandar um pedido gigante e torcer

É um ciclo: entender, planejar, contextualizar, rodar, revisar, corrigir

1. Entenda antes de mudar, no modo Ask

O modo Ask é somente leitura: ele pesquisa na sua base de código e responde, sem fazer nenhuma alteração

É o modo ideal pra perguntar "onde fica a autenticação nesse projeto?" antes de pedir qualquer mudança

Pra alternar entre os modos, o atalho é Ctrl+. direto no input do agente

O erro comum deste passo: já abrir no modo Agent e mandar mexer numa parte do código que você ainda não entendeu

2. Planeje antes de gerar código, com o Plan Mode

No input do agente, Shift+Tab inicia o planejamento

O agente pesquisa a base, faz perguntas de esclarecimento e devolve um plano de implementação revisável antes de escrever qualquer linha

O blog oficial do Cursor trata planejar antes de gerar código como a mudança de maior impacto no resultado, citando um estudo da University of Chicago segundo o qual desenvolvedores experientes tendem a planejar antes de gerar

Se você quiser ir mais fundo nessa fronteira entre planejar e sair codando, eu já comparei spec-driven development e vibe coding por aqui

O erro comum deste passo: responder as perguntas de esclarecimento com "tanto faz, pode escolher" e depois reclamar da escolha 😛

3. Edite o plano, ele é seu

O plano abre como arquivo Markdown editável dentro do editor, com caminhos de arquivo e referências de código

Dá pra editar, remover passos que não fazem sentido e adicionar contexto que só você sabe

E o botão Save to workspace salva o plano na pasta .cursor/plans/ do projeto

O erro comum deste passo: ler o plano na diagonal, aprovar, e só descobrir no diff que ele ia mexer num arquivo que não devia ser tocado

4. Dê contexto com @ no chat

Contexto manual é anexado digitando @ no chat, que vai sugerindo opções conforme você digita

As opções documentadas incluem @Files, @Folders, @Code, @Docs, @Git, @Past Chats, @Cursor Rules, @Web, @Recent Changes e @Lint Errors

A orientação oficial é direta: use @ quando você JÁ sabe quais arquivos são relevantes

Se você não sabe quais importam, é melhor não anexar nada e deixar o agente encontrar pela busca dele

O erro comum deste passo: entupir o chat de arquivo "por garantia" e apontar o agente pro lugar errado

5. Escreva o pedido específico, não o genérico

Aqui mora a diferença entre um diff que você aceita e um que você joga fora

O contraste que o próprio Cursor usa no blog oficial é este:

add tests for auth.ts

Contra este:

Write a test case for auth.ts covering the logout edge case, using the patterns in __tests__/ and avoiding mocks

Percebe? O segundo pedido carrega o edge case, o padrão da pasta e uma restrição explícita

É a mesma tarefa, mas uma delas não deixa espaço pra invenção

O erro comum deste passo: pedir "melhore isso" e depois discutir com a IA sobre o que era "melhor"

6. Rode em modo Agent e revise o diff

O modo Agent é o modo padrão do Cursor para tarefas de código: ele explora a base sozinho, edita vários arquivos, roda comandos e corrige erros

As mudanças aparecem numa interface de diff, com linhas de adição e remoção coloridas, e uma barra flutuante na parte de baixo da tela permite aceitar ou rejeitar as mudanças do arquivo atual

Esse é o momento de desconfiar, não de comemorar

O alerta oficial é bem claro: código gerado por IA pode parecer certo e estar sutilmente errado, e quanto mais rápido o agente trabalha, mais importante fica o processo de revisão

O erro comum deste passo: aceitar tudo em sequência porque "parece ok" e só perceber o estrago três tarefas depois

7. Corrija o rumo sem perder o trabalho

Checkpoints são snapshots automáticos, criados a cada alteração do agente, e permitem desfazer o que ele fez

Salva bastante quando a IA pegou o caminho errado no meio de uma tarefa grande

Mas repare no aviso da documentação: checkpoints não são controle de versão

Edições manuais não são rastreadas, eles valem para a sessão atual e o histórico recente, são limpos automaticamente e são separados do Git

O erro comum deste passo: tratar checkpoint como commit e ficar sem rede de segurança justamente no dia em que a coisa desanda

8. Transforme correção repetida em regra

Quando você percebe que está corrigindo a MESMA coisa toda vez, aquilo virou regra

Project Rules ficam na pasta .cursor/rules, são versionadas junto do código e escopadas ao projeto

Detalhe que derruba muita gente: a extensão precisa ser .mdc

Um arquivo .md simples dentro de .cursor/rules é ignorado pelo sistema de regras, porque não tem o frontmatter esperado:

---
description:
globs:
alwaysApply:
---

Além das Project Rules, o Cursor aceita AGENTS.md como alternativa simples em markdown, User Rules globais do ambiente e Team Rules gerenciadas pelo dashboard nos planos Team e Enterprise

E a recomendação oficial é começar simples: adicione regra só quando notar o agente repetindo o mesmo erro, sem tentar otimizar tudo antes de entender seus padrões

O erro comum deste passo: escrever um manual de 300 linhas no primeiro dia, pra um projeto que você ainda nem sabe como vai crescer

Quando descrever a tarefa rende e quando é melhor voltar a digitar

Tem hora que descrever é imbatível, e tem hora que é mais rápido você mesmo digitar

O próprio Karpathy relativizou depois: chamou o tweet original de um pensamento jogado fora, feito para projetos descartáveis de fim de semana

Ou seja, nem o cara que batizou a coisa tratou aquilo como lei pra sistema de produção 😀

O Tab completion sugere código enquanto você digita, e a sugestão pode ser aceita, rejeitada ou configurada

Pra edição pequena ele costuma ser mais direto que abrir uma conversa inteira com o agente

E aquela última linha da tabela é a mais importante: se você não tem como revisar o resultado, o problema não é a ferramenta, é o escopo que você escolheu

Em tarefa densa, dar mais espaço de raciocínio pro modelo antes da resposta ajuda, e isso vale em outras ferramentas também: eu já destrinchei isso no Extended Thinking do Claude Code

O que muda na prática quando esse fluxo entra no dia a dia

Eu programo há mais de 10 anos e construí vários sistemas escrevendo código linha a linha

Hoje eu praticamente não programo: eu coordeno a IA pra que ela crie o projeto

O método é bem o que descrevi aqui em cima: eu descrevo o que quero, testo o projeto enquanto ela constrói e vou dando novas orientações pra melhorar ou corrigir o que aparece torto

E tem um contraste que eu gosto de contar, porque ele explica melhor que qualquer benchmark

Eu e minha equipe levamos 2 anos pra construir do zero uma plataforma própria, antes de existir IA

Hoje, às vezes em uma semana eu já tenho um projeto rodando

Não é mágica, e não é prompt secreto: é ritmo diferente

O gargalo mudou de lugar

Antes ele estava em escrever, agora ele está em revisar e em saber pedir do jeito certo

Eu passei os últimos meses testando ferramentas gratuitas e pagas, de empresa grande e pequena, criando projetos reais e lançando eles pra ver o que acontecia

E a conclusão que ficou é chata pra quem quer atalho: descrever a tarefa não dispensa saber o que roda por baixo do capô

Dá pra criar sistema seguro e escalável com IA, sim

Mas se a pessoa não souber pedir do jeito certo, aparecem falhas de segurança e dados expostos, e ela nem percebe que aceitou aquilo no diff

Pra mim, vibe coding também não é arrastar bloquinho de no-code, comprar template ou continuar projeto pronto: é partir da própria ideia e construir com IA

E a ferramenta pode mudar, isso eu acho até provável

O que perdura é a estratégia e a base sólida de criação, porque escolher a ferramenta certa pra cada cenário faz parte do trabalho, não é algo que se resolve fixando uma só pra sempre

No vídeo abaixo eu falo justamente sobre esse método de coordenar a IA em vez de digitar, e por que sem base técnica o resultado vira sistema de faz de conta:

Próximo passo: uma tarefa pequena, do plano ao diff

O ciclo inteiro cabe em cinco movimentos

Ask pra entender a base, Plan Mode com Shift+Tab pra planejar, @ pra dar contexto quando você sabe qual arquivo importa, diff pra revisar linha a linha, e regra em .cursor/rules só quando o mesmo erro se repete

Agora escolhe uma tarefa PEQUENA de verdade, dessas que você faria na mão em vinte minutos

Roda ela de ponta a ponta no plano Hobby gratuito ou no teste Pro de 14 dias, com o projeto sob Git e tudo commitado antes

E presta atenção no ponto onde você quase aceitou algo errado: é ali que o aprendizado mora 🙂

Faça o teste e me conta como foi… até o próximo post!