Spec-Driven Development para iOS: cuando programar se parece a ingeniería de procesos
Spec-Driven Development para iOS: cuando programar se parece a ingeniería de procesos
TL;DR: si venís de ingeniería de procesos, el Spec-Driven Development no suena tan extraño. En el fondo, se parece bastante a definir especificaciones, planificar una intervención, ejecutar con método y revisar antes de liberar.
Este post nace de un video que publiqué en YouTube: Spec driven development para iOS siendo ingeniero de procesos.
La pregunta de fondo es bastante personal: ¿cómo construís software de calidad si no venís de ingeniería de software?
Soy ingeniero químico y trabajo hace casi 14 años en ingeniería de procesos. Programé en Python, entiendo algo de arquitectura y fui aprendiendo herramientas, pero no me formé como desarrollador tradicional. Entonces, cuando pienso en construir una app iOS, no me interesa solamente “hacer que funcione”. Me interesa construir con método.
Ahí aparece el Spec-Driven Development.
Lo familiar de especificar antes de construir
En ingeniería de procesos, una especificación no es decoración. Define qué tiene que cumplir un producto, una pieza o una operación para ser aceptable.
Hay límites. Hay criterios. Hay documentación. Hay revisión.
Si algo se desvía, no alcanza con decir “más o menos funciona”. Hay que entender qué cambió, por qué cambió y si sigue dentro de lo aceptable.
Cuando miro el Spec-Driven Development desde ese lugar, deja de parecer una moda de software y empieza a sonar bastante familiar.
Una feature también puede pensarse como una pieza de proceso:
- tiene una intención;
- tiene restricciones;
- tiene criterios de aceptación;
- tiene riesgos;
- necesita implementación;
- necesita revisión.
La diferencia es el material. En vez de nylon, catalizadores o variables de planta, trabajamos con código, interfaces, estados y datos.
Pero el patrón mental no está tan lejos.
Hacer apps sin arrancar desde el caos
Una de las cosas que más me preocupa al aprender iOS es arrancar con prácticas viejas.
iOS evoluciona rápido. Swift cambia. SwiftUI madura. Xcode incorpora herramientas nuevas. Lo que hace unos años era una buena decisión hoy puede estar deprecado o, al menos, no ser el mejor punto de partida.
Por eso en el video intento armar un template moderno para proyectos iOS con Spec-Driven Development.
La idea no es tener una carpeta linda. La idea es tener un entorno repetible:
- Xcode actualizado;
- SwiftFormat para formato;
- SwiftLint para reglas;
- XcodeBeautify para leer mejor los builds;
- GitHub CLI para publicar y trabajar con repos;
- UV para instalar herramientas Python;
- Spec Kit para ordenar especificaciones;
- MCP para conectar herramientas al flujo de agentes;
- una estructura de documentación que marque cómo se trabaja.
En otras palabras: no quiero aprender iOS acumulando código suelto. Quiero construir un sistema de trabajo.
Agentes con roles, no un solo “chat que hace todo”
La parte más interesante para mí es separar responsabilidades entre agentes o modelos.
Un flujo razonable podría ser:
- Planner / Specifier: un modelo fuerte, como Opus, ayuda a clarificar, especificar y planificar.
- Implementer: un modelo más rápido, como Sonnet, ejecuta una tarea por vez.
- Reviewer: un modelo fuerte revisa criterio, concurrencia, edge cases y calidad.
- Second opinion: eventualmente Codex/GPT puede actuar como mirada externa.
Esto también se parece mucho a ingeniería.
La persona que define el criterio, la que ejecuta y la que revisa no tienen por qué ocupar exactamente el mismo rol mental. Separar esas funciones reduce el riesgo de mezclar intención, implementación y validación en una sola masa confusa.
El agente no reemplaza criterio. Pero puede ayudar a sostener un flujo más disciplinado.
Spec Kit como andamio
Spec Kit me interesa porque no se queda solamente en “escribí mejor el prompt”. Propone un andamiaje:
- una constitución del proyecto;
- especificaciones por feature;
- planes de implementación;
- tareas más chicas;
- criterios de revisión;
- estructura repetible.
Eso para mí es clave. Cuando uno no viene de ingeniería de software, necesita apoyarse en estructura. No para volverse rígido, sino para no depender solamente de inspiración o intuición.
En procesos pasa algo parecido: una buena metodología no reemplaza experiencia, pero evita que cada problema se ataque desde cero.
El objetivo: apps para ingenieros de procesos
Todo esto no es solamente para aprender Swift por aprender Swift.
Estoy pensando en una aplicación que ayude a resolver problemas de ingeniería de procesos. Hay mucho hilo para tirar ahí: diagnóstico, análisis de variables, documentación de casos, soporte para decisiones, seguimiento de problemas, herramientas para el día a día de planta.
La oportunidad que veo es juntar tres mundos:
- experiencia real en ingeniería de procesos;
- desarrollo moderno en iOS;
- agentes de IA como soporte para especificar, construir y revisar.
No sé todavía cuál será la forma final de esa app. Pero sí sé que quiero construirla con una base más seria que “abrir Xcode y ver qué sale”.
Cierre
Spec-Driven Development me interesa porque traduce algo que ya respeto desde procesos: antes de intervenir, entender; antes de construir, especificar; antes de liberar, revisar.
Quizás ese sea el puente que necesitaba.
No entre ingeniería química y software como dos mundos separados, sino entre dos formas de hacer lo mismo: construir sistemas que funcionen mejor.
Ampliaremos.