Spec-Driven Development:From Code to Contract in the Age of AI Coding Assistants
Este artículo presenta una guía exhaustiva sobre el Desarrollo Impulsado por Especificaciones (SDD, por sus siglas en inglés), describiendo sus principios, tres niveles de rigor de especificación y las herramientas de apoyo para demostrar cómo tratar las especificaciones como el artefacto principal puede aprovechar eficazmente los asistentes de codificación con IA en diversos dominios de software.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que estás contratando a un robot chef muy talentoso, increíblemente rápido, pero ligeramente literal, para cocinar una comida compleja para ti.
La vieja forma (Primero el código):
Te acercas al robot y le dices: "Hazme una cena deliciosa".
El robot, ansioso por complacer, comienza inmediatamente a picar verduras y a calentar sartenes. Supone que quieres pasta. Supone que la quieres picante. Supone que quieres usar ese costoso aceite de trufa que no mencionaste.
Diez minutos después, tienes un plato de pasta con trufa y picante. Tú querías una ensalada.
Ahora tienes que decirle al robot que se detenga, tirar la pasta y empezar de nuevo. Esto es lo que el artículo llama "vibe coding" (programación por sensaciones): confiar en instrucciones vagas donde la IA tiene que adivinar tu intención. El resultado suele ser un desastre que requiere correcciones constantes.
La nueva forma (Desarrollo basado en especificaciones):
En lugar de gritar órdenes, primero escribes una tarjeta de receta (la Especificación).
Escribes exactamente: "Quiero una ensalada. Usa espinacas, tomates y feta. Sin nueces. El aderezo aparte. Sírvela a temperatura ambiente".
Le entregas la tarjeta al robot. El robot la lee, verifica su comprensión y entonces comienza a cocinar.
Si el robot intenta añadir nueces, se detiene porque la tarjeta dice "Sin nueces". Si intenta servirla caliente, se detiene.
En este escenario, la tarjeta de la receta es la jefa. La comida (el código) es solo el resultado de seguir la receta. Si la comida sabe mal, no culpas al chef; revisas si la receta fue clara.
Los tres niveles de rigurosidad
El artículo explica que no siempre necesitas un contrato de 50 páginas. Hay tres formas de usar este enfoque de la "tarjeta de receta", dependiendo de qué tan serio seas:
Spec-First (El "Boceto"):
- Qué es: Escribes la receta antes de empezar a cocinar para asegurarte de que todos estén de acuerdo en lo que van a preparar.
- Cuándo usarlo: Ideal para probar una idea nueva o un proyecto de una sola vez.
- El inconveniente: Una vez cocinada la comida, podrías tirar la tarjeta de la receta. Si cambias la receta más tarde, es posible que la tarjeta no se actualice. Es bueno para empezar, pero no para el mantenimiento a largo plazo.
Spec-Anchored (El "Menú Vivo"):
- Qué es: La tarjeta de la receta se mantiene en la nevera junto a la estufa. Cada vez que cambies el plato (añadir más queso, cambiar el aderezo), debes actualizar la tarjeta inmediatamente.
- Cuándo usarlo: Este es el punto ideal para la mayoría de las cocinas profesionales (software de producción).
- La magia: La cocina tiene un robot inspector. Si el chef cambia el plato pero olvida actualizar la tarjeta, el inspector hace sonar una alarma. Esto asegura que el menú (documentación) siempre coincida con la comida (software).
Spec-as-Source (La "Impresora 3D"):
- Qué es: Esta es la versión más extrema. Nunca tocas la comida directamente. Solo editas la tarjeta de la receta. Una máquina entonces automáticamente imprime la comida basándose únicamente en esa tarjeta.
- Cuándo usarlo: Se utiliza en campos de alto riesgo como la construcción de motores de coches o dispositivos médicos, donde un error podría ser peligroso.
- La regla: Si quieres cambiar los frenos de un coche, no metes la mano bajo el capó con una llave inglesa. Cambias el plano, y la máquina reconstruye los frenos perfectamente. Nunca se te permite editar manualmente las piezas generadas.
Por qué la IA hace esto necesario
El artículo argumenta que los asistentes de programación por IA son como ese robot chef talentoso pero literal. Son increíbles siguiendo instrucciones, pero terribles para "leer la mente".
- Sin una especificación: Le pides a la IA que "añada una función de inicio de sesión". La IA adivina las reglas de la contraseña, el tipo de base de datos y el nivel de seguridad. A menudo se equivoca.
- Con una especificación: Le das a la IA un contrato claro: "El inicio de sesión requiere una contraseña de 12 caracteres, usa email y bloquea la cuenta tras 3 intentos fallidos". La IA sigue las reglas perfectamente.
El flujo de trabajo: Una danza de cuatro pasos
El artículo sugiere un ritmo sencillo para este proceso:
- Especificar: Escribe el "Qué". (La Receta).
- Planificar: Escribe el "Cómo". (La lista de compras y la disposición de la cocina).
- Implementar: Construirlo. (La cocina).
- Validar: Comprobarlo. (La prueba de sabor). Si el sabor no coincide con la receta, corriges la cocina o actualizas la receta, pero nunca ignoras la discrepancia.
Cuándo usarlo (Y cuándo no)
El artículo proporciona una guía de decisión sencilla:
- Úsalo cuando: Estés construyendo algo grande, trabajando con un equipo, usando IA o construyendo algo donde los errores sean costosos (como la banca o los coches).
- No lo uses cuando: Estés haciendo un prototipo rápido para desechar, o seas un desarrollador solitario construyendo una aplicación de lista de tareas simple donde los requisitos son obvios. En esos casos, escribir una receta detallada es simplemente una pérdida de tiempo.
La gran conclusión
Durante décadas, los desarrolladores de software escribieron primero el código y escribieron la "receta" (documentación) después, si es que la escribían. Este artículo dice: Invierte la lógica.
Haz de la Especificación la cosa principal que creas. Trata al Código como un simple producto automático de esa especificación.
Al hacer esto, dejas de adivinar, dejas de pelear con tus herramientas de IA y te aseguras de construir exactamente lo que pretendías construir. El código se convierte en una sombra de la especificación, no al revés.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.