Spec Driven Development: El Fin de la Programación por Intuición

Bienvenidos a mi breve charla sobre spec-driven development. Estamos al final de la codificación wipe, o tal vez mejor, la codificación wipe bien hecha. Primero, permítanme presentarme brevemente. Mi nombre es Daniel Sogel. Soy de Alemania. Trabajo como consultor principal para Thinktecture. Mi enfoque principal normalmente es, por supuesto, la ingeniería de software, pero también estoy muy interesado en este tipo de tema, cómo hacer que los desarrolladores sean más productivos, y por supuesto, también sobre la IA generativa. También soy un Microsoft MVP para tecnologías de desarrollo y web, porque mi principal stack tecnológico es la programación de aplicaciones web y también GitHub Copilot, por ejemplo.

Por eso fui promovido como MVP de Microsoft el año pasado. Vamos a sumergirnos en este tema. Me gustaría comenzar primero con la parte problemática donde los agentes de IA hoy en día todavía están luchando. Primero, tal vez cuando se lanza un nuevo LLM, encontrarás algunos benchmarks. Los proveedores de LLM normalmente intentan convencerte de que su LLM es realmente bueno cuando se trata de tareas de desarrollo de software. Por supuesto, esto no es algo falso. Es correcto, pero depende de qué benchmarks estés mirando. Por ejemplo, está este famoso benchmark SWE, pero también hay una versión pro disponible o pro score. Esto compara los LLM entre sí cuando se trata de tareas más complejas, más del mundo real.

Cuando miras estos puntajes de benchmark, puedes ver que incluso los nuevos LLM como, por ejemplo, SONET 4.5 todavía tienen dificultades para resolver esas tareas del mundo real. También depende, por supuesto, de qué números estés mirando. Por ejemplo, la última encuesta de Stack Overflow del año pasado muestra que el 66% de los desarrolladores necesitan pasar más tiempo corrigiendo el código cuando usan herramientas de codificación asistida por IA. Tal vez a primera vista, parece que todo está bien, pero cuando echas un segundo vistazo al código generado por tu agente de IA favorito, puedes ver que hay múltiples errores y necesitas más tiempo para corregirlos.

puedes ver que hay múltiples errores y necesitas más tiempo para corregirlos. Lo que también es peligroso e importante de observar son los problemas de seguridad y fallos de seguridad en el código generado por IA. También puedes ver números como este, 2.7 veces más problemas de seguridad en el código generado por IA. Por supuesto, todos esos problemas necesitan ser resueltos.

Espero poder mostrarte una solución a esos problemas usando Spectre desde el desarrollo. Así que, se han identificado cinco limitaciones principales, y todas esas limitaciones también deberían ser resueltas por Spectre desde el desarrollo. Primero, está la gestión de contexto. Solo tenemos pequeñas ventanas de contexto. Por supuesto, depende de qué LLMs estés usando, pero normalmente tenemos alrededor de 200,000 tokens de tamaños de ventana de contexto. Por supuesto, esta ventana de contexto es demasiado pequeña para incluir todo el conocimiento de la empresa y tampoco tu base de código completa en esta ventana de contexto. Luego tenemos la coordinación de múltiples archivos. Así que, cuando estás trabajando en proyectos complejos, no solo tienes una, dos o tres clases que están conectadas entre sí.

Normalmente, tienes flujos más complejos en tu aplicación, por lo que tu agente necesita actualizar todos esos archivos y supervisar todas esas estructuras de dependencia en tu base de código. Luego tenemos fallos silenciosos. Más sobre eso en la siguiente diapositiva. Este es el problema más peligroso que tenemos estos días cuando se trata de código generado por IA. Tenemos decisiones de arquitectura. Esto también es a menudo un problema cuando estás trabajando en un proyecto existente donde la arquitectura ya no está bien implementada. Cuando se trata de codificación asistida por IA, los agentes de IA también a menudo tienen dificultades para seguir las decisiones de arquitectura. Cuando los usas en un proyecto existente sin una buena arquitectura, por supuesto, los resultados serán realmente, realmente malos. Al final, el contexto empresarial también es un gran problema porque a veces tienes conocimiento dentro de una empresa que tal vez no está documentado en algún lugar o no en tu base de código. Entonces, ¿cómo debería el agente de IA saber que hay algunas reglas en tu empresa que la IA debería seguir cuando implementa código para ti? ¿Cómo resolver esos problemas?

Pero antes de eso, es realmente importante para mí hablar sobre esto y los patrones peligrosos. Porque cuando usas agentes de IA, y los uso todos los días, a menudo puedes ver que eliminan comprobaciones de seguridad de tu código. Por ejemplo, tienes un bloque try-catch y el agente piensa, está bien, no necesito este bloque try-catch porque tenemos otras comprobaciones de seguridad en nuestra base de código. Entonces, tal vez no sea relevante. Así que, eliminemos esto o algunos registros son eliminados, por lo que nunca verás que ocurrió un error. También tenemos este problema de hacerte feliz, diría yo. Así que, los agentes de IA intentan hacerte feliz generando código que se ajusta a tu estimación que tienes sobre ellos. Entonces, les das una tarea y el agente la resuelve. Pero a menudo, los agentes alucinan y añaden datos falsos o incorrectos al código. Así que, la tarea de código parece estar completada pero solo con la ayuda de datos falsos. Esto también sucede a menudo cuando, por ejemplo, escribes pruebas unitarias.

También, más sobre eso más tarde. Hay esta cita. Creo que esta es también una muy buena cita. Este tipo de fallos silenciosos es mucho peor que un fallo porque las salidas defectuosas a menudo funcionan sin ser detectadas hasta que surgen mucho más tarde. Así que, tal vez sepas que en el desarrollo de software, cuanto antes detectes un error, es más barato, es más rápido resolver este error. Y cuando tienes una base de código bien establecida y tratas de resolver este problema más tarde, por supuesto, esto tomará demasiado tiempo. Así que, finalmente, podemos hablar sobre el desarrollo de espectro. Y primero, nos ayuda a poner el contexto completo por adelantado. Así que, cuando más tarde usamos un agente de IA para resolver nuestras tareas, no necesitamos esperar hasta que el agente encuentre todo el contexto relevante necesario para resolver esta tarea porque hemos hecho este trabajo por adelantado. Más sobre eso, por supuesto, más tarde. Tenemos razonamiento estructurado, por lo que el agente siempre sabe lo que debe hacer paso a paso. Tenemos esto junto con los puntos de control de validación. Esto también es importante.

Así que, no es solo como, está bien, el agente genera código, sino que también hay algunos mecanismos que ayudan al agente a validar sus resultados de manera independiente. Luego, tenemos esta implementación autónoma. Por supuesto, esto actualmente no funciona al 100%, pero esto es tal vez para futuros LLMs y herramientas que vendrán en los próximos meses o semanas. El agente puede resolver completamente todas esas tareas sin nuestra necesidad de mirar el código porque combinaremos el desarrollo de espectro junto con el desarrollo impulsado por pruebas, por ejemplo. Así que, construimos realmente fuertes barandillas para nuestros agentes de IA.

Creo que esto es realmente importante. Deberíamos actuar con nuestros agentes de IA como si fueran nuestros programadores en pareja. Por eso Microsoft lo llama copilot y no como motores de búsqueda estúpidos. Por supuesto, son realmente buenos cuando se trata de buscar en nuestra base de código, pero tal vez cuando ya has usado tales agentes de IA, sabes que a menudo carecen de contexto cuando se trata de bases de código complejas. Así que, combinaremos el desarrollo de espectro, el qué y el por qué, junto con el desarrollo impulsado por comportamiento, el comportamiento del sistema, y el desarrollo impulsado por pruebas para la corrección del código. Así que, con estas tres categorías de flujos de desarrollo, deberíamos resolver todos esos problemas que te mostré antes.

Hay dos principales frameworks o bibliotecas que puedes usar ahí fuera. Por supuesto, hay múltiples disponibles, pero mis favoritos son OpenSpec y SpecKit. OpenSpec es un poco más ligero. Está hecho con TypeScript, y el flujo de trabajo es realmente simple. Solo hay una fase de propuesta donde defines tu especificación. Luego, tenemos nuestra fase de aplicación. Así que, el agente de IA está resolviendo la especificación o implementando la especificación por ti, y al final, solo puedes archivar los resultados. Eso es todo. Es una solución realmente simple. Por otro lado, tienes SpecKit de GitHub. Está basado en Python y muchos scripts de shell, y es más completo.

Así que, tenemos más tareas que podemos hacer con SpecKit. Así que, hay diferentes comandos slash o comandos slash personalizados que puedes ejecutar, y hay cuatro fases. Tenemos especificar, planificar, tarea e implementar, y más tarde te mostraré cómo todas esas fases trabajan juntas. Y esto comparado entre sí, hay diferentes proyectos en los que puedes o deberías usar esas herramientas. OpenSpec, porque es más ligero y más simple, es mejor para proyectos brownfield. Así que, tienes una base de código ya existente en la que quieres trabajar, y en esta base de código existente, puedes usar OpenSpec. Pero cuando tienes un proyecto greenfield, así que si no has tocado ninguna línea de código aún en tu nuevo proyecto, entonces SpecKit es la herramienta para ti.

ninguna línea de código aún en tu nuevo proyecto, entonces SpecKit es la herramienta para ti. Pero puedes combinarlo, por supuesto. Esto es algo que también me gusta hacer por mí mismo. Así que, cuando tengo un proyecto greenfield, primero uso SpecKit para especificar todo más detalladamente, y cuando la base está hecha por SpecKit, entonces puedo cambiar a OpenSpec para generar código o piezas de código más pequeñas. Así que, también podemos ver que, sí, el desarrollo impulsado por especificaciones ya es una realidad en la industria. Por ejemplo, hay un IDE propio desarrollado por AWS llamado Keyro.

Así que, sí, lanzaron este IDE, y sí, más de 250,000 desarrolladores están usando Keyro después de tres meses. Así que, sí, podemos ver que muchos desarrolladores están experimentando con esta tecnología o esta técnica para desarrollar software con la ayuda de IA. También hay algunos estudios internos, por ejemplo, de Delta Air Lines. Puedes ver que el 94% de los desarrolladores que usan el desarrollo impulsado por especificaciones están realmente satisfechos cuando se trata de este tipo de flujo de trabajo. Y también podemos ver en GitHub, por ejemplo, que todas esas bibliotecas están ganando mucha atención. También aquí, SpecKit, como un ejemplo, después de una semana, vimos que ya alcanzó más de 16,000 estrellas en GitHub.

Así que, podemos ver que muchos desarrolladores están adoptando este patrón realmente rápido y muy rápido. Así que, vamos a sumergirnos en las cuatro fases, especificar, planificar, tarea e implementar. Y antes de que incluso comiences a escribir una sola línea de especificación – no código, sino especificación – lo que es realmente importante es definir la llamada constitución. En esta constitución, defines reglas que el agente debería seguir más tarde, sin importar en qué tarea esté trabajando. Así que, no importa si es la fase de especificación o la fase de tarea o la fase de implementación. No importa. Así que, por ejemplo, en esta breve demostración, quiero construir una API de autenticación con Express y Node como un ejemplo. Así que, es realmente, realmente importante que la seguridad siempre sea lo primero. Así que, por ejemplo, deberíamos siempre validar nuestras entradas, como un ejemplo.

Esto es realmente importante más tarde. También te mostré esto en las diapositivas anteriores. También me gusta combinar spec-driven con behavior-driven y test-driven. Entonces, cuando usas agentes de IA y les dices que tienes una función existente, por ejemplo, y les dices, por favor escríbeme pruebas unitarias, normalmente escribirán pruebas evocreen. Entonces, esas pruebas están escritas para ajustarse a tu código existente. Así que, esas pruebas unitarias nunca te dirán que hay un error dentro de tu código existente. Por eso el desarrollo impulsado por pruebas funciona muy bien cuando se trata de código generado por IA. Entonces, en esta constitución, le digo a los agentes, está bien, cuando escribas o implementes más tarde una tarea, deberías escribir la prueba primero e implementar después de eso. Entonces, escribes una prueba sólida, el agente genera código, la prueba se ejecutará, y luego puedes ver, está bien, ¿la prueba pasa sí o no? Y es divertido ver, porque uso mucho spec-driven en mis proyectos, puedes ver a menudo que la implementación falla en el primer intento. Así que, es un patrón realmente bueno. Usa el desarrollo impulsado por pruebas en tu constitución.

Y, por supuesto, está realmente condensado. Hay más reglas que puedes agregar a este archivo. Depende de tus preferencias. Y, por supuesto, siempre puedes usar IA para pedirle a tu LLM favorito que tal vez mejore tu constitución. Y después de eso, finalmente es hora de comenzar con la primera fase, la parte de especificación. Y este es el único archivo que realmente escribes a mano, porque es el fundamento del desarrollo impulsado por especificaciones, porque este es el nombre. De aquí proviene el nombre, la especificación. Y la especificación trata sobre el qué y el por qué, y no sobre el cómo. Y así, es para definir todo, lo que te gustaría lograr y cómo lograrlo, pero no con qué tipo de tecnología te gustaría lograr tus objetivos. Así que, no escribes algo sobre, quiero construir un backend usando NextJS, y el frontend también debería usar NextJS, por ejemplo. Ahora, escribes lo que te gustaría lograr y por qué te gustaría lograrlo. Y luego, puedes ver aquí, algunas salidas son un poco inestables. Puedes ver que Copilot, en este caso, creó cinco historias de usuario, pero las nombró P1, P1, P2, P2, y P3. Así que, a veces es solo una salida rota, porque así es como funcionan los LLMs.

Pero en este caso, Copilot creó cinco escenarios de usuario basados en mi especificación para crear un backend de autenticación. Y también podemos ver que esta especificación también se desglosa en requisitos funcionales, entidades, criterios de éxito, y eso es realmente importante, casos límite. También siempre deberías pensar en casos límite, por ejemplo, cuando se trata de autenticación, cómo debería manejar más tarde el backend un token que ya no es válido, o el refresco falló, algo así. Es realmente importante pensar en casos límite. Luego, está esta fase de planificación.

Y en la fase de planificación, puedes ponerte técnico. Y esto es cuando los ingenieros de software pueden usar sus habilidades. Con suerte, sabes cómo crear una buena arquitectura, qué bibliotecas te gusta usar, y así sucesivamente. Y luego, le dices a tu LLM favorito, nuevamente, de tu elección, qué tecnologías te gusta usar.

Entonces, en este caso, por ejemplo, quiero usar JWT, quiero usar SQLite, limitación de tasa, Express, Node 22, LTS, TypeScript o lo que sea, VTests. No importa. Todo lo técnico ahora se define en esta fase. Y también es, sí, realmente importante pensar en tu stack tecnológico aquí en esta fase. Y luego, puedes ver aquí también algunas capturas de pantalla sobre la salida.

Puedes ver, primero, hubo investigación. El copilot o el LLM detrás de copilot verificó todo, si esas bibliotecas que me gusta usar son compatibles entre sí, como ejemplo. Luego, se diseñó un diseño y contratos. Puedes ver aquí el OpenAPI YAML como un ejemplo para definir cómo debería verse la API al final. Y está el plan de implementación. Cómo solo cosas técnicas junto con las especificaciones deberían implementarse juntas más tarde.

Y luego, solo quedan dos fases. Tenemos la fase de tareas, y esto es realmente simple. Normalmente, solo ejecutas el comando de tarea en copilot o tu herramienta de codificación de agentes de IA favorita de tu elección. Y luego, el LLM dividirá esas tareas técnicas y tu especificación en pequeñas tareas. Y cada tarea puede ser implementada y probada independientemente una de otra. Entonces, puedes, si lo deseas, en este caso, crear 89 commits después de la implementación. Así que, cada tarea será un commit, como ejemplo. Y cada tarea puede ser probada independientemente. Y podemos ver aquí, pequeña tarea de autenticación back-end con JWT usando Express. Es un proyecto Greenfield, en este caso. Puedes ver, al final, creará 89 tareas. Así que, es realmente, realmente detallado.

Y la última fase es donde ocurre la magia. Entregas esta lista de tareas y la constitución y el plan y la especificación y todo lo demás generado por los LLMs antes a uno o, si lo deseas, a múltiples agentes de IA, y ahora trabajarán en esas tareas. Y también puedes ver en esta captura de pantalla, porque usé desarrollo guiado por pruebas, también puedes ver que cada archivo o cada funcionalidad en esta pequeña demo fue bien probada. Así que, tenemos alrededor de 26 pruebas unitarias. Y como describí antes en la constitución, primero guiado por pruebas. Así que, sí, los LLMs generaron las pruebas antes de que realmente comenzaran la implementación técnica al final. Así que, puedo estar seguro de que las características están funcionando, pero por supuesto, deberías más tarde echar un vistazo más de cerca por ti mismo en la base de código.

Entonces, ¿dónde realmente vale la pena SDD? Porque no todo es perfecto, por supuesto. Entonces, donde sobresale en proyectos Greenfield, está funcionando realmente bien. Así que, cuando comienzas de cero a uno, puedes usar spec.hit de GitHub para crear una descripción realmente completa y detallada y lo que te gustaría lograr. Para características complejas, también está funcionando realmente bien porque tienes los archivos smart down describiendo todo lo necesario para el agente. Así que, defines esos límites. El agente no debería, con suerte, alucinar al final. Y también puedes usarlo realmente bien para la coordinación de múltiples agentes. Así que, tal vez sepas que esto también es algo que no solo tienes un agente ejecutándose localmente, sino que también puede entregar algunas tareas a agentes de fondo, por ejemplo. Así que, esto también funciona realmente bien. Pero SDD también tiene dificultades en algunos proyectos y condiciones. Por ejemplo, cuando se trata de pequeñas correcciones de errores, tal vez spec.driven sea un poco excesivo.

Por ejemplo, usar spec.hit para una especificación toma alrededor de 30 minutos, tal vez más, cuando especificas algo realmente detallado. Y cuando se trata de corregir errores, por supuesto, tal vez arreglar el error te llevará cinco minutos. ¿Por qué deberías definir múltiples archivos markdown? Además, para la creación rápida de prototipos y tal vez desarrolladores en solitario, cuando deseas lograr algo realmente, realmente rápido, entonces, por supuesto, spec.driven te hará más lento. Por supuesto, tal vez los resultados sean mejores. Pero cuando se trata de prototipos, la calidad del código, la seguridad tal vez no sea realmente importante para ti. Solo quieres probar algo. Entonces, por supuesto, el desarrollo spec.driven también es un poco demasiado para tu tarea.

Entonces, ¿cuáles son los puntos clave para resumir todo? Entonces, los agentes de IA son, por supuesto, poderosos, pero están limitados cuando miras los números actuales. Como si estuvieran creando código falso o incorrecto, problemas de seguridad, los desarrolladores necesitan corregir más errores cuando escriben código por sí mismos. Tal vez serían más rápidos. Entonces, son poderosos, pero limitados. Y el desarrollo spec.driven cambia de el código como única fuente de verdad a la intención como verdad. Entonces, nuestras especificaciones definen cuál es la verdadera verdad y no el código en sí. Así que, las especificaciones también se vuelven más ejecutables a través de la IA con la ayuda de tus agentes de IA favoritos o subagentes.

Pero es realmente importante elegir la herramienta adecuada. Solo te mostré dos, OpenSpec y Speckit. También está este IDE de AWS. Kiro, que mencioné. Hay diferentes bibliotecas disponibles. Así que siéntete libre de probarlas para que se adapten a tu flujo de trabajo específico. Y también podemos ver, por ejemplo, servidores MCP o instrucciones personalizadas. El desarrollo spec.driven será un estándar en el sector empresarial porque es realmente importante para tus proyectos complejos que tengas una especificación realmente sólida. Todo está documentado. Sabes por qué lograste algo y por qué implementaste algo de la manera en que lo implementaste. Así que esto también será realmente importante en el futuro.