Cursor para Vibe Coders: crea aplicaciones completas sin tocar código

Si eres de los que crean aplicaciones usando plataformas como Lovable, Bolt.new o v0, probablemente pienses que esa es la única forma de hacer vibe coding. En este artículo te muestro una alternativa que en mi opinión es mejor opción hoy en día: usar Cursor como plataforma de vibe coding. Es más barato, puedes crear sistemas mucho más grandes y obtienes características que esas plataformas no ofrecen, como ejecutar múltiples sesiones al mismo tiempo, usar skills, conectar MCPs y, en la práctica, tener un administrador de agentes trabajando por ti.

Para demostrarlo, vamos a construir un proyecto real paso a paso: un sistema de pedidos para un restaurante con frontend, base de datos en Supabase, pagos con PayPal y despliegue en la nube. Todo sin escribir una sola línea de código.

¿Qué ofrecen las plataformas de vibe coding?

Plataformas como Lovable, Bolt.new o v0 permiten crear sitios web sin escribir código: pides un dashboard o un landing page, y te devuelven una aplicación conectada a una base de datos (casi siempre Supabase) lista para publicar. La idea no es nueva y todas funcionan de forma parecida: te creas una cuenta, describes lo que quieres y obtienes una aplicación web.

No tienen nada de malo. De hecho, si es tu primera vez creando aplicaciones, son una buena puerta de entrada, y durante mucho tiempo destacaron por generar diseños muy bonitos. Pero hoy puedes lograr lo mismo combinando un buen modelo con skills de diseño, y hay dos puntos en contra que conviene tener claros:

El precio. Lovable Pro cuesta $25 al mes, Bolt.new se mueve entre $20 y $25 según el plan, y en v0 el plan individual para usuarios nuevos (Plus) cuesta $30 al mes. Cursor Pro, en cambio, cuesta $20 al mes e incluye acceso a modelos frontier, MCPs, skills y agentes en la nube. Además, su modo Auto es ilimitado en los planes pagos: los créditos solo se consumen cuando seleccionas manualmente un modelo específico.

El techo. La mayoría de estas plataformas te permiten crear aplicaciones "hasta cierto punto": aplicaciones web donde todo viene dado, pero pierdes la posibilidad de conectarlas con herramientas fuera de su ecosistema. Cursor puede hacer lo mismo que ellas y, además, crear otro tipo de proyectos (aplicaciones de escritorio, de consola, backends propios) con mucho más control.

Instalación y primeros pasos

A diferencia de las plataformas de vibe coding, Cursor es una aplicación de escritorio (también funciona en la nube, pero no es su propósito principal). Se descarga desde cursor.com, detecta automáticamente tu sistema operativo (Windows, Linux o Mac) y la instalación es un típico "siguiente, siguiente, finalizar".

Algo importante: Cursor tiene dos vistas. La principal, que es la que usaremos, funciona como un administrador de chats y agentes, pensada justamente para quienes quieren hacer vibe coding. La otra es el modo IDE, un editor de código completo orientado a desarrolladores. Hoy nos quedamos con la primera.

Para empezar, crea una carpeta en tu escritorio (por ejemplo, sistema-pedidos) y ábrela desde Cursor con la opción de abrir carpeta local. También puedes importar un repositorio de GitHub si ya tienes uno.

El selector de modelos y los modos de trabajo

En la caja del chat verás un texto que dice Auto: es el selector de modelo. Mi recomendación es dejarlo en Auto, porque elige automáticamente el modelo más eficiente para cada tarea, su uso es ilimitado en los planes pagos y no consume tus créditos mensuales. Puedes elegir un modelo específico si prefieres sus respuestas, pero recuerda que ahí sí gastas créditos y en algún punto se agotan.

También hay modos de trabajo que cambian cómo responde el agente. Los dos que más nos interesan:

• Plan: hace que Cursor primero escanee el proyecto, "piense" más y elabore una planificación antes de tocar nada.
• Multitask: lanza varios agentes al mismo tiempo dentro de una misma sesión para avanzar más rápido (gasta más tokens, pero paraleliza tareas).

Paso 1: crear la interfaz de usuario

Activamos el modo Plan y pedimos algo como esto:

Crea un sistema de pedidos de restaurante con un landing page donde los usuarios escogen un menú, y un dashboard donde administradores y cocineros gestionan el sitio. Es para un solo negocio. Incluye pagos, autenticación, selección de pedidos y un dashboard estilo Kanban. Solo crea la UI.

Dos decisiones importantes en este prompt. Primero, especificar que es para un solo negocio evita que el sistema se vuelva genérico y complejo (múltiples roles, multi-tenant, etc.). Segundo, pedir solo la UI al inicio: si no sabes qué backend, lenguaje o base de datos elegir, empezar por la interfaz te permite ver cómo luce el sistema con datos de ejemplo antes de tomar decisiones técnicas.

Cursor genera un plan con un resumen de pasos (en este caso, un proyecto con Next.js y una UI con datos de ejemplo). Puedes revisarlo o simplemente darle a build locally. Como está en modo Plan, es posible que antes te haga algunas preguntas: responde lo que sepas, o pregúntale qué significa lo que te está preguntando.

Después de unos 20 minutos de implementación, obtienes un resumen de los archivos generados (unos 40 en este caso) y las instrucciones para ejecutarlo. Ni siquiera necesitas usar la terminal: basta con decirle "ejecuta el proyecto" y te dará la URL local para abrirla directamente desde Cursor, con la misma experiencia visual que ofrecen las plataformas de vibe coding.

Design mode: edita señalando

Si quieres modificar algo visual, Cursor tiene un design mode que te permite seleccionar una parte de la interfaz (toma un screenshot del bloque) y pedir cambios sobre esa selección. Por ejemplo, seleccionar el tablero de pedidos y decirle "permíteme hacer drag and drop de las tarjetas". Es una forma muy sencilla de iterar sobre la interfaz sin describir nada en abstracto.

Paso 2: conectar Supabase con MCP

Hasta aquí todo es interfaz con datos falsos. Para que funcione de verdad necesitamos una base de datos, y para eso usaremos Supabase: una plataforma que te da una base de datos en internet, autenticación de usuarios (correo/contraseña, Google y más) y almacenamiento de archivos, todo con solo crearte una cuenta.

Crea una cuenta en Supabase, dale a nuevo proyecto, ponle un nombre (por ejemplo, restaurant-pedidos), genera una contraseña (guárdala), elige la región y listo. Podrías crear las tablas manualmente, pero eso requiere conocer la plataforma. En su lugar, usaremos el MCP de Supabase.

Un MCP, explicado de forma simple, es una forma de permitir que la IA haga algo más o se conecte con alguna plataforma externa. En Cursor la integración es casi automática: escribe "supabase" en cualquier chat y aparecerá la opción de añadir el conector; autorizas tu cuenta y verás un círculo verde indicando que está conectado. Si no aparece el recuadro, ve a Customize → MCPs → Browse marketplace y búscalo ahí.

Con el MCP conectado, en modo Plan pedimos:

Actualiza el proyecto para que toda la lógica funcione con Supabase. Utiliza el proyecto "restaurant-pedidos". Los pagos simúlalos por ahora, los integraremos después.

Cursor llama internamente al MCP, lista tus proyectos, detecta que no hay tablas y las crea desde cero, incluyendo datos de demo. A diferencia de las plataformas de vibe coding, donde todo pasa automáticamente, aquí obtienes un paso intermedio de revisión antes de aprobar el plan. Tras unos 15 minutos de implementación, la aplicación queda conectada: si creas un plato desde el dashboard, aparece directamente en la tabla menu_items de Supabase.

Un detalle muy útil: Cursor suele generar usuarios de prueba (administrador, cocinero) con credenciales listas para que pruebes los distintos roles de la aplicación.

Paso 3: testear la aplicación con el navegador

Aquí viene algo que probablemente no puedes hacer en las plataformas de vibe coding: testear tu aplicación automáticamente. Hay dos caminos: usar un CLI más skills (con proyectos como Playwright) o usar MCPs que controlan el navegador.

Cursor trae una automatización de navegador integrada: ve a Settings, busca "browser" y activa browser automation (asegúrate de que no esté en off; la opción browser tab funciona bien). Luego pides:

Testea todas las funcionalidades abriendo la página en una pestaña y usando browser automation de Cursor.

Funciona, pero no siempre puedes ver lo que hace. Por eso mi recomendación es instalar un MCP aparte: Chrome DevTools MCP, un proyecto oficial del equipo de Chrome de Google que manipula el navegador usando su protocolo interno de automatización (el mismo que usan las DevTools). Se instala desde su repositorio (hay un botón para añadirlo a Cursor) o pegando la configuración en Customize → New MCP server. Una vez instalado, basta con pedir:

Prueba todas las características de la aplicación usando Chrome DevTools.

Esto abre una instancia limpia del navegador (sin tus sesiones) y va página por página probando cada característica: llena formularios, hace clics, verifica flujos. El proceso puede tomar 20 minutos o más según el tamaño del proyecto, pero puedes dejarlo en segundo plano y al final te entrega un reporte con lo que pasó y lo que falló. Si tu proyecto es grande, mejor testea por partes: primero autenticación, luego creación de productos, y así.

Y el flujo se vuelve muy natural: seleccionas un elemento de la interfaz, pides una mejora ("permite añadir notas al pedido"), y luego encolas otra tarea ("compruébalo usando Chrome DevTools"). Cursor va ejecutando las tareas en cola, una tras otra, mientras tú sigues pidiendo más cambios sin esperar.

Paso 4: subir el código a GitHub

Mientras las tareas avanzan, puedes abrir otra sesión en paralelo sobre el mismo proyecto. Por ejemplo, para subir el código a GitHub.

Si no lo conoces, GitHub es la plataforma donde se aloja el código de tus proyectos: es gratis, y tener una cuenta es fundamental si trabajas desde varias computadoras o con otras personas. Como Cursor no incluye una integración directa en su marketplace, la forma más sencilla es instalar GitHub CLI, la herramienta de línea de comandos oficial. Se instala con un comando según tu sistema (con winget en Windows, por ejemplo), luego ejecutas gh auth login, sigues las opciones por defecto y autorizas desde el navegador con el código que te da la terminal.

Con eso hecho, desde Cursor basta con pedir:

Usando gh, sube el código a GitHub y crea un repositorio.

Cursor crea el repo (en privado por defecto, puedes cambiarlo a público) y sube el código. Un consejo importante: revisa lo que sube, porque durante el desarrollo puede haber dejado credenciales de prueba en el código que conviene quitar antes de compartirlo.

Varias sesiones, con criterio

Puedes tener una sesión investigando opciones de pago, otra creando el repo y otra modificando código, todo a la vez. Eso sí: evita que varias sesiones modifiquen código al mismo tiempo, porque los agentes pueden intentar tocar los mismos archivos y pisarse entre ellos. La investigación y las tareas de infraestructura sí se paralelizan sin problema. Y si quieres velocidad dentro de una sola sesión, ahí es donde entra el modo Multitask, que lanza subagentes en paralelo dentro del mismo chat.

Otro consejo de organización: cada chat tiene su propio contexto, así que nómbralos según su función: deploy, frontend, pagos, repo. Así vuelves rápidamente al contexto correcto en lugar de crear chats nuevos todo el tiempo.

Paso 5: integrar pagos con PayPal

Una ventaja frente al vibe coding tradicional: esas plataformas suelen limitarte a Stripe o PayPal, mientras que con Cursor puedes integrar cualquier procesador de pagos que tenga API, y como el agente conoce tu código, él mismo te sugiere proveedores compatibles.

Para este ejemplo usamos PayPal. En modo Plan pedimos:

Integra PayPal en este proyecto. Actualiza frontend y backend.

Cursor genera el plan y te pide unas variables de entorno: un client ID y un client secret. Estos se obtienen desde el panel de desarrolladores de PayPal, en Apps & Credentials → Create App, creando una aplicación tipo Merchant (es decir, una app que cobra). Copias ambas credenciales, se las pegas al chat y listo.

Para probar el flujo completo, PayPal ofrece cuentas sandbox: en Testing Tools → Sandbox Accounts encuentras correos y contraseñas de prueba. Ejecutas el proyecto, seleccionas productos, vas a pagar, aparece el botón de PayPal, inicias sesión con la cuenta sandbox y completas el pago de prueba. Cuando pases a producción, solo cambias el entorno a live y colocas las credenciales reales: el flujo es exactamente el mismo.

Bonus: mejora el diseño con skills

Mientras los pagos se integran, puedes mejorar el frontend con skills: instrucciones empaquetadas que le dan superpoderes específicos al agente. Existen directorios de skills de todo tipo, como skills.sh (frontend, lógica, buenas prácticas) y ui-skills.com, que lista skills enfocados solo en diseño, con opciones como frontend design.

La instalación es copiar un comando, pegarlo en la terminal e instalarlo a nivel global. Una vez instalado, escribes /frontend-design en el chat y aparece como comando disponible (puedes verificar tus skills instalados en Customize → Skills). Luego pides algo como "crea un plan de mejora de todo el dashboard usando /frontend-design" y el agente elabora mejoras visuales para varias páginas.

Paso 6: desplegar en la nube con Railway

Para publicar el frontend necesitas una plataforma en la nube (Supabase ya está desplegado por su cuenta). Las opciones típicas son Vercel, Railway, Render o Netlify; las cuatro son similares y varían en precio, pero recomiendo Railway por una razón concreta: tiene un CLI y un skill, lo que significa que el despliegue puede ser prácticamente automático. Ten en cuenta que sus planes empiezan en $5 al mes.

El proceso es igual que con GitHub CLI: instalas el CLI de Railway según tu sistema (curl en Linux/Mac, Homebrew, npm o Scoop en Windows), verificas con railway --version, y te autenticas con railway login, que abre el navegador para autorizar tu cuenta. Luego instalas el skill de Railway desde skills.sh: el instalador te pregunta para qué agentes instalarlo y si a nivel de proyecto o global (recomiendo global si vas a crear varias aplicaciones).

Con todo listo, escribes /use-railway en el chat y pides:

Despliega el frontend en Railway.

Cursor crea el proyecto en Railway, configura la URL, coloca las claves de Supabase y te devuelve la dirección final: tu sitio ya está en internet, listo para compartir.

Actualizaciones continuas

A partir de aquí el ciclo es simple. ¿Quieres tema oscuro? "Añade soporte a tema oscuro en todo el proyecto". ¿Quieres publicar el cambio? Desde tu chat de despliegue: "Actualiza el deploy haciendo un commit y push". Cursor hace el commit, lo sube a GitHub y actualiza Railway. Entras al repo y ahí está el commit dark mode; entras al sitio y el cambio está en producción.

Conclusión

Usar Cursor como plataforma de vibe coding es relativamente simple y al final obtienes lo mismo que ofrecen Lovable, Bolt.new y compañía, pero con mucho más control: tienes el código, controlas la ejecución y puedes cambiar de plataforma cuando quieras. Y no se limita a aplicaciones web: con la misma idea puedes crear aplicaciones de escritorio, herramientas de consola y proyectos mucho más ambiciosos.

Los proyectos tipo "frontend + Supabase + algo de lógica" son muy sencillos de implementar con este flujo porque la plataforma hace la mayor parte del trabajo. Si más adelante quieres construir tu propio backend, Cursor también puede hacerlo, solo que te va a pedir investigar y leer un poco más, porque tendrás más opciones sobre la mesa.

Si eres vibe coder o estás desarrollando tus propios proyectos y tienes dudas, déjalas en los comentarios.