El «Vibe Coding» es seductor: lanzas una idea vaga, la IA interpreta tu «vibra» y, mágicamente, el código aparece. Sin embargo, para un Arquitecto de Soluciones, la «magia» sin estructura es deuda técnica latente. La diferencia fundamental no está en el modelo (LLM), sino en la gestión de la memoria y el contexto.
1. La Trampa del Vibe Coding: El «Efecto Memoria de Pez»
El Vibe Coding depende casi exclusivamente del historial del chat. A medida que el «scroll» aumenta, ocurre un fenómeno crítico:
- Pérdida de Contexto: Las instrucciones iniciales se diluyen en la ventana de contexto del modelo. Si tu gold (contexto) «brilla en rojo», estás en peligro de perder precisión.
- Consumo Ineficiente de Tokens: Al perder el hilo, la IA debe re-escanear todo el código base para «entender» qué se ha hecho, lo que dispara el consumo de tokens y aumenta la latencia.
- La Alucinación por Ambigüedad: Sin una fuente de verdad, la IA empieza a adivinar implementaciones, lo que te obliga a realizar correcciones manuales constantes.
2. El Instinto del Veterano: La Historia de John y el Contexto Persistente
Mucho antes de que el término SDD se formalizara, ingenieros veteranos como John Miller ya aplicaban un principio básico de ingeniería de sistemas: si no está escrito de forma persistente, no existe.
Hace años, John no confiaba su arquitectura a la memoria volátil de una sesión de chat. Su instinto le dictó una estrategia de «Providence»:
- Guardaba cada prompt y cada respuesta en archivos Markdown organizados por año, mes y día.
- Al iniciar una nueva sesión, no empezaba de cero; cargaba un archivo de resumen (summary.md) para reducir el ruido y enfocar a la IA en los principios core del proyecto.
- El aprendizaje: John entendió que el chat es solo una interfaz de transporte, pero el archivo de texto (.md, .yaml) es el verdadero cerebro del sistema.
3. SDD: Crear Contexto como Artefacto de Primera Clase
A diferencia del Vibe Coding, el Spec-Driven Development propone que el contexto no sea un subproducto del chat, sino un artefacto versionado.
- Fuente de Verdad: Se definen especificaciones técnicas, principios de equipo y flujos de trabajo en archivos que viven en el repositorio.
- Evitar el «Efecto Confluence»: Al mantener la documentación junto al código, evitas que esta muera por obsolescencia. Si la documentación no está actualizada, no sirve ni para el humano ni para la IA.
El Ganador: OpenSpec.dev y la Elegancia del «Delta»
De todos los frameworks de SDD, OpenSpec destaca por su manejo quirúrgico del contexto. Su filosofía es «acuerda antes de construir», y su flujo se basa en tres etapas clave que resuelven el problema del historial infinito:
¿Cómo maneja OpenSpec el Contexto y los Deltas?
- La Propuesta Estructurada (/opsx:propose):
OpenSpec no «asume». Genera cuatro artefactos exhaustivos antes de tocar una línea de código:
- Propuesta: El «por qué» desde el negocio.
- Specs: Requerimientos y escenarios (estilo BDD/Cucumber).
- Diseño: Racional técnico y decisiones de arquitectura (por qué usar un patrón y no otro).
- Tareas: Una checklist hiper-detallada donde incluso cada test unitario es una tarea.
- Implementación con apply: Al ejecutar la implementación, la IA está «atada» a los artefactos creados. No puede alucinar porque su contexto está restringido por las tareas y el diseño previamente acordados.
- El Cierre Maestro: /opsx:archive y la Gestión de Deltas:
Aquí es donde OpenSpec brilla sobre el resto. Cuando terminas una funcionalidad y lanzas archive:
- Transformación de Contexto: Lo que era un «cambio» (una feature aislada) se convierte en documentación formal del proyecto.
- Manejo de Deltas: Si pides un cambio sobre algo existente (ej. añadir Login con Google a un módulo de Auth), OpenSpec revisa lo archivado y solo genera el «delta» o la diferencia necesaria.
- Esto garantiza que cada nueva instrucción se base en el estado real y documentado del sistema, no en lo que se habló en un chat hace tres semanas.
Conclusión
Mientras el Vibe Coding es una carrera de velocidad que termina en un muro de confusión, OpenSpec y SDD son una maratón de precisión. Al final del día, el mejor código no es el que se genera más rápido, sino el que tiene el contexto más sólido detrás.