¡Hola a todos! Bienvenidos al día 1 de este diario de desarrollo. Durante las próximas semanas voy a documentar el proceso paso a paso de cómo construyo una aplicación web real desde cero.
Pero no lo haré a ciegas. Para este proyecto no voy a programar de la forma tradicional, ni tampoco voy a improvisar. Voy a utilizar Spec-Driven Development (SDD) apoyándome en la herramienta de estándar abierto más potente del ecosistema: GitHub Spec Kit.
🎯 El Proyecto: El Comparador Inteligente de Hipotecas
La aplicación que vamos a construir tiene un propósito muy claro y una lógica de negocio que se presta perfectamente para el desarrollo guiado por especificaciones:
- Comparador Multihipoteca: Permitirá introducir y comparar de forma simultánea hasta 3 hipotecas con sus respectivos tipos de interés (fijo, variable o mixto), plazos y comisiones de apertura.
- Simulador de Vinculaciones (Complementos): Podremos añadir productos adicionales vinculados que habitualmente proponen los bancos para rebajar el diferencial de la hipoteca (seguro de vida, seguro de hogar, domiciliación de nómina, plan de pensiones, alarma, etc.).
-
Cálculo de Viabilidad Real (El "Árbitro Financiero"): Evaluaremos si un complemento del banco realmente merece la pena.
- Ejemplo: Si contratar el seguro de vida del banco te reduce la hipoteca un 0.1% (ahorrándote 15€ al mes en la cuota), pero ese seguro contratado con el banco cuesta 300€ anuales (25€/mes) y contratarlo por fuera de manera independiente te costaría 200€ anuales (16.6€/mes)... ¿Vale la pena la bonificación? El sistema calculará matemáticamente si estás perdiendo o ganando dinero con la vinculación.
🛠️ ¿Por qué elijo GitHub Spec Kit?
Para gestionar el ciclo de vida de este desarrollo, he elegido GitHub Spec Kit. Los motivos son muy sencillos:
-
Independencia de modelos (Model-Agnostic): Spec Kit no me ata a un solo proveedor de IA. Funciona mediante un CLI (
specify) y plantillas estándar. Esto me permite orquestar mis especificaciones utilizando cualquier LLM tanto local (ej: qwen3.5:9b) como cloud (ej: modelos top tier de Claude, OpenAI, Gemini...) -
Estructura y Comandos Estandarizados: Spec Kit nos dota de un flujo estructurado a través de comandos claros (
/constitution,/specify,/plan,/tasks,/implement). No tengo que inventar la estructura de carpetas; el framework se encarga de que la especificación y el código vivan en armonía. -
Sincronización nativa en Git: La especificación (en formato Markdown con metadatos YAML basados en OpenSpec) se guarda directamente en la carpeta
.specify/de nuestro repositorio. De este modo, si modificamos el comportamiento de nuestra calculadora de seguros de vida, editamos primero el archivo.mdde especificación, y Spec Kit regenerará el código de forma controlada.
🥊 Tablas Comparativas: El Ecosistema de Desarrollo en 2026
Para entender el valor de lo que vamos a hacer, observemos cómo se compara SDD frente al resto de enfoques.
1. SDD vs. Metodologías de Diseño y Desarrollo (TDD y BDD)
| Criterio | TDD (Test-Driven) | BDD (Behavior-Driven) | SDD (Spec-Driven / Spec Kit) |
|---|---|---|---|
| Artefacto Principal | Pruebas unitarias de código (e.g. Jest, PyTest). | Escenarios de usuario en lenguaje de negocio (Gherkin: Given/When/Then). | Especificación ejecutable estructurada (Arquitectura, reglas EARS, APIs, fórmulas matemáticas). |
| Foco del Proceso | Calidad del código y diseño técnico interno. | Colaboración estrecha entre desarrollo, producto y negocio. | Sincronizar el diseño humano con la ejecución ultra-precisa de agentes de IA y humanos. |
| Rol de la IA | Te asiste sugiriendo código para hacer pasar un test. | Puede generar tests a partir de historias de negocio escritas en lenguaje natural. | Lee la spec, genera un plan técnico estructurado, desglosa tareas y escribe el código funcional y los tests. |
2. SDD vs. Vibe Coding (Improvisación con IA)
| Aspecto | Vibe Coding (Improvisación) | SDD con Spec Kit (Guiado por Spec) |
|---|---|---|
| Aproximación | Prompts rápidos y ambiguos ("Créame un comparador de hipotecas con seguros"). | Especificaciones acotadas basadas en reglas lógicas estandarizadas utilizando sintaxis EARS. |
| Escalabilidad | Muy baja. Al crecer la base de código, la IA sufre "degradación de contexto" y rompe funciones viejas al arreglar bugs. | Muy alta. La IA consulta la "Constitución" del proyecto y el archivo de especificación en el repo para no desviarse jamás. |
| Lógica Matemática | Frecuentemente errónea. Las IAs suelen fallar con fórmulas de amortización complejas si no se les guía de cerca. | Exacta. Las fórmulas financieras están explicitadas en la spec como requerimientos inflexibles que el código debe respetar. |
⚙️ El Plan de Ataque: El Flujo en 4 Fases
A partir de mañana, para cada funcionalidad (como el módulo de carga de hipotecas, el simulador de seguros o la interfaz de comparación gráfica), repetiremos este ciclo soportado por Spec Kit:
-
Especificar (Specify): Redactaremos un archivo
calculator.mdbajo el estándar OpenSpec, detallando las fórmulas financieras con reglas exactas de tipo EARS ("CUANDO el usuario active el seguro de hogar, ENTONCES el sistema reducirá el diferencial en un 0.20% y sumará 250€ al gasto anual del perfil"). -
Planificar (Plan): El agente de IA traducirá la spec en un
plan.mdtécnico (qué librerías usaremos para calcular las fechas, base de datos en local, etc.). - Crear Tareas (Tasks): Dividiremos el plan en tareas de programación atómicas para que puedan ser ejecutadas sin errores colaterales.
- Implementar (Implement): El programador o la IA completarán cada tarea asegurándose de que los cálculos pasen la verificación frente a la spec inicial.
🚀 ¿Qué sigue?
Utilizar Spec Kit nos asegura que nuestro simulador financiero será matemáticamente preciso y perfectamente escalable a medida que añadamos más tipos de vinculaciones (como planes de pensiones o alarmas).
En el próximo post de este diario, definiremos la "Constitución" técnica de nuestra App y mucho más.
¡Nos vemos en el Día 2! ¡Déjame en los comentarios qué características te gustaría que incluyamos en el comparador!
Top comments (0)