NicoPaez

La semana pasada puse en producción una aplicación construida con la estrategia de desarrollo conocida como Spec-Driven Development (SDD).

La aplicación no era gran cosa, pero tampoco era un ejemplo de juguete. Era una web app construida sobre el framework NestJS, con Bootstrap, vanilla JavaScript, una base de datos PostgreSQL e integración con la API de Google Calendar. Tal vez lo más importante: tenía usuarios reales, lo cual implicó un ambiente productivo y su correspondiente operación.

La aplicación la construí yo solo (con asistencia de IA) de punta a punta. Me encargué del descubrimiento/relevamiento con el cliente y, a partir de ahí, fui armando la especificación funcional traducida en user stories cargadas en un tablero de gestión (GitLab Issues). Estas stories representaron el input para el proceso de SDD.

Para implementar Spec-Driven Development utilicé el framework OpenSpec con OpenCode y GitHub Copilot como agentes de programación. Como IDE utilicé Visual Studio Code con los correspondientes plugins para los mencionados agentes.

Comencé armando la estructura base del proyecto a mano, pues hay ciertas cuestiones que me gusta tratar de una forma distinta a la que propone NestJS. También armé a mano toda la configuración de GitLab: el pipeline de CI/CD, el tablero de proyecto y la estructura de documentación en la wiki.

Si bien estaba clara la infraestructura necesaria para correr la aplicación, no estaba definido en qué servicio de cloud correría, así que inicialmente levanté un ambiente de prueba en Render. Finalmente, escribí algunos lineamientos de trabajo para OpenSpec (openspec/config.yaml) y comencé el desarrollo con la intención de no tocar código.

Fui trabajando a nivel funcionalidad con stories «feteadas» bien finitas de forma vertical, de manera tal de mantener acotada la duración de los ciclos de interacción con la IA. Al cabo de un par de horas de trabajo ya tenía algo mostrable a mi cliente.

Si bien todo el tiempo revisé las especificaciones generadas por OpenSpec (proposal, design y tasks), solo en las primeras stories revisé el código generado. Al hacerlo, encontré algunas cuestiones que no me convencieron y, ante ello, actualicé los lineamientos de OpenSpec.

Finalmente, como ambiente productivo se decidió utilizar Dokku (una plataforma PaaS, similar a Heroku pero de código abierto). Todo el setup de la infraestructura, el monitoreo y los scripts de despliegue asociados los hice a mano (en parte porque reutilicé artefactos que ya tenía armados de otros proyectos).

Algunas conclusiones:

• Interfaz de usuario (UI): Para algunas cuestiones de pantallas/interfaz de usuario varias veces metí mano directamente, pues me parecía incómodo e inconveniente hacerlo vía IA (detalles como alineación, tamaños, etc.). Seguramente me podría haber ahorrado esto si proveía a la IA lineamientos más específicos sobre la UI. Imagino que en un contexto organizacional uno debería proveer a la IA un design system, cosa que en mi caso no tenía.
• Velocidad de modelos: Noté diferencias de velocidad entre los modelos de IA pagos y los gratuitos (los pagos me resultaron más rápidos), aunque dado que mis ciclos de trabajo eran cortos, esa diferencia no me resultó significativa.
• Precisión de modelos: También noté diferencias en la precisión de los modelos. Concretamente, en algunos casos con los modelos gratuitos me encontré con que ignoraban algunos de mis lineamientos, generando errores de linting o pruebas que fallaban.
• Uso de scaffolding y tokens: Todo el código, más allá de mi esqueleto base, fue generado por la IA, cuando tal vez parte de ese código podría haber sido generado utilizando la funcionalidad de scaffolding del framework web (nestjs-cli), lo cual habría permitido ahorrar tokens. Creo que definitivamente este es un tema para tener presente a la hora de dar lineamientos a la IA.
• Arquitectura y modularidad: Una vez completado el primer release a producción, revisé la solución de punta a punta y me encontré con varias cuestiones mejorables, principalmente relacionadas con la modularidad. La solución quedó armada en un único módulo, con algunos archivos, clases y métodos demasiado grandes para mi gusto. Creo que esto también podría llegar a ajustarse en las especificaciones para la IA.

Me queda la sensación de que, por más ricas o completas que sean las especificaciones que pueda darle a la IA, es posible que siga habiendo algunas cuestiones que prefiera (o convenga) ajustar a mano.

En las próximas semanas está planificado hacer algunas actualizaciones funcionales a la aplicación en base al feedback de los usuarios. Ya compartiré cómo me va con eso.