Cursor AI e vibe coding: crie seu MVP sem ser programador sênior

Índice

• Resumo rápido: o que você precisa saber do Cursor
• O que é vibe coding (e o que não é)

  • Vibe coding e Lean Startup: construir menos, validar antes
• Como configurar o Cursor para trabalhar bem

  • As formas de trabalhar com a IA
  • Gerenciar o contexto: a habilidade que mais rende
• Regras do projeto: AGENTS.md e .cursor/rules

  • As regras .mdc em .cursor/rules/
  • AGENTS.md: as regras gerais do projeto
  • Três regras de ouro para escrever boas diretivas
• Caso prático: da ideia a um MVP em produção

  • Passo 1: escreva um PRD de uma página
  • Passo 2: monte o esqueleto
  • Passo 3: conecte os serviços
  • Passo 4: depure, versione e publique
• Os riscos que ninguém te conta
• Preços do Cursor em 2026: a mudança de outubro

  • Como pensar o custo
• O que muda de verdade para empreender na América Latina
• Antes de escrever seu primeiro prompt

O Cursor AI é um editor de código com agentes de IA integrados que permite construir uma aplicação descrevendo em linguagem natural o que você quer, enquanto o agente escreve, edita e corrige o código. Combinado com o vibe coding —guiar a IA por conversa em vez de escrever cada linha—, um fundador não técnico consegue ir de uma ideia a um MVP em produção em dias, não em meses.

Agora, as letras miúdas: o difícil já não é a sintaxe, é saber o que pedir, como dar à IA o contexto certo e como revisar o que ela entrega. Este guia trata disso: a filosofia, a configuração que evita o código espaguete, um caso prático passo a passo, quanto custa o Cursor depois da mudança de planos de outubro de 2026 e os riscos que quase ninguém menciona.

Resumo rápido: o que você precisa saber do Cursor

Conceito	O que é	Para que serve
Agente (com Composer 2)	O modo principal: planeja e edita vários arquivos a partir de uma instrução. O Composer 2 é o modelo próprio do Cursor.	Construir telas, lógica e configuração sem escrever código à mão.
Edição inline (Cmd/Ctrl + K)	Mudanças pontuais no código ou comando que você seleciona.	Ajustar um componente sem mexer no resto do arquivo.
Regras do projeto	Arquivos .mdc em .cursor/rules/ e um AGENTS.md na raiz.	Fazer a IA respeitar seu stack, seu design e suas proibições em cada sessão.
Contexto (@-menções e .cursorignore)	Você diz ao agente quais arquivos e documentação ler, e quais ignorar.	Menos alucinações, menos consumo e respostas mais precisas.
Planos 2026	Free, Plus ($8), Premium ($30), Super ($100) e Ultra ($200) por mês.	Escolher conforme a etapa do projeto e os modelos de que você precisa.

O que é vibe coding (e o que não é)

O termo vibe coding foi popularizado por Andrej Karpathy —cofundador da OpenAI e ex-diretor de IA da Tesla— no início de 2025. Ele descrevia uma forma de programar em que você "se entrega à vibe": fala com o modelo, aceita as mudanças e quase esquece que o código existe.

Para um fundador não técnico, a ideia útil é outra, mais disciplinada: a habilidade crítica deixa de ser a sintaxe e passa a ser estruturar requisitos. Se você sabe explicar com clareza que problema resolve, para quem, o que acontece em cada tela e que dados são guardados, a IA faz o trabalho de traduzir isso em código.

Isso muda três coisas concretas:

• O custo da primeira versão. O que antes era um orçamento de agência de vários meses hoje pode ser uma assinatura mensal mais o seu tempo. Atenção: seu tempo continua custando, e não é pouco.
• A velocidade para testar hipóteses. Um protótipo pode estar diante de usuários reais em dias, que é exatamente o que você precisa para saber se a ideia vale a pena.
• O seu papel. Você deixa de ser "quem escreve o código" e passa a algo mais parecido com produto e arquitetura: decide o que se constrói, em que ordem e com que critério de qualidade.

O que não é: uma forma de construir sem entender nada. O vibe coding puro funciona para protótipos de fim de semana. Para algo que vai ter usuários, pagamentos ou dados pessoais, você precisa entender —mesmo sem escrever— como ele está montado.

Vibe coding e Lean Startup: construir menos, validar antes

Um dos motivos mais comuns de fracasso de um negócio é construir em cima de suposições não validadas. O vibe coding não resolve isso; torna mais barato corrigir. Se um MVP custa dias em vez de meses, você pode lançar, medir e mudar de rumo sem queimar o caixa.

A ordem continua importando: primeiro a hipótese, depois o código. Antes de abrir o Cursor, vale a pena validar a ideia em uma semana e colocar o modelo em um Business Model Canvas. Se você não sabe quem paga nem por quê, a IA só ajuda a construir mais rápido algo que ninguém quer.

Como configurar o Cursor para trabalhar bem

O Cursor é um fork do VS Code: tem a mesma cara, mantém as extensões e os atalhos, mas coloca a IA no centro do editor. Se você nunca usou o VS Code, a curva de aprendizado é de uma tarde.

As formas de trabalhar com a IA

1. Agente. É o modo que você mais vai usar. Você dá uma tarefa ("adicione uma página de preços com três planos") e o agente lê o projeto, propõe um plano, edita vários arquivos e pode executar comandos no terminal. Você decide se cada mudança precisa da sua aprovação ou se ele aplica direto; no começo, aprove mudança por mudança.
2. Modo plano ou perguntas. Antes de uma mudança grande, peça que ele analise e proponha sem mexer nos arquivos: "explique como funciona o cadastro de usuários" ou "quais arquivos teriam que mudar para adicionar assinaturas?". É a melhor forma de aprender o seu próprio projeto.
3. Edição inline (Cmd/Ctrl + K). Você seleciona um bloco e pede uma mudança concreta. Ideal para retoques sem arriscar o resto do arquivo.
4. Terminal com IA. Você descreve o que quer fazer ("instale as dependências e rode a migração") e recebe o comando. Leia o que ele faz antes de executar, principalmente se apagar ou sobrescrever algo.

Quanto aos modelos, o Cursor permite escolher entre o modelo próprio, o Composer 2 (lançado em março de 2026, rápido e barato para editar código), e modelos de terceiros como Claude ou GPT, conforme o seu plano. Se quiser entender as diferenças entre famílias de modelos, tenho um guia sobre os modelos Claude em 2026.

Gerenciar o contexto: a habilidade que mais rende

Os modelos trabalham com uma janela de contexto limitada: o que cabe na memória deles durante a conversa. Se você enche essa janela de arquivos irrelevantes, o modelo se confunde e inventa coisas que não existem no seu código. Se dá pouco, ele adivinha.

Como dar o contexto certo:

• @-menções. Com @ você aponta exatamente o que ele deve ler: um arquivo específico, uma pasta (por exemplo /components) ou a documentação oficial de uma biblioteca. É muito melhor do que deixá-lo procurar sozinho no projeto inteiro.
• Conversas curtas e por tarefa. Uma conversa por funcionalidade. Quando uma sessão se alonga e começa a se contradizer, abra outra e resuma o importante.
• .cursorignore. Um arquivo na raiz, com a mesma sintaxe do .gitignore, para que a IA não leia arquivos pesados, dados locais, logs ou arquivos com segredos. Economiza consumo e reduz o risco de uma chave acabar numa conversa.
• GitHub desde o primeiro dia. Conecte o projeto a um repositório. Isso te dá histórico para voltar atrás quando a IA quebrar algo (vai acontecer) e garante que o código é seu, não da ferramenta.

Regras do projeto: AGENTS.md e .cursor/rules

Sem regras, a IA improvisa: mistura bibliotecas, muda de estilo de um arquivo para outro e repete erros que você já corrigiu. As regras são instruções persistentes que o agente lê em cada sessão, para você não ter que repeti-las.

As regras .mdc em .cursor/rules/

O formato próprio do Cursor são arquivos .mdc dentro de .cursor/rules/. Cada um tem um cabeçalho que define quando se aplica: sempre (alwaysApply: true), só quando você trabalha com certos arquivos (globs) ou quando o agente decide que é relevante pela description. O antigo arquivo único .cursorrules ficou como formato legado.

Exemplo, .cursor/rules/frontend.mdc:

---
description: Padrões de componentes e estilos do frontend
globs: "src/components/**/*.tsx"
alwaysApply: false
---

# Frontend

1. Use componentes funcionais de React com Tailwind CSS. Não use estilos inline.
2. Para componentes de interface, use primeiro os do shadcn/ui antes de criar um novo.
3. Estado local com hooks de React; mutações de dados com Server Actions.
4. Nunca coloque chaves de API nem tokens em código que roda no navegador.

Repare num detalhe: se uma regra tem globs, o normal é alwaysApply: false, para que ela só seja ativada com esses arquivos. Se você marcar as duas coisas, a regra se aplica sempre e o globs deixa de importar.

AGENTS.md: as regras gerais do projeto

O AGENTS.md é um arquivo Markdown comum na raiz do repositório. Não tem cabeçalho nem condições: tudo o que você escrever se aplica. A vantagem é que é um padrão aberto, então outros agentes como Claude Code ou Codex também o leem; se amanhã você trocar de ferramenta, suas regras vão junto.

	Regras .mdc	AGENTS.md
Onde fica	.cursor/rules/*.mdc	Raiz do projeto (e subpastas, se quiser)
Quando se aplica	Conforme o cabeçalho: sempre, por arquivos ou por relevância	Sempre, por completo
Quem lê	Só o Cursor	O Cursor e outros agentes compatíveis
Use para	Regras específicas de uma parte do código	O que é o projeto, o stack, como se testa e o que é proibido

Uma divisão que funciona: AGENTS.md para o panorama (o que o app faz, stack, comandos, regras que valem para tudo) e .mdc para regras que só se aplicam a uma pasta ou tipo de arquivo.

Três regras de ouro para escrever boas diretivas

1. Dados concretos, não desejos. "Escreva código limpo" não diz nada ao modelo. "A tabela de usuários é public.profiles e se relaciona por user_id" diz: obriga a trabalhar sobre a sua arquitetura real em vez de inventá-la.
2. Proibições explícitas. Diga o que não se faz: "não instale bibliotecas novas sem perguntar", "não use estilos inline", "não modifique as migrações já aplicadas". Proibições claras evitam mais erros do que recomendações vagas.
3. Respostas diretas. Peça que entregue primeiro o código ou o comando e depois a explicação, se for necessária. Economiza tempo e consumo.

Se você quiser levar isso adiante —escrever a especificação antes do código—, o Spec-Driven Development é exatamente essa disciplina aplicada a agentes.

Caso prático: da ideia a um MVP em produção

O caminho é sempre o mesmo: especificação → esqueleto → integrações → publicação. O que muda é quanto tempo você dedica a cada etapa.

Passo 1: escreva um PRD de uma página

Antes de pedir uma única linha de código, escreva um documento de requisitos (PRD) num arquivo PRD.md dentro do projeto. Não precisa ser longo: que problema você resolve, para quem, o que a versão 1 faz e, muito importante, o que ela ainda não faz.

Inclua também os eventos que você vai medir. Se não defini-los no começo, depois não vai saber se o produto funciona. Uma lista base para um SaaS:

• signed_up: se cadastrou.
• onboarding_completed: terminou o fluxo inicial.
• created_first_project: obteve o primeiro valor real do produto.
• invited_teammate: convidou alguém.
• hit_plan_limit: chegou ao limite do plano gratuito.
• subscription_started: começou a pagar.
• payment_failed: uma cobrança falhou.
• cancelled: cancelou.

Com o PRD pronto, o agente tem uma fonte de verdade que você pode mencionar com @PRD.md em cada tarefa.

Passo 2: monte o esqueleto

Um stack muito comum, bem documentado e que os modelos conhecem a fundo:

• Next.js (framework de React para produção),
• Tailwind CSS (estilos com classes utilitárias),
• shadcn/ui (componentes de interface acessíveis que você copia para o seu projeto).

O modelo conhecer bem o stack não é um detalhe menor: quanto mais popular ele é, menos a IA inventa.

Prompt de exemplo para o agente:

Leia @PRD.md. Proponha um plano para inicializar um projeto Next.js com App Router, TypeScript, Tailwind CSS e shadcn/ui, com o código dentro de /src e uma barra de navegação no layout principal. Não execute nada até eu aprovar o plano.

Essa última frase importa: plano primeiro, execução depois. Revisar um plano leva dois minutos; desfazer vinte arquivos mal criados leva uma tarde.

Passo 3: conecte os serviços

Uma integração por sessão, testando cada uma antes de passar à seguinte:

• Autenticação. Supabase Auth se você já usa Supabase, ou Clerk se quiser cadastro e login com Google ou GitHub praticamente prontos.
• Banco de dados. Supabase (PostgreSQL gerenciado). Ative a segurança em nível de linha (RLS) em cada tabela e peça ao agente que explique qual política cada uma tem. Uma tabela sem RLS pode ficar legível para qualquer pessoa.
• Pagamentos. Stripe se operar no seu país; no Brasil e na América Latina, avalie também Mercado Pago ou outros gateways locais. Os pagamentos são confirmados com webhooks do lado do servidor, nunca só pelo navegador.
• E-mails transacionais. Um serviço como Resend ou SendGrid para o e-mail de boas-vindas e os alertas.

Passo 4: depure, versione e publique

• Erros. Quando algo falhar, copie o erro completo no chat do agente e peça que explique a causa antes de corrigir. Se você só pedir "conserta", ele tende a remendar o sintoma.
• Commits frequentes. Um commit depois de cada mudança que funciona. É o seu botão de desfazer.
• Publicação. Conecte o repositório do GitHub à Vercel (ou à plataforma que preferir). Cada mudança na branch principal é publicada sozinha, com HTTPS e domínio próprio. Se quiser algo mais barato para um app simples, também dá para publicar na Cloudflare de graça.

Os riscos que ninguém te conta

O vibe coding baixa a barreira de entrada, mas não elimina os problemas: esconde-os melhor. Os mais comuns:

• Segurança. Chaves de API expostas no navegador, tabelas sem permissões, rotas de administração sem proteção. O código "funciona" e por isso ninguém revisa. Antes de ter usuários reais, peça ao agente uma auditoria de segurança explícita e, se você lida com pagamentos ou dados pessoais, consiga uma revisão humana. Para se aprofundar, tenho um guia sobre segurança e privacidade ao usar IA no seu negócio.
• Dívida técnica. Cada remendo rápido se soma. Se cada mudança nova quebra duas coisas, é hora de parar e pedir ao agente que proponha uma reorganização.
• Dependência de uma só ferramenta. Por isso importam o GitHub e o AGENTS.md: se o Cursor subir os preços ou mudar as condições —como acabou de acontecer—, você pode continuar com outro agente. Comparei as alternativas em as IDEs e agentes de código que valem a pena em 2026.
• O custo invisível. Os créditos de IA acabam rápido quando o agente entra em loops de "conserto isto, quebro aquilo". Olhe seu consumo toda semana.

Preços do Cursor em 2026: a mudança de outubro

Desde 12 de outubro de 2026, o Cursor vende suas assinaturas novas dentro da The X Subscription, um pacote compartilhado com Grok e X. Os planos Pro ($20) e Pro+ ($60) não são mais oferecidos a novos clientes; quem já os tinha pode mantê-los.

Plano	Preço mensal	Uso incluído	Para quem
Free	$0	Limitado, com modelos do Cursor	Testar a ferramenta e aprender o fluxo.
Plus	$8	Uso base semanal, só modelos do Cursor e do Grok com configurações fixas. Sem Auto, agentes na nuvem nem modelos de terceiros.	Protótipos simples com orçamento mínimo.
Premium	$30	4 vezes o uso do Plus. Agentes na nuvem, Bugbot e modelos de terceiros (Claude, GPT) cobrados à parte, a preço de API, a partir de crédito pré-pago.	Um fundador construindo seu MVP a sério. É o equivalente ao antigo Pro.
Super	$100	15 vezes o uso do Plus e prioridade em horários de pico.	Uso intensivo ou vários projetos ao mesmo tempo. Equivale ao antigo Pro+.
Ultra	$200	50 vezes o uso do Plus e acesso antecipado a novos modelos.	Equipes ou bases de código grandes.

Os planos anuais custam $80, $300, $1.000 e $2.000, respectivamente. Os preços não incluem impostos (fonte: central de ajuda do Cursor).

Como pensar o custo

• O uso não é mais contado em "requisições". Cada plano traz um pacote de uso que se renova toda semana. Quando acaba, você pode recarregar. O Cursor não publica quanto vale em dólares cada pacote, então a única forma de saber se é suficiente é medir o seu próprio consumo nas primeiras semanas.
• Os modelos de terceiros são pagos à parte. No Premium e acima, usar Claude ou GPT é descontado de um crédito pré-pago a preço de API. Use o Composer 2 para o grosso do trabalho e reserve os modelos mais caros para o difícil: arquitetura, erros que o modelo barato não resolve ou revisões de segurança.
• Se você já tem Pro ou Pro+, pense antes de trocar. A mudança para a nova assinatura cancela o plano anterior e não tem volta.
• Compare com o que ele substitui. Mesmo no Premium mais o consumo de modelos, o custo mensal costuma ser uma fração de contratar desenvolvimento externo por hora. Mas conte o seu tempo: um MVP feito por você com IA é barato em dinheiro, não em horas.

Para comparar o Cursor com as assinaturas do ChatGPT, Claude ou Gemini e com modelos abertos, veja os preços reais da IA em 2026. E se você se preocupa em depender de um só fornecedor, também pode trabalhar com modelos locais a partir de agentes como o opencode.

O que muda de verdade para empreender na América Latina

Durante anos, lançar um produto digital na região significava conseguir capital para pagar desenvolvimento ou encontrar um sócio técnico. O vibe coding não elimina essa necessidade para sempre, mas elimina para a primeira versão: hoje você pode chegar a usuários reais com o seu tempo, uma assinatura e disciplina.

A vantagem competitiva não está mais em decorar sintaxe. Está em ter claro que problema você resolve, construir o mínimo para comprovar, medir o que os usuários fazem e cuidar do caixa enquanto itera. Escrever código deixou de ser o gargalo; decidir o que construir, não.

Antes de escrever seu primeiro prompt

Faça as contas e o modelo antes de abrir o editor:

1. Use a calculadora de margem para projetar quanto custam a infraestrutura e as assinaturas de IA, e a que preço você teria que vender seu plano para o negócio fechar a conta.
2. Monte seu modelo no Business Model Canvas interativo para ter claro quem é seu cliente e quanto vai cobrar antes de investir tempo e dinheiro em construir.