¿Cuál Es la Diferencia Entre spec, plan e implementation? El Flujo de Trabajo Correcto para Superpowers

Los artículos anteriores cubrieron "activar hábitos primero, hacer brainstorming primero para llegar al consenso de diseño." El siguiente punto de bloqueo común es: el diseño está acordado — ¿ahora qué? Mucha gente en este punto simplemente dice "okay, empieza a escribir" — y el agente se lanza a modificar archivos, solo para descubrir a mitad de camino que nadie escribió nunca "cuántos pasos, y qué verificar en cada uno." El spec, plan e implementation en el título de este artículo mapean a tres niveles en lenguaje sencillo a continuación, y este artículo explica dónde encaja writing-plans en toda la cadena.

En esta serie, así es cómo pensar acerca de spec (especificación): toma los requisitos y el diseño que se han discutido y alineado, y escríbelos en un documento que tanto tú como el agente han confirmado — indicando claramente qué construir, qué deliberadamente no se está construyendo, cómo saber que está terminado y qué restricciones o acuerdos de interfaz aplican. Todavía no es una tabla de ejecución de "qué archivo modificar en qué paso." Plan es esa guía de ejecución paso a paso con puntos de verificación (quién hace qué, en qué orden, cómo verificar cada segmento). Implementation es realmente ir a modificar código, ejecutar pruebas y entregar resultados según el plan. Una oración para principiantes: spec define "qué y los límites"; plan define "en qué orden hacerlo"; implementation es "realmente hacerlo."

La Diferencia Entre Requisitos, Diseño, Plan e Implementation

Los tres términos anteriores son una categorización por tipo de resultado. Si desglosamos la primera mitad en "cómo crecen las ideas," la progresión de vago a específico generalmente se ve así:

Requisito: "¿Qué problema estamos resolviendo? ¿Quién lo usa? ¿Cómo se ve el éxito?" — todavía hablando sobre por qué y para quién, los detalles todavía pueden ser aproximados.
Diseño: "¿Qué enfoque, cuáles son los límites, qué está deliberadamente excluido, cómo se conecta al código existente?" — ahora hablando sobre qué camino tomar y cuáles son los trade-offs. El brainstorming generalmente ayuda a alinear esta parte.
Plan: "¿Qué pasos, qué orden, qué verificar después de cada paso, dónde están los puntos de riesgo?" — este es el mapa de ruta ejecutable. Todavía no se ha escrito código, pero "el próximo paso no es adivinar" ya está establecido.
Implementation: Realmente modificar archivos, ejecutar pruebas, abrir un PR — siguiendo el alcance y la definición de terminado del spec, en el orden del plan.

Alinear 1 y 2 y escribirlos en un documento confirmado es el spec de arriba. Solo entonces pasas al plan en el paso 3, y finalmente al paso 4. Mucha gente trata "el diseño está discutido" como "listo para construir" — pero en el medio puede seguir faltando la caída al spec (de lo contrario el consenso solo vive en la conversación), y también puede faltar la capa del plan. Sin ellos, la implementación fácilmente se convierte en inventar el alcance y el proceso mientras se escribe código, y la probabilidad de retrabajo se dispara.

El Papel de writing-plans

En el vocabulario de Superpowers, el papel de un skill de proceso writing-plans es simple: después de tener una dirección (o incluso un spec aproximado), escribe "cómo aterrizarlo" en un plan que otros (incluyendo tú en el futuro) puedan seguir sin desviarse del rumbo.

No es repetir el brainstorming: el brainstorming se enfoca en seleccionar opciones, alinear la intención; writing-plans se enfoca en dividir el camino elegido en pasos, marcar puntos de verificación y dejar espacio para retroceder. Piénsalo como: un gerente de proyecto escribiendo una lista de tareas de sprint — excepto que el lector es frecuentemente un AI agent, por lo que el plan necesita ser suficientemente explícito para que el agente no tome atajos hacia el destino incorrecto.

En la práctica frecuentemente cubre: qué archivos o módulos tocar, el orden recomendado, cómo verificar después de que cada segmento se complete, dónde están las trampas que necesitan pruebas tempranas. El punto no es escribir de forma elegante — es ser ejecutable y verificable.

El Orden Correcto para Aterrizar el Trabajo

Los principiantes pueden memorizar esta secuencia, que conecta con los artículos anteriores de la serie:

using-superpowers: Confirma qué flujos de trabajo aplican esta vez; no escribas código en el momento en que llegas.
brainstorming (cuando sea necesario): Aclara requisitos, lista opciones, elige un camino y define límites — consenso de diseño.
writing-plans (cuando hay escala o múltiples pasos): Escribe el camino de aterrizaje como un plan — quién hace qué primero y cómo verificar.
Skill de implementación / implementación real: Sigue el plan para modificar código. Si también hay guardarraíles de calidad como TDD, debugging o verification-before-completion, adjúntalos según el contexto (el siguiente artículo cubre esto en detalle).

No cada corrección de una línea necesita un plan extenso, pero siempre que tengas el pensamiento "esto probablemente tomará varios pasos" o "me temo que cambiar A romperá B," escribir un plan corto casi siempre es más barato que apagar incendios después.

Por Qué Es Peligroso Saltar a la Implementación Sin un Plan

Sin un plan, aquí hay guiones comunes (aprender de estos cuenta como una victoria; es mejor no experimentarlos de primera mano):

El agente primero modifica el archivo más fácil de tocar, solo para darse cuenta después de que el orden era incorrecto y toda la sección necesita revertirse.
A mitad de camino, falta una dependencia, pruebas o configuración de entorno — el "plan" se convierte en "inventar sobre la marcha."
Creíste que había terminado, pero solo se terminó la UI o solo la mitad de la API — porque la "definición de terminado" nunca se escribió.
Cuando múltiples personas o múltiples conversaciones transfieren el trabajo, la siguiente persona no puede decir "por qué se cambió de esta manera" y tiene que hacer telepatía nueva.

Un plan convierte "asumí que entendías" en "está escrito en blanco y negro." Ya sea para humanos o AI Agents: menos adivinanzas, menos retrabajo.

Próximos Pasos

Para entender TDD, debugging y verificación previa a la finalización — los tres pasos de verificación que siguen a la implementación: TDD, systematic-debugging, verification-before-completion: Tres Guardarraíles de Calidad para Agentes de IA.
Para trazar todo el camino de principio a fin: Curso para Principiantes de Superpowers.

Volver al Índice de la Serie

Este artículo cubre los niveles de spec / plan / implementation y el papel de writing-plans. Para volver al mapa de lectura de la serie y el orden recomendado, abre el Curso para Principiantes de Superpowers.