Dejé que Cursor construyera una app entera solo: las 5 funciones que casi nadie activa

Si usas Cursor para desarrollar con IA, lo más probable es que estés usando el 20% de lo que ya pagas. La mayoría abre el chat, escribe un prompt, revisa, corrige, vuelve a escribir otro prompt… y así todo el día. Ese ciclo funciona, pero es el más lento de todos.

Cursor hoy puede hacer otra cosa: planificar el proyecto contigo, repartirlo entre varios subagentes que trabajan en paralelo, rediseñar la interfaz con un skill especializado y probar la aplicación en un navegador real sin que tú toques nada.

Para probarlo hice un experimento: partí de un boceto dibujado a mano de una app llamada EmoScan (un veterinario sube fotos de células sanguíneas, la IA las analiza y compara resultados entre varios modelos), y dejé que Cursor la construyera casi sola. El bloque de generación tomó alrededor de una hora y veinte minutos sin intervención mía, y terminó desplegada con URL propia.

Estas son las cinco funciones que hicieron posible eso, con los comandos exactos y —también— con lo que no salió bien.

1. El modo plan: donde se ahorra el 80% de los tokens

Suena aburrido, pero es la función que más impacto tiene. El modo plan de Cursor no escribe código: analiza el proyecto, te hace preguntas y arma un documento de planificación que después ejecuta.

La diferencia con escribir un prompt largo es que el plan queda escrito y revisable antes de gastar un solo token en generar archivos.

Empieza con un dibujo, no con un párrafo

Un truco simple: en vez de describir la app en texto, dibújala. Yo uso Excalidraw para bocetar pantallas, le pongo un fondo, exporto la imagen y la subo al chat en modo plan. La primera instrucción no es "hazme esto", es literalmente "¿qué entiendes de esta imagen?".

Ese cambio de orden hace que el modelo primero interprete y luego pregunte, en vez de asumir. Y si trabajas con clientes, pedirles un boceto —aunque sea feo, aunque sea en papel— vale más que tres reuniones.

Sube el esfuerzo de razonamiento (y baja el modelo después)

Para planificar conviene el nivel de razonamiento más alto y un modelo fuerte. En el momento de escribir esto, Cursor da acceso a Claude Opus 5, Claude Sonnet 5, la familia GPT-5.6, Gemini 3.1 Pro y a modelos de su propio pool como Grok 4.6 y Composer 2.5, además del modo Auto con perfiles de costo, equilibrio e inteligencia.

Para decidir cuál usar en cada fase no me guío por hype: reviso Artificial Analysis, que evalúa modelos de forma independiente en inteligencia, precio y velocidad, y publica índices por dominio (Salud y Medicina, Legal, Finanzas, Ingeniería, agentes de programación). Como EmoScan es una app de datos médicos, filtré por Salud y Medicina para elegir los tres modelos que iba a comparar dentro de la propia aplicación vía OpenRouter.

La estrategia que mejor me funciona:

  • Planificación: modelo caro + esfuerzo alto (yo usé Opus 5 en extra high).
  • Escritura de código: modelo rápido y barato (Grok 4.6). Si el plan es bueno, el modelo que escribe importa mucho menos.
  • Tareas mecánicas (probar un login, llenar un formulario): baja el esfuerzo a medium o low. En modo extra high el agente piensa de más y avanza lentísimo para tareas que no lo necesitan.

Cambiar de modelo a mitad de un proyecto no es una rareza: es la forma correcta de usar el editor.

Grill Me: el skill que te interroga hasta que entiendas tu propio proyecto

El modo plan pregunta dos o tres cosas y arranca. Para funcionalidades serias eso no alcanza. Ahí entra Grill Me, un skill de Matt Pocock cuyo trabajo es uno solo: entrevistarte sin piedad sobre tu plan hasta que no queden huecos.

Se instala con el CLI de skills.sh, el registro abierto de agent skills:

npx skills@latest add mattpocock/skills

El instalador detecta Cursor y deja el skill listo a nivel de proyecto o global. Después basta con escribir /grill-me en el chat.

En mi caso llegué a 15 preguntas antes de que el plan se estabilizara; hay usuarios que reportan sesiones de 50 y hasta 100 preguntas. Y no son preguntas de relleno. Sobre EmoScan me señaló vacíos clínicos que yo no había considerado:

  • Un conteo diferencial real exige revisar entre 100 y 200 leucocitos: con una sola foto de un campo no se obtiene un hemograma, solo una estimación.
  • No estaba definido qué se mide exactamente ni qué debe devolver el análisis.
  • Si tres modelos opinan distinto y ninguno decide, ¿qué se le muestra al usuario?
  • ¿Dónde se despliega? ¿Qué pasa con la privacidad de las imágenes enviadas a proveedores externos? ¿Se le avisa al usuario antes de enviarlas?

Eso último es clave: responder el despliegue y la privacidad al inicio evita reescribir medio proyecto después. Cuando terminas la entrevista, el plan cambia de forma visible: más rutas, más detalle de frontend, riesgos, variables de entorno y una sección de despliegue que antes no existía.

Yo casi nunca lo uso para el "hola mundo" del proyecto. Lo uso cuando voy a meter una funcionalidad que sé que toca muchas partes.

2. Multitask y "Build in Parallel": los subagentes de Cursor

Esta es la función que la gente pide y ya está incluida. Los subagentes de Cursor son asistentes con su propio contexto a los que el agente principal delega trabajo. Vienen tres integrados (Explore, Bash y Browser) y pueden ejecutarse en primer plano o en segundo plano.

Hay dos formas de aprovecharlos:

  1. Pedirlo en el plan. En modo plan escribe algo como "haz que el plan lo puedan ejecutar múltiples subagentes". El plan se reorganiza en fases y marca qué tareas son paralelizables.
  2. El botón "Build in Parallel". Cursor identifica solo las partes independientes del plan y las lanza con subagentes asíncronos. Se anunció en la versión 3.3, junto con el comando /multitask para lanzar subagentes desde el editor en vez de encolar peticiones.

En mi proyecto el plan quedó dividido en fases: autenticación primero, y luego pacientes, captura, almacenamiento y resultados avanzando a la vez con flujos A, B, D1 y D2. Ojo con el orden: el proyecto tiene que estar inicializado antes; recién ahí tiene sentido paralelizar.

Dos advertencias honestas:

  • No es gratis en tokens. La propia documentación lo dice: cinco subagentes en paralelo consumen aproximadamente cinco veces los tokens. Cada uno arranca con su propio contexto.
  • No es rápido. Que sean paralelos no significa que termine en cinco minutos. Mi bloque completo tomó más de una hora. La ventaja no es la velocidad bruta, es que no tienes que estar ahí.

Un detalle que me sorprendió: como en la planificación ya había definido el entorno de despliegue y tenía el CLI de Railway instalado, el agente desplegó el proyecto solo y me devolvió la URL sin que yo pidiera "despliégalo paso a paso".

3. El editor dentro del navegador: Design Mode + Impeccable

El resultado funcionaba, pero el diseño era el típico slop de IA: genérico, plano y —error clásico— mobile first sin versión de escritorio, porque nadie lo especificó.

Aquí hay dos caminos, y conviene entender cuándo usar cada uno.

Design Mode: preciso, pero manual

Cursor tiene Design Mode: abres tu app en el navegador de la ventana de agentes, activas el modo con Ctrl/Cmd + Shift + D, haces clic en un elemento y el agente recibe ese elemento y su código. Puedes seleccionar varios, dibujar sobre la página o dictar por voz.

Es excelente para arreglos puntuales ("este botón no debería verse en todas las páginas"). El problema es que, elemento por elemento, terminas haciendo vibe coding otra vez.

Impeccable: rediseño con criterio

Para un rediseño completo uso Impeccable, un skill de diseño de código abierto (pbakaus/impeccable) que le da al agente un vocabulario de diseño real. Instalación:

npx impeccable install

El instalador detecta tu herramienta —Claude Code, Cursor, Copilot, Gemini CLI, Codex CLI— y escribe los archivos de skill correspondientes. Después, /impeccable en el chat te abre 23 subcomandos repartidos en crear (impeccable, shape), evaluar (audit, critique), refinar (layout, typeset, colorize, animate…), simplificar y endurecer (polish, optimize, harden).

Los dos que más valor dan:

  • shape: define propósito del sitio, usuario, contenido y qué debe sentir alguien al entrar, antes de generar nada.
  • audit: revisa si el diseño cumple métricas de accesibilidad y rendimiento.

Combinado con multitask ("crea un rediseño de todo el proyecto usando /impeccable"), lanza varios subagentes: uno critica una página, otro detecta zonas pendientes.

Lo que no hace: magia. Depende mucho del modelo que uses, y en mi prueba rediseñó bien la pantalla principal pero dejó otras páginas con la estructura vieja. Hay que pedirle explícitamente que evalúe página por página, y aun así conviene ir por las principales primero.

4. Testing automático: cuatro opciones y cuál elegir

Esta es la sección donde más gente se queda corta. Generar código es fácil; comprobar que funciona es lo que separa un demo de un proyecto.

Opción A — El navegador nativo de Cursor

Cursor trae automatización de navegador integrada sin instalar nada: navega, hace clic, escribe en formularios, toma capturas y lee consola y red. Se configura en Cursor Settings → Agents/Browser (pon la opción en Browser Tab en vez de Off) y el nivel de aprobación en Auto-Run.

Es lo más cómodo. En mi experiencia, sin embargo, no siempre termina bien las secuencias largas, y por eso suelo saltar a las siguientes dos.

Opción B — Chrome DevTools MCP

chrome-devtools-mcp es un servidor MCP que expone el control real del navegador a cualquier cliente: Cursor, Claude Code, Codex, VS Code, Copilot. En Cursor se instala con un botón desde su documentación y queda registrado como MCP.

Ventaja: ves el navegador trabajando. Limitación: habla con una sola instancia, así que no puedes probar tres flujos a la vez.

Opción C — Playwright CLI (mi favorita)

Aquí no hablamos de un MCP sino de una herramienta de consola oficial de Microsoft, playwright-cli, bajo licencia Apache-2.0. El agente simplemente ejecuta comandos.

npm install -g @playwright/cli@latest
playwright-cli install --skills

También puedes instalarlo desde skills.sh buscando playwright-cli. Cuidado con las variantes: hay skills parecidos publicados por otras empresas y usuarios; el que quieres es el de Microsoft, que es el estándar de facto. Instalarlo desde el registro evita el problema de que el skill quede en una carpeta que Cursor no lee.

A propósito de eso: Cursor lee los skills desde .agents/skills/ y .cursor/skills/ (proyecto), sus equivalentes en ~/ (global), y por compatibilidad también desde .claude/skills/ y .codex/skills/.

Por defecto corre headless —no porque esconda algo, sino porque no necesita pintar el navegador para probar—. Si quieres verlo:

playwright-cli open https://tu-app.local --headed

Y su gran ventaja sobre el MCP: puede lanzar varias instancias a la vez. Le pedí literalmente "ejecuta tres instancias de navegador: en una prueba el registro, en otra el login y en la otra un análisis" y abrió tres navegadores probando en paralelo, llenando datos de prueba y corrigiendo en código los errores que encontraba.

Opción D — TestSprite, cuando quieres reportes y grabaciones

TestSprite es una plataforma de testing que combina el framework, la manipulación del navegador y grabaciones en video de cada test. Se conecta por MCP y tiene tres modos de uso: conectado a GitHub (automático), por consola sobre un proyecto ya desplegado, o en local mientras desarrollas. Yo lo uso sobre todo después de desplegar.

El flujo real:

  1. Instalas el MCP en Cursor (botón directo desde su panel).
  2. Escribes: "usando TestSprite MCP, ayúdame a testear el proyecto".
  3. Eliges frontend o backend, todo el código base o solo los cambios, y entregas usuario y contraseña de prueba y el puerto local.
  4. Creas un PRD (Product Requirements Document). Este es el paso que casi todos se saltan y es el más importante: un resumen de qué hace el producto, visión y objetivos. No lo escribas a mano; pídele a un agente aparte que lo genere y lo guarde en el proyecto, y luego cárgalo.
  5. Generas una API key desde tu cuenta y se la pasas a Cursor.

El resultado es un panel con tests de todo tipo, y cuando algo falla tienes la grabación de lo que hizo la IA paso a paso. Un detalle importante para no volverse loco: muchos tests bloqueados no son bugs de tu app, sino falta de credenciales o de claves de terceros (en mi caso, la API key de OpenRouter). Cuando se la di, se generaron tests adicionales que antes ni podían ejecutarse.

Empezar es gratis, y el ciclo "ejecuta los tests → corrige los errores encontrados → vuelve a ejecutar" se puede repetir desde el mismo chat.

5. La vista IDE y tu propio skill personal

Hay un botón que dice IDE y que casi nadie que viene del vibe coding pulsa. Abre el mismo proyecto en la vista de editor clásica, con explorador de archivos.

¿Por qué importa en un proyecto de verdad?

  • Ahí ves las carpetas con punto (.agents, .cursor, .claude) donde viven tus skills y herramientas.
  • Puedes aprobar los cambios parte por parte en vez de aceptar todo a ciegas.
  • Con Ctrl/Cmd + P saltas directo al archivo que quieres revisar (escribe "login", enter, y estás ahí).

Y desde ahí llegamos a lo más útil a largo plazo: crear tu propio skill con tu forma de trabajar. Un skill no es magia ni un archivo oculto: es un .md guardado dentro del proyecto. Puedes pedirle a Cursor algo como:

Crea un skill propio llamado my-style que incluya: 1) validar siempre con Zod, 2) usar API routes sobre server actions, 3) crear una carpeta scripts para generar usuarios directamente en la base de datos.

Lo va a escribir en .cursor/skills/ y luego lo invocas con /my-style.

Pero revísalo. Dependiendo del modelo, a veces se extiende de más y mete ejemplos de código que se vuelven obsoletos rápido. Si una librería ya tiene un método nuevo más rápido, no quieres un skill que obligue al agente a usar el método viejo para siempre. Regla simple: si no entiendes una línea del skill, bórrala. Siempre puedes añadirla después.

Lo que verifiqué (y lo que deberías esperar)

Escribo esto porque el ecosistema de skills se mueve rápido y hay mucho contenido que promete resultados que no ocurren:

  • Sí funciona: los subagentes en paralelo, el despliegue automático si ya tienes el CLI de tu nube configurado, el testing multi-instancia con Playwright CLI y las grabaciones de TestSprite.
  • Funciona a medias: el navegador nativo de Cursor en secuencias largas, y el rediseño global de Impeccable, que no toca todas las páginas por sí solo.
  • No esperes: que sea barato en tokens (paralelizar multiplica el consumo), ni que sea rápido (más de una hora en mi caso), ni que el diseño quede impecable sin que tú des directrices concretas.
  • Un matiz sobre elegir modelos: los índices por dominio de Artificial Analysis (como el de Salud y Medicina) se construyen sobre evaluaciones agregadas de capacidad general en ese campo. Son una señal mucho mejor que el hype de X, pero no son una validación clínica: para un producto real de salud, el criterio profesional y la revisión humana siguen siendo obligatorios.

Nada de esto requiere una suscripción cara ni herramientas empresariales: son funciones incluidas en el plan estándar de Cursor más skills gratuitos y de código abierto.

Conclusión

El salto de productividad no viene de escribir mejores prompts. Viene de cambiar el orden: planificar bien primero (con Grill Me), repartir en paralelo después (multitask), rediseñar con criterio (Impeccable) y dejar que la propia herramienta pruebe lo que construyó (Playwright CLI o TestSprite).

Si lo haces así, dejas de ser el que aprueba cada mensaje y pasas a ser el que revisa el resultado. Que es, al final, para lo que sirve delegar.

¿Dudas o algo que te gustaría que profundice en un próximo artículo? Déjamelo en los comentarios. Y si necesitas ayuda aplicando esto a un proyecto real, puedes reservar una asesoría personalizada en fazt.dev.

Fuentes