Cursor AI y vibe coding: crea tu MVP sin ser programador sénior

Tabla de Contenidos

• Resumen rápido: lo que necesitas saber de Cursor
• Qué es el vibe coding (y qué no es)

  • Vibe coding y Lean Startup: construir menos, validar antes
• Cómo configurar Cursor para trabajar bien

  • Las formas de trabajar con la IA
  • Manejar el contexto: la habilidad que más rinde
• Reglas del proyecto: AGENTS.md y .cursor/rules

  • Las reglas .mdc en .cursor/rules/
  • AGENTS.md: las reglas generales del proyecto
  • Tres reglas de oro para escribir buenas directivas
• Caso práctico: de la idea a un MVP en producción

  • Paso 1: escribe un PRD de una página
  • Paso 2: arma el esqueleto
  • Paso 3: conecta los servicios
  • Paso 4: depura, versiona y despliega
• Los riesgos que nadie te cuenta
• Precios de Cursor en 2026: el cambio de octubre

  • Cómo pensar el costo
• Lo que de verdad cambia para emprender en Latinoamérica
• Antes de escribir tu primer prompt

Cursor AI es un editor de código con agentes de IA integrados que permite construir una aplicación describiendo en lenguaje natural lo que quieres, mientras el agente escribe, edita y corrige el código. Combinado con el vibe coding —guiar a la IA por conversación en lugar de escribir cada línea—, un fundador no técnico puede pasar de una idea a un MVP en producción en días, no en meses.

Ahora, la letra pequeña: lo difícil ya no es la sintaxis, es saber qué pedir, cómo darle a la IA el contexto correcto y cómo revisar lo que entrega. Esta guía va de eso: la filosofía, la configuración que evita el código espagueti, un caso práctico paso a paso, lo que cuesta Cursor después del cambio de planes de octubre de 2026 y los riesgos que casi nadie menciona.

Resumen rápido: lo que necesitas saber de Cursor

Concepto	Qué es	Para qué te sirve
Agente (con Composer 2)	El modo principal: planea y edita varios archivos a partir de una instrucción. Composer 2 es el modelo propio de Cursor.	Construir pantallas, lógica y configuración sin escribir código a mano.
Edición inline (Cmd/Ctrl + K)	Cambios puntuales sobre el código o el comando que seleccionas.	Ajustar un componente sin tocar el resto del archivo.
Reglas del proyecto	Archivos .mdc en .cursor/rules/ y un AGENTS.md en la raíz.	Que la IA respete tu stack, tu diseño y tus prohibiciones en cada sesión.
Contexto (@-menciones y .cursorignore)	Le dices al agente qué archivos y documentación leer, y cuáles ignorar.	Menos alucinaciones, menos consumo y respuestas más precisas.
Planes 2026	Free, Plus ($8), Premium ($30), Super ($100) y Ultra ($200) al mes.	Elegir según la etapa del proyecto y los modelos que necesitas.

Qué es el vibe coding (y qué no es)

El término vibe coding lo popularizó Andrej Karpathy —cofundador de OpenAI y exdirector de IA en Tesla— a principios de 2025. Describía una forma de programar en la que te "entregas a la vibra": le hablas al modelo, aceptas sus cambios y casi te olvidas de que existe el código.

Para un fundador no técnico, la idea útil es otra, más disciplinada: la habilidad crítica deja de ser la sintaxis y pasa a ser estructurar requerimientos. Si sabes explicar con claridad qué problema resuelves, para quién, qué pasa en cada pantalla y qué datos se guardan, la IA hace el trabajo de traducirlo a código.

Esto cambia tres cosas concretas:

• El costo de la primera versión. Lo que antes era una cotización de agencia de varios meses hoy puede ser una suscripción mensual más tu tiempo. Ojo: tu tiempo sigue costando, y no es poco.
• La velocidad para probar hipótesis. Un prototipo puede estar frente a usuarios reales en días, que es justo lo que necesitas para saber si la idea vale la pena.
• Tu rol. Pasas de "quien escribe el código" a algo más parecido a producto y arquitectura: decides qué se construye, en qué orden y con qué criterio de calidad.

Lo que no es: una forma de construir sin entender nada. El vibe coding puro funciona para prototipos de fin de semana. Para algo que va a tener usuarios, pagos o datos personales, necesitas entender —aunque no lo escribas— cómo está armado.

Vibe coding y Lean Startup: construir menos, validar antes

Uno de los motivos más comunes por los que fracasa un emprendimiento es construir sobre suposiciones sin validar. El vibe coding no arregla eso; lo hace más barato de corregir. Si un MVP cuesta días en vez de meses, puedes lanzar, medir y cambiar de rumbo sin quemar la caja.

El orden sigue importando: primero la hipótesis, después el código. Antes de abrir Cursor, vale la pena validar la idea en una semana y aterrizar el modelo en un Business Model Canvas. Si no sabes quién paga ni por qué, la IA solo te ayuda a construir más rápido algo que nadie quiere.

Cómo configurar Cursor para trabajar bien

Cursor es un fork de VS Code: se ve igual, conserva las extensiones y los atajos, pero tiene la IA en el centro del editor. Si nunca usaste VS Code, la curva es de una tarde.

Las formas de trabajar con la IA

1. Agente. Es el modo que más vas a usar. Le das una tarea ("agrega una página de precios con tres planes") y el agente lee el proyecto, propone un plan, edita varios archivos y puede ejecutar comandos en la terminal. Puedes decidir si cada cambio requiere tu aprobación o si lo deja aplicar directamente; al empezar, aprueba cambio por cambio.
2. Modo plan o preguntas. Antes de un cambio grande, pídele que analice y proponga sin tocar archivos: "explícame cómo fluye el registro de usuarios" o "¿qué archivos habría que cambiar para agregar suscripciones?". Es la mejor forma de aprender tu propio proyecto.
3. Edición inline (Cmd/Ctrl + K). Seleccionas un bloque y pides un cambio concreto. Ideal para retoques sin arriesgar el resto del archivo.
4. Terminal con IA. Describes lo que quieres hacer ("instala las dependencias y corre la migración") y obtienes el comando. Lee qué hace antes de ejecutarlo, sobre todo si borra o sobrescribe algo.

En cuanto a modelos, Cursor permite elegir entre su modelo propio, Composer 2 (lanzado en marzo de 2026, rápido y barato para editar código), y modelos de terceros como Claude o GPT, según tu plan. Si quieres entender las diferencias entre familias de modelos, tengo una guía de los modelos Claude en 2026.

Manejar el contexto: la habilidad que más rinde

Los modelos trabajan con una ventana de contexto limitada: lo que cabe en su memoria durante la conversación. Si la llenas de archivos irrelevantes, el modelo se confunde e inventa cosas que no existen en tu código. Si le das muy poco, adivina.

Cómo darle el contexto justo:

• @-menciones. Con @ señalas exactamente qué debe leer: un archivo concreto, una carpeta (por ejemplo /components) o documentación oficial de una librería. Es mucho mejor que dejarlo buscar solo en todo el proyecto.
• Conversaciones cortas y por tarea. Una conversación por funcionalidad. Cuando una sesión se alarga y empieza a contradecirse, abre una nueva y resume lo importante.
• .cursorignore. Un archivo en la raíz, con la misma sintaxis que .gitignore, para que la IA no lea archivos pesados, datos locales, registros o archivos con secretos. Ahorra consumo y reduce el riesgo de que una clave termine en una conversación.
• GitHub desde el día uno. Conecta el proyecto a un repositorio. Te da historial para volver atrás cuando la IA rompe algo (va a pasar) y garantiza que el código es tuyo, no de la herramienta.

Reglas del proyecto: AGENTS.md y .cursor/rules

Sin reglas, la IA improvisa: mezcla librerías, cambia de estilo de un archivo a otro y repite errores que ya corregiste. Las reglas son instrucciones persistentes que el agente lee en cada sesión, para que no tengas que repetirlas.

Las reglas .mdc en .cursor/rules/

El formato propio de Cursor son archivos .mdc dentro de .cursor/rules/. Cada uno tiene un encabezado que define cuándo se aplica: siempre (alwaysApply: true), solo cuando trabajas con ciertos archivos (globs) o cuando el agente decide que es relevante según la description. El antiguo archivo único .cursorrules quedó como formato heredado.

Ejemplo, .cursor/rules/frontend.mdc:

---
description: Estándares de componentes y estilos del frontend
globs: "src/components/**/*.tsx"
alwaysApply: false
---

# Frontend

1. Usa componentes funcionales de React con Tailwind CSS. No uses estilos en línea.
2. Para componentes de interfaz, usa primero los de shadcn/ui antes de crear uno nuevo.
3. Estado local con hooks de React; mutaciones de datos con Server Actions.
4. Nunca pongas claves de API ni tokens en código que se ejecute en el navegador.

Fíjate en un detalle: si una regla tiene globs, lo normal es alwaysApply: false, para que se active solo con esos archivos. Si marcas las dos cosas, la regla se aplica siempre y el globs deja de importar.

AGENTS.md: las reglas generales del proyecto

AGENTS.md es un archivo Markdown normal en la raíz del repositorio. No tiene encabezado ni condiciones: todo lo que escribas se aplica. Su ventaja es que es un estándar abierto, así que también lo leen otros agentes como Claude Code o Codex; si mañana cambias de herramienta, tus reglas viajan contigo.

	Reglas .mdc	AGENTS.md
Dónde vive	.cursor/rules/*.mdc	Raíz del proyecto (y subcarpetas, si quieres)
Cuándo se aplica	Según su encabezado: siempre, por archivos o por relevancia	Siempre, completo
Quién lo lee	Solo Cursor	Cursor y otros agentes compatibles
Úsalo para	Reglas específicas de una parte del código	Qué es el proyecto, el stack, cómo se prueba y qué está prohibido

Una división que funciona: AGENTS.md para el panorama (qué hace la app, stack, comandos, reglas que valen para todo) y .mdc para reglas que solo aplican a una carpeta o tipo de archivo.

Tres reglas de oro para escribir buenas directivas

1. Datos concretos, no deseos. "Escribe código limpio" no le dice nada al modelo. "La tabla de usuarios es public.profiles y se relaciona por user_id" sí: obliga a trabajar sobre tu arquitectura real en vez de inventarla.
2. Prohibiciones explícitas. Di qué no se hace: "no instales librerías nuevas sin preguntar", "no uses estilos en línea", "no modifiques las migraciones ya aplicadas". Las prohibiciones claras evitan más errores que las recomendaciones vagas.
3. Respuestas al grano. Pide que entregue primero el código o el comando y después la explicación, si hace falta. Ahorra tiempo y consumo.

Si te interesa llevar esto más lejos —escribir la especificación antes que el código—, el Spec-Driven Development es justamente esa disciplina aplicada a agentes.

Caso práctico: de la idea a un MVP en producción

El recorrido es siempre el mismo: especificación → esqueleto → integraciones → despliegue. Lo que cambia es cuánto tiempo le dedicas a cada etapa.

Paso 1: escribe un PRD de una página

Antes de pedir una sola línea de código, escribe un documento de requerimientos (PRD) en un archivo PRD.md dentro del proyecto. No necesita ser largo: qué problema resuelves, para quién, qué hace la versión 1 y, muy importante, qué no hace todavía.

Incluye también los eventos que vas a medir. Si no los defines al principio, después no sabrás si el producto funciona. Una lista base para un SaaS:

• signed_up: se registró.
• onboarding_completed: terminó el flujo inicial.
• created_first_project: obtuvo el primer valor real del producto.
• invited_teammate: invitó a alguien.
• hit_plan_limit: llegó al límite del plan gratuito.
• subscription_started: empezó a pagar.
• payment_failed: falló un cobro.
• cancelled: canceló.

Con el PRD listo, el agente tiene una fuente de verdad que puedes mencionar con @PRD.md en cada tarea.

Paso 2: arma el esqueleto

Un stack muy común, bien documentado y que los modelos conocen a fondo:

• Next.js (framework de React para producción),
• Tailwind CSS (estilos con clases utilitarias),
• shadcn/ui (componentes de interfaz accesibles que copias a tu proyecto).

Que el modelo lo conozca bien no es un detalle menor: cuanto más popular es el stack, menos inventa la IA.

Prompt de ejemplo para el agente:

Lee @PRD.md. Propón un plan para inicializar un proyecto de Next.js con App Router, TypeScript, Tailwind CSS y shadcn/ui, con el código dentro de /src y una barra de navegación en el layout principal. No ejecutes nada hasta que apruebe el plan.

Esa última frase importa: plan primero, ejecución después. Revisar un plan toma dos minutos; deshacer veinte archivos mal creados toma una tarde.

Paso 3: conecta los servicios

Una integración por sesión, y probando cada una antes de pasar a la siguiente:

• Autenticación. Supabase Auth si ya usas Supabase, o Clerk si quieres registro e inicio de sesión con Google o GitHub casi listos.
• Base de datos. Supabase (PostgreSQL gestionado). Activa la seguridad a nivel de fila (RLS) en cada tabla y pídele al agente que te explique qué política tiene cada una. Una tabla sin RLS puede quedar legible para cualquiera.
• Pagos. Stripe si opera en tu país; en Latinoamérica revisa también Mercado Pago u otras pasarelas locales. Los pagos se confirman con webhooks del lado del servidor, nunca solo desde el navegador.
• Correos transaccionales. Un servicio como Resend o SendGrid para el correo de bienvenida y las alertas.

Paso 4: depura, versiona y despliega

• Errores. Cuando algo falle, copia el error completo al chat del agente y pídele que explique la causa antes de corregir. Si solo le pides "arréglalo", tiende a parchear el síntoma.
• Commits frecuentes. Un commit después de cada cambio que funciona. Es tu botón de deshacer.
• Despliegue. Conecta el repositorio de GitHub a Vercel (o a la plataforma que prefieras). Cada cambio en la rama principal se publica solo, con HTTPS y dominio propio. Si prefieres algo más barato para una app sencilla, también se puede desplegar en Cloudflare gratis.

Los riesgos que nadie te cuenta

El vibe coding baja la barrera de entrada, pero no elimina los problemas: los esconde mejor. Los más comunes:

• Seguridad. Claves de API expuestas en el navegador, tablas sin permisos, rutas de administración sin proteger. El código "funciona" y por eso nadie lo revisa. Antes de tener usuarios reales, pídele al agente una auditoría de seguridad explícita y, si manejas pagos o datos personales, consigue una revisión humana. Si quieres profundizar, tengo una guía sobre seguridad y privacidad al usar IA en tu negocio.
• Deuda técnica. Cada parche rápido se suma. Si cada cambio nuevo rompe dos cosas, es momento de parar y pedirle al agente que proponga una reorganización.
• Dependencia de una sola herramienta. Por eso importan GitHub y AGENTS.md: si Cursor sube precios o cambia de condiciones —como acaba de pasar—, puedes seguir con otro agente. Comparé las alternativas en los IDEs y agentes de código que valen la pena en 2026.
• El costo invisible. Los créditos de IA se van rápido cuando el agente entra en bucles de "arreglo esto, rompo aquello". Mira tu consumo cada semana.

Precios de Cursor en 2026: el cambio de octubre

Desde el 12 de octubre de 2026, Cursor vende sus suscripciones nuevas dentro de The X Subscription, un paquete compartido con Grok y X. Los planes Pro ($20) y Pro+ ($60) ya no se ofrecen a clientes nuevos; quien los tenía puede conservarlos.

Plan	Precio mensual	Uso incluido	Para quién
Free	$0	Limitado, con modelos de Cursor	Probar la herramienta y aprender el flujo.
Plus	$8	Uso base semanal, solo modelos de Cursor y Grok con ajustes fijos. Sin Auto, agentes en la nube ni modelos de terceros.	Prototipos sencillos con presupuesto mínimo.
Premium	$30	4 veces el uso de Plus. Agentes en la nube, Bugbot y modelos de terceros (Claude, GPT) cobrados aparte a precio de API desde crédito prepagado.	Un fundador construyendo su MVP en serio. Es el equivalente al antiguo Pro.
Super	$100	15 veces el uso de Plus y prioridad en horas pico.	Uso intensivo o varios proyectos a la vez. Equivale al antiguo Pro+.
Ultra	$200	50 veces el uso de Plus y acceso anticipado a nuevos modelos.	Equipos o bases de código grandes.

Los planes anuales cuestan $80, $300, $1.000 y $2.000 respectivamente. Los precios no incluyen impuestos (fuente: centro de ayuda de Cursor).

Cómo pensar el costo

• El uso ya no se cuenta en "peticiones". Cada plan trae una bolsa de uso que se renueva cada semana. Cuando se acaba, puedes recargar. Cursor no publica cuánto vale en dólares cada bolsa, así que la única forma de saber si te alcanza es medir tu propio consumo durante las primeras semanas.
• Los modelos de terceros se pagan aparte. En Premium y superiores, usar Claude o GPT se descuenta de un crédito prepagado a precio de API. Usa Composer 2 para el grueso del trabajo y reserva los modelos más caros para lo difícil: arquitectura, errores que el modelo barato no resuelve o revisiones de seguridad.
• Si ya tienes Pro o Pro+, piénsalo antes de cambiar. El cambio a la nueva suscripción cancela tu plan anterior y no tiene vuelta atrás.
• Compáralo con lo que reemplaza. Incluso en Premium más el consumo de modelos, el costo mensual suele ser una fracción de contratar desarrollo externo por horas. Pero cuenta tu propio tiempo: un MVP hecho por ti con IA es barato en dinero, no en horas.

Para comparar Cursor con las suscripciones de ChatGPT, Claude o Gemini y con modelos abiertos, revisa los precios reales de la IA en 2026. Y si te preocupa depender de un solo proveedor, también puedes trabajar con modelos locales desde agentes como opencode.

Lo que de verdad cambia para emprender en Latinoamérica

Durante años, lanzar un producto digital en la región significaba conseguir capital para pagar desarrollo o encontrar un socio técnico. El vibe coding no elimina esa necesidad para siempre, pero sí para la primera versión: hoy puedes llegar a usuarios reales con tu tiempo, una suscripción y disciplina.

La ventaja competitiva ya no está en memorizar sintaxis. Está en tener claro qué problema resuelves, construir lo mínimo para comprobarlo, medir lo que hacen los usuarios y cuidar la caja mientras iteras. Escribir código dejó de ser el cuello de botella; decidir qué construir, no.

Antes de escribir tu primer prompt

Haz los números y el modelo antes de abrir el editor:

1. Usa la calculadora de margen para proyectar cuánto te cuestan la infraestructura y las suscripciones de IA, y a qué precio tendrías que vender tu plan para que el negocio cierre.
2. Arma tu modelo en el Business Model Canvas interactivo para tener claro quién es tu cliente y qué le vas a cobrar antes de invertir tiempo y dinero en construir.