.jpg)
En las Partes 1 a 3 explicamos el enfoque Spec-Driven Development, el proyecto Estación Estación y el flujo de trabajo con agent-os. Entregamos ocho funcionalidades desplegadas y operativas, pero ahora toca hablar con honestidad sobre los retos reales que aparecieron durante el desarrollo y qué problemas resolvió la estructura SDD y cuáles aún requirieron depuración tradicional.
Reto 1 Cloudflare y la autenticación
El bloqueo más frustrante fue lograr la autenticación con el portal Myki. Sin autenticación no hay datos y el proyecto quedaba parado. Cloudflare Turnstile detectaba y bloqueaba navegadores headless, así que la implementación inicial con Playwright en modo headless fue inmediatamente interceptada por la pantalla Verifying you are human. La especificación decía simplemente extraer el token Bearer para llamadas a la API, lo que definía el objetivo pero no cómo sortear la detección de bots.
Cómo ayudó SDD El desglose en tareas dejó claro el mapa de trabajo Launch browser Navigate to login page Fill credentials Submit form Extract token y permitió localizar exactamente en qué paso Cloudflare intervenía. Registrar los intentos fallidos en la spec evitó repetir errores y mantuvo el foco en el criterio de éxito.
Qué no resolvió SDD La solución exigió conocimiento de fingerprinting y muchos ensayos y errores. Investigar mostró que crear un perfil de navegador persistente con metadatos mínimos y lanzar Playwright en contexto persistente en modo visible es lo que funcionó para que Cloudflare tratara el navegador como real. Ese descubrimiento vino de experimentación manual, no de la spec.
Reto 2 Bug multidispositivo manualAttendanceDates
Después de tener el flujo end to end, añadí una configuración manualAttendanceDates para marcar días en que fui a la oficina sin usar Myki. Aunque la especificación era clara, la funcionalidad falló por múltiples problemas de integración entre backend Python, GitHub Actions y frontend React. Gracias a la spec pude seguir el flujo de datos y comprobar cada capa en orden, lo que aceleró la localización de errores: fusión incorrecta de fechas en Python, workflow que no propagaba el nuevo campo y renderizado frontend que no buscaba la clave adecuada.
Qué no resolvió SDD Encontrar los archivos y la línea exacta que requerían cambio exigió revisión manual del código y conocimiento de cómo fluye la configuración entre componentes. La AI arregló partes concretas cuando le indiqué dónde actuar, pero identificar esas ubicaciones fue trabajo humano.
Reto 3 Zonas horarias
Las fechas del calendario aparecían desplazadas un día respecto a attendance.json. La spec dejaba claro que las fechas debían coincidir exactamente, lo que ayudó a detectar el error, pero no anticipó la suposición implícita sobre timezone. El problema fue usar conversiones a UTC que cambiaban la fecha cerca de medianoche. La corrección fue forzar formato local YYYY-MM-DD con toLocaleDateString o construir la fecha desde componentes año mes día.
Qué no resolvió SDD El equipo necesitó conocimiento de cómo JavaScript maneja fechas y la decisión explícita de usar la zona horaria local, algo que no suele estar presente en una especificación a menos que se haya sufrido ese fallo antes.
Reto 4 Integración con librerías externas
Integrar date-holidays para detectar feriados de Victoria fue sencillo en la especificación pero la librería devolvía cadenas con marca horaria en lugar de objetos Date. La spec indicó qué librería usar y la apariencia esperada en calendario, pero no el formato de retorno real. La solución fue inspeccionar la salida y convertir la subcadena YYYY-MM-DD en un objeto Date usando año mes y día.
Qué no resolvió SDD Solo ejecutar y revisar la librería reveló la discrepancia. La spec documentó luego la conversión para futuras referencias, pero no pudo evitar el descubrimiento en tiempo de ejecución.
Reto 5 Preferencias de usuario vs suposiciones de desarrollador
Por defecto weekends se mostraban en rojo. Como desarrollador quise cambiarlo, pero al preguntar al usuario resultó que prefería conservar esa señal visual. El flujo SDD crea puntos naturales para pedir retroalimentación y evitar cambios apresurados, pero no sustituye la comunicación real con usuarios.
Dónde SDD aportó más valor
La estructura SDD marcó criterios de éxito claros lo que hizo evidentes los fallos; facilitó una depuración sistemática con tareas que describían el recorrido de los datos; dejó documentación de decisiones y soluciones para retomar el trabajo sin perder contexto; y estableció puntos de revisión que evitaron decisiones prematuras. En resumen SDD aceleró la localización de fallos y mejoró la resiliencia del proyecto frente a interrupciones del desarrollador.
Qué no reemplaza SDD
SDD no sustituye el conocimiento técnico ni la investigación. No evita bugs en integraciones multi capa ni los efectos sutiles de zonas horarias o formatos de terceros. Tampoco sabe lo que prefieren los usuarios. Lo que hace es ofrecer un marco que reduce la probabilidad de perderse y facilita documentar las soluciones cuando aparecen problemas inesperados.
ROI honesto
Tiempo en especificaciones alrededor de 4 a 5 horas implementación y despliegue principal unas 48 horas depuración adicional 4 a 6 horas total aproximado tres días para ocho funcionalidades desplegadas. Donde SDD ahorró tiempo fue en depuración sistemática documentalidad y reanudabilidad; el coste fue tiempo inicial en escribir specs y aprender el flujo agent-os, inversiones que se amortizan en proyectos posteriores.
Conclusión y próximos pasos
Spec-Driven Development no es una varita mágica pero sí una caja de herramientas para afrontar problemas complejos de manera ordenada. Proporciona claridad objetivos y trazabilidad; los retos técnicos profundos siguen exigiendo investigación y persistencia. En la Parte 5 ofreceré un marco de decisión para elegir cuándo usar SDD y cómo empezar con Estación Estación.
Sobre Q2BSTUDIO
En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida especializada en inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, automatización de procesos y soluciones de inteligencia de negocio como Power BI. Diseñamos software a medida y agentes IA para empresas que necesitan soluciones prácticas y seguras. Si te interesa conocer cómo adaptamos IA a procesos reales visita nuestra página de inteligencia artificial y para proyectos de desarrollo de aplicaciones y software a medida consulta desarrollo de aplicaciones multiplataforma.
Palabras clave
aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws azure servicios inteligencia de negocio ia para empresas agentes IA power bi
.jpg)