Apariencia
Spec-Driven Coding > Vibe Coding
El vibe coding parece rápido — hasta que intentas mantener lo que entregaste. A los seis meses, las funcionalidades interactúan de formas que nadie anticipó, el contexto se perdió, y cada cambio generado por IA arriesga romper tres cosas que olvidaste que existían. El coste oculto no es el código en sí, sino la ausencia de un contrato: sin una spec, la IA no tiene una fuente de verdad, el desarrollador no tiene red de seguridad, y el codebase no tiene memoria. El Desarrollo Orientado a Specs (SDD) es la respuesta: escribe el comportamiento primero, bloquéalo como contrato, y luego deja que la IA ejecute contra él. La spec es el trabajo; el código es el resultado.
Los 7 Principios
Una lista de principios para codificación asistida por IA ampliamente compartida ha generado un debate útil. Coincidimos con la mayoría. Donde no estamos de acuerdo, lo decimos — y explicamos el mecanismo detrás de nuestra posición.
1. "No vibe coding if you care about what you build." ✓ Acuerdo
Aceptar el output de la IA sin leerlo, ejecutarlo y entenderlo es como acumular deuda invisible. Planu lo hace imposible estructuralmente: create_spec requiere criterios de aceptación antes de generar cualquier código, y validate ejecuta una verificación de conformidad contra esos criterios después de la implementación. No existe ningún atajo que permita que una spec llegue a done sin que la implementación haya sido probada contra su propio contrato. Si omites la spec, Planu se niega a continuar. Ver el ciclo completo de specs.
2. "Always understand the code it generates." ✓ Acuerdo
El código generado que no entiendes es un pasivo que no puedes auditar ni depurar. Las herramientas elicit_requirements y clarify_requirements de Planu sacan la ambigüedad a la superficie antes de la generación, de modo que el desarrollador nunca recibe una caja negra — aprobó la spec que la produjo. Los criterios de aceptación en cada spec están escritos de forma que el desarrollador pueda leer el output e inmediatamente verificar: ¿hace este código lo que los criterios decían? Cómo se escriben los criterios.
3. "Don't generate an entire project from scratch with AI." ↻ Matizado
Verdad — sin una spec. Cuando una IA genera desde cero sin restricciones, obtienes un prototipo que parece plausible pero sin comportamiento declarado y sin forma de verificar su corrección. Con una spec aprobada en Planu, generar desde cero es exactamente lo que hacemos, y es seguro precisamente porque la spec es el contrato. La herramienta update_status bloquea cualquier transición de draft → approved hasta que los criterios tengan suficiente detalle para validar. Una vez aprobada, la spec es la fuente de verdad — generar a partir de ella no es imprudente, es el objetivo. Cómo funciona el spec.md unificado · Transiciones de estado.
4. "Keep asking questions until you fully understand the task." ✓ Acuerdo
Un modelo que adivina en lugar de preguntar produce respuestas incorrectas con confianza. Planu lo formaliza con InteractiveQuestion[]: cuando una herramienta necesita clarificación, devuelve un array estructurado de preguntas que el agente transmite al usuario antes de continuar. Nada se asume; cada ambigüedad se convierte en una pregunta explícita con opciones tipadas. No es una preferencia de estilo — está impuesto en la capa de herramientas. Mecanismo.
5. "Use your token budget wisely — don't dump your entire codebase." ✓ Acuerdo
El exceso de tokens degrada la atención del modelo e incrementa el coste sin mejorar la calidad del output. Planu aborda esto con una superficie MCP enfocada: el agente ve 27 tools SDD oficiales en vez de un catálogo gigante. Los flujos avanzados pasan a skills, CLI y pipelines internos. El contexto se mantiene ajustado; la señal se mantiene alta. Cómo funciona la superficie enfocada.
6. "Have sufficient knowledge — AI amplifies skills, it doesn't replace them." ✓ Acuerdo
Un desarrollador que no entiende el dominio no puede evaluar el output de la IA, y la IA no puede compensar esa brecha. Planu institucionaliza el conocimiento mediante skills (archivos de reglas reutilizables que el agente carga por tarea), log_decision para capturar decisiones arquitectónicas, y log_lesson para el aprendizaje post-implementación. El objetivo no es reemplazar la experiencia, sino hacerla persistente, buscable y disponible para la IA como contexto estructurado en lugar de intuiciones. Skills y gestión del conocimiento.
7. "Stop chasing every new AI model that comes out." ⚠ Desacuerdo
Distinguimos seguir de perseguir. Perseguir significa actualizar en pánico cada vez que sale un anuncio, reescribir prompts para un nuevo modelo antes de evaluar si realmente cambia los resultados, y quemar tiempo del equipo en ciclos de modelo-del-mes. Ese es el mal consejo que conviene rechazar. Pero "deja de perseguir" puede deslizarse hacia "deja de seguir", y eso es peor: ignorar un salto de capacidad generacional (mejor razonamiento, menor coste a la misma calidad) porque estás harto de anuncios. La propia regla de selección de modelos de Planu — aplicada en la capa de reglas globales — es: clasifica la tarea, usa el nivel de modelo correcto, y sube de nivel solo cuando hay una ganancia clara de calidad o coste. Eso requiere estar informado. Sigue. Evalúa. Actualiza cuando valga la pena. No persigas, pero tampoco te desconectes. Fundamento de selección de modelos.
¿Listo para dejar el vibe coding?
Pon specs entre tú y la IA — y deja que el código sea un resultado, no el plan.