Contenido del curso
Crear la base full-stack del producto
- 6

Composer ejecuta el spec 01 en Cursor
02:26 min - 7

Cómo actualizar dependencias con IA de forma segura
06:34 min - 8

MCP en Cursor: valida tu API con datos reales
07:32 min - 9

Hooks en Cursor: guardianes automáticos para tu código
07:20 min - 10

Multitask y Playwright MCP: automatiza tu QA en Cursor
06:20 min - 11

Git Worktrees: haz competir dos modelos de IA
05:26 min
Calidad, entrega y automatización
Cursor divide tu PRD en specs con subagentes




Todos los cursos GRATIS
Resumen
El spec-driven development es la técnica que te permite tomar un documento PRD y dividirlo en especificaciones técnicas pequeñas que un subagente puede ejecutar por sí solo. Si trabajas con Cursor y quieres acelerar la construcción de software, aquí ves cómo hacerlo paso a paso y por qué importa.
Qué es el spec-driven development y por qué conviene usarlo
La idea central es sencilla: en lugar de darle a la IA un documento enorme y esperar que lo resuelva todo, fragmentas ese PRD en specs pequeños y autocontenidos. Cada spec queda tan acotado que un subagente lo puede tomar y ejecutar sin depender del resto.
¿Qué es el spec-driven development? Es la práctica de tomar un PRD y dividirlo en especificaciones técnicas pequeñas, cada una lo bastante independiente como para que un subagente la ejecute por su cuenta.
Esto cambia la forma de trabajar. Un PRD grande se vuelve inmanejable, pero once specs bien definidos permiten repartir el trabajo y ganar velocidad.
Por qué Cursor te hace preguntas antes de crear los specs
Antes de generar nada, el prompt te devuelve preguntas que debes responder [00:14]. Y aquí viene lo interesante: esas preguntas no son relleno, son decisiones técnicas que definen el rumbo del proyecto.
En el ejemplo aparecieron dos casos concretos:
- El PRD mencionaba un SDK ligero con un cache de TTL de 30 a 60 segundos de propagación, pero no había un spec dedicado a ese SDK. La decisión fue no incluir el SDK en esta iteración.
- Para el spec
01 monorepo setup, había que elegir el orquestador: PMP workspaces con Turborepo o sin él. Se optó por PMP workspaces sin Turborepo.
Puedes seleccionar una de las respuestas propuestas o escribir directamente lo que tú quieras. Esa flexibilidad es clave, porque tú mandas sobre las decisiones, no el agente.
¿Por qué responder preguntas antes de generar specs? Porque definen decisiones técnicas como el orquestador o si incluir un SDK. Sin esas respuestas, el agente asumiría cosas que tal vez no quieres.
Cómo funciona el plan que genera Cursor
Después de responder las preguntas, Cursor genera un plan [01:03]. Este documento es la fuente de verdad de las decisiones y reúne varios elementos importantes:
- El PRD como base y el stack elegido, en este caso sin SDK.
- La plantilla obligatoria que debe seguir cada spec.
- El mapeo de cada spec con respecto al PRD.
Lee el plan completo antes de avanzar. Si algo no te convence, puedes editarlo directamente en esa vista. No delegues esa revisión, porque el plan condiciona todo lo que viene después.
Cuando ya estés convencido, en la parte superior derecha aparece el botón build. Y si das clic en la flecha de la derecha, se despliegan más opciones.
Qué diferencia hay entre build, build local y build in parallel
Cursor ofrece tres formas de ejecutar el plan, cada una con su propósito:
- Build: la ejecución estándar.
- Build local: hace el build dentro de tu propia máquina.
- Build in parallel: ejecuta varias tareas al mismo tiempo para ganar velocidad.
La opción build in parallel revisa los to-dos de la parte inferior y decide cuáles puede paralelizar. Puede hacerlo o no, dependiendo del contenido de cada spec y de las relaciones entre ellos.
Cómo Cursor lanza subagentes en paralelo para ahorrar tiempo
Al activar build in parallel, Cursor lanzó tres subagentes al mismo tiempo [01:47]. El reparto fue así:
- El primer subagente creó los specs del uno al tres.
- El segundo se encargó del cuatro, cinco y nueve.
- El tercero tomó el seis, siete, ocho, diez y once.
Eso significa que entre esos grupos no había dependencias, y el propio Cursor decidió que tres agentes bastaban para ejecutar unas tareas en serie y otras en paralelo.
¿Cómo decide Cursor cuántos subagentes lanzar? Analiza las relaciones entre los specs y lanza automáticamente los subagentes necesarios, paralelizando solo las tareas que no dependen entre sí.
En este ejemplo solo estamos creando specs, pero la magia aparece cuando construyes software grande. Ahí esta paralelización de subagentes te ahorra muchísimo tiempo, porque Cursor levanta automáticamente los que necesite y, al terminar, te entrega el resumen dentro de la misma conversación.
Cuál es tu misión con el PRD y los specs
Tu tarea es tomar el documento PRD que ya tienes y dividirlo en specs usando el prompt que encuentras en la sección de recursos. Tienes dos caminos:
- Usar el prompt tal cual, con los specs ya descritos.
- Quitar los specs descritos y dejar que el agente proponga la cantidad de specs que considere.
Esa decisión es tuya. Prueba ambas rutas y cuéntame en los comentarios cuántos specs te propuso el agente cuando lo dejaste elegir.