Uso del Desarrollo Dirigido por Especificaciones para Flujos de Trabajo de Producción

Hola a todos, mi nombre es Eric Hanchet, y hoy quiero contarles todo sobre el desarrollo dirigido por especificaciones y cómo podrían usarlo en sus flujos de trabajo hoy. Así que hay un par de cosas de las que queremos hablar. Primero, ¿qué es el desarrollo dirigido por especificaciones? Y luego, ¿cómo puede hacerte un programador mejor y más rápido? Así que no solo queremos que programes más rápido, sino que realmente queremos que crees un código de mayor calidad a partir de ello. Y realmente creo que el desarrollo dirigido por especificaciones te ayuda con esto, y voy a explicar por qué y cómo.

Así que echemos un vistazo a una definición de desarrollo dirigido por especificaciones. Básicamente, es un código estructurado. Las especificaciones se crean antes de que se escriba cualquier código. Esa es la definición de realmente las especificaciones o los requisitos de este desarrollo dirigido por especificaciones. Y va al corazón de lo que es. Así que lo que estamos haciendo es escribir estos archivos markdown. Estamos escribiendo las especificaciones y el documento de diseño antes de que se escriba cualquier código. Y esto realmente funciona muy, muy bien con los modelos de lenguaje grandes y nuestros asistentes de codificación que usamos. Y voy a mostrarles exactamente cómo funciona eso.

Ahora, una pregunta que a veces recibo es ¿por qué? Como, ¿por qué deberíamos usar este flujo de trabajo de desarrollo dirigido por especificaciones y luego cómo podemos hacerlo? Así que para responder a esa pregunta de por qué, me gusta pensar en nuestros asistentes de codificación, nuestros modelos de lenguaje grandes que usamos todos los días como una especie de pasantes de IA. Realmente necesitas incitarlos. Realmente necesitas empujarlos de la manera correcta. Sin juego de palabras con la incitación. Así que realmente necesitas guiarlos porque si les das solo un poco de libertad, se desviarán. Y realmente el desarrollo dirigido por especificaciones ayuda a guiarlos en la dirección correcta.

Recuerdo cuando era un pasante, y en uno de mis primeros trabajos, teníamos un VP que caminaba por ahí y simplemente se le ocurrían ideas aleatorias de la nada. Y cuando me lo decía, dejaba todo y trabajaba en ello. Y luego mi jefe me decía, oye, Eric, ¿por qué dejaste todo? Bueno, el VP dijo algo. Y luego aprendí que tienes que tomar la información que te da, escribirla, ponerla en tu agenda, hablar conmigo, hablar con mi gerente al respecto. Así que estaba un poco demasiado ansioso. Y esto es lo que los pasantes de IA o básicamente estos modelos de lenguaje grandes hacen hoy en día. Y tenemos que tener cuidado con eso.

No te di realmente mucha introducción, así que te la daré ahora. Mi nombre es Eric Hanchett. Soy un defensor de desarrolladores senior en AWS. Tengo más de 15 años de experiencia en desarrollo de software. Y si quieres conectarte conmigo, puedes buscarme en LinkedIn. Probablemente sea el mejor lugar para ir. Solo busca a Eric Hanchett y sí, háblame, sígueme. Me encantaría hablar más contigo al respecto. Otra pregunta que la gente a menudo me hace sobre el desarrollo de espectro es ¿no pueden los modelos de frontera más recientes hacer todo por nosotros ya? ¿Por qué necesitamos esto? Y aunque digo que los modelos están mejorando cada año y cada lanzamiento, a veces incrementalmente, a veces a pasos agigantados, todavía no es perfecto.

Y dar al modelo de lenguaje grande, a estos modelos más contexto es realmente importante porque ayuda a guiarlos en la dirección correcta. Y con nuestro software siempre cambiando y con los requisitos siempre cambiando, y con nuevos paradigmas y cambios, siempre necesitas guiarlos hacia donde necesitan ir. Algunos modelos de lenguaje grandes, algunos arneses están comenzando a pensar más en esto y añadiendo un poco más de un modo de pensamiento o planificación antes de que salte a cuando escribe código. Pero no hay nada mejor que tener esos documentos creados y estar tú en el medio antes de que salte a esa siguiente parte con él, creando código. Así que tengamos en cuenta algunas cosas antes de avanzar demasiado. Hay bastante información por ahí y tengo algunas opiniones. Estas son mis opiniones. Déjame saber, conéctate conmigo en LinkedIn si estás de acuerdo o en desacuerdo. Pero creo que necesitas tener esto en cuenta antes de usar el desarrollo de espectro o la codificación de vibraciones o cualquier cosa intermedia.

Tenemos que, tienes que tener cuidado con el contexto. Ahora, te dije antes que el desarrollo de espectro te da mucho contexto que se alimenta a ese modelo de lenguaje grande, pero a veces tienes demasiado de algo bueno. Lo que necesitas hacer es cuando trabajas con estos modelos de lenguaje grandes, usualmente creas como un agents.md o un claw.md al principio con algo de información en él. Tendría mucho cuidado de no poner demasiada información o muy poca información en eso. Algo así como esa zona de información de Ricitos de Oro es lo que necesitas. Así que solo necesitas darle suficientes reglas y pautas para que sepa qué hacer. Eso es exactamente de lo que se habla en agents.md o steering. Lo llamamos documentos de dirección en Kiro, de lo cual mencionaré en un minuto, pero solo tienes que tener mucho cuidado con lo que pones en esos documentos.

También recomiendo encarecidamente cuando uses el desarrollo de espectro usar habilidades. Las habilidades son como archivos de instrucciones que puedes dar a tus agentes de codificación que se ejecutan bajo demanda. Así que usualmente tienen palabras clave en ellos. Y cuando el asistente de codificación ve esas palabras clave, activarán la habilidad o puedes hacer slash en el nombre de la habilidad y luego ejecutarla. Pero esto realmente ayuda cuando estás haciendo el proceso de desarrollo de espectro, puedes realmente agregar habilidades cuando crea tus documentos de diseño o cualquier otra cosa que puedas usar en paralelo con el desarrollo de espectro o cuando realmente implementas las tareas. Y solo ten cuidado con dar demasiada confianza. Recuerda, todo en el flujo de desarrollo de espectro eres tú, lo que significa que tú eres el humano en el bucle, por así decirlo. Tú necesitas ser el revisor de código de todo el código que se genera a través de este proceso. Tú necesitas estar mirando interactivamente los documentos de diseño y los documentos de requisitos que se crean, porque al final del día, si algo sale mal, tú eres la persona que va a ser culpada por ello, no el agente.

Y eso no quiere decir que no usemos herramientas para ayudar a hacer revisiones de código. Alguien una vez me dijo como, ¿estás diciendo que eres el humano en el bucle? Hiciste la revisión de código, nadie más. Por supuesto, podríamos tener múltiples personas haciendo revisiones de código. Y definitivamente usa tus asistentes de codificación AI normales y herramientas de revisión para ayudarte a revisar cualquier solicitud de extracción que crees. O CRs. Así que déjame darte una pequeña lección de historia de dónde hemos estado, especialmente en AWS. Vimos esta necesidad, especialmente de nuestros equipos y nuestros clientes que estaban codificando con vibraciones, estaban usando este asistente de codificación, pero no estaban obteniendo los resultados que querían. Y lo que vimos es esto, estos clientes estaban usando este patrón a medida de tener los agentes, los asistentes de codificación crear estos documentos de requisitos completos y estos documentos de diseño. Y decidimos crear una aplicación para hacer esto todo por ellos. Así que lanzamos Kiro a finales del año pasado en disponibilidad general. Es nuestro nuevo asistente de codificación AI IDE. También tenemos una versión de interfaz de línea de comandos o CLI, que es igual de popular. Creo que ahora mismo está cambiando.

La mayoría de las personas están comenzando a usar CLIs más a menudo que IDEs. Así que si te gusta hacer eso, puedes usar el CLI. Pero en lo que realmente nos enfocamos con Kiro, como puedes ver en estas capturas de pantalla, es en este modo vibe y spec. Así que vamos a adentrarnos en el modo spec en un momento, pero realmente pensamos que esto realmente abarcaba lo que estábamos escuchando de nuestros clientes. Pero la gente quería más formas de trabajar con características más grandes y proyectos más complejos, y realmente necesitaban que el asistente de codificación supiera exactamente lo que su proyecto estaba haciendo. También lanzamos el sitio web en kiro.dev. Siéntete libre, después de esta presentación, de ir a revisarlo. Puedes descargar nuestro CLI, nuestro IDE, y probarlo, porque realmente estamos orgullosos de ello. Es divertido. Cuando lanzamos esto, en realidad se volvió un poco viral. Obtuvimos decenas de miles de descargas. Muchas personas nos preguntaban sobre Kiro, así que estábamos realmente felices de lanzar esto. Cuando lo configuramos en vista previa, tuvimos tantas descargas que tuvimos que poner una puerta delante de él. Y luego la gente encontró la manera de rodear la puerta, pero ahora está disponible públicamente para que todos lo prueben y le den una oportunidad. Pero no quiero que esto sea una presentación de media hora para Kiro. Puedes hacer este desarrollo impulsado por especificaciones sin Kiro. Hay algunas maneras. Una es que básicamente tienes que hacer esto manualmente con cualquier cosa. Podrías decirle a tu asistente, tu modelo de lenguaje grande, que incluya lo siguiente. Primero son los requisitos del usuario. Les dirías, por favor, basado en X, Y, Z, crea un conjunto completo de requisitos del usuario. Ahora, puedes proporcionarle tus propios requisitos del usuario de antemano y decir, está bien, usa esto como base. O puedes hacer que el editor, el AI IDE lo cree por ti. Luego revisas de ida y vuelta y te aseguras de que esté bien. Luego le dices al asistente que cree el documento de diseño. Luego revisas eso, y luego haces que cree los detalles de implementación. Estas son las listas de tareas, las tareas, una por una, para implementarlo realmente basado en los requisitos y el documento de diseño que creaste. Podrías hacer esto de manera manual si lo deseas. Haré una mención a SpecKit. Esta es la forma de código abierto de GitHub de hacer este proceso.

Puedes instalar una variedad de diferentes asistentes de codificación. Ahora, en Kiro, tienes esto. Esta es la versión IDE. Tenemos el modo plan dentro del CLI, si prefieres el CLI. Pero en el IDE, elegirías spec, y luego procederías a dar un prompt. En este caso, puedo decir, construye un servidor MCP de películas para llevar un registro de las películas que he visto o construye un sitio web de películas, lo que quieras. Ahora, probablemente estés pensando, ¿es el spec solo bueno para proyectos nuevos de tipo greenfield? Yo diría que absolutamente no. He visto aplicaciones existentes que tienen años, tienen docenas y docenas de estos diferentes archivos spec en ellas. En este ejemplo, es un poco más de un greenfield, pero definitivamente puedes usarlo para proyectos legacy existentes también.

Funciona muy bien. Solo diría que estos son realmente buenos para cuando estás haciendo características en profundidad, cuando tu proyecto necesita un poco más de planificación previa, y solo quieres construir las cosas de una manera estructurada. Definitivamente funciona muy bien con proyectos complejos. De hecho, añadimos un modo spec para correcciones de errores también. Puedes usarlo para cosas más pequeñas, aunque puede que prefieras simplemente hacer un código vibe para esas cosas en su lugar. Así es como se ve nuestro documento de requisitos. En la primera parte, crea esta fase de requisitos donde está en este formato de años, y te da la introducción, los requisitos, las historias de usuario. También tenemos un proceso donde te hace preguntas de antemano. Añadimos algunas preguntas y respuestas adicionales.

A medida que introduces tu prompt, te hará algunas preguntas aclaratorias antes de crear esta fase de requisitos. También puedes hacer este modo plan rápido que acabamos de añadir, que procederá a generar rápidamente todos estos documentos para ti basado en las preguntas y respuestas que des. Hay muchas maneras diferentes de hacer esto. Luego crearás un documento de diseño, que es un documento de diseño de nivel superior. También puedes comenzar con el documento de diseño primero. Algunas personas tienden a tomar este diseño y requisitos, combinarlos, pero típicamente con nuestro flujo de desarrollo impulsado por especificaciones, puedes comenzar con uno o el otro. Luego podrías tener diagramas de mermaid aquí, arte ASCII con toda la información. Ahora, este es el punto en el que recomendaría encarecidamente si estás intentando esto en casa que te detengas y lo actualices con tu conocimiento y experiencia y gusto exactamente a lo que estás buscando, porque solo es tan bueno como lo que pongas. Pero descubrirás que incluso con un prompt más pequeño y con las preguntas aclaratorias, hace un buen trabajo. Por supuesto, siempre querrás revisarlo para markdown. El archivo markdown es para inconsistencias, elucidaciones y errores. Finalmente, llegas a la fase de implementación.

Esto será una lista de tareas. También tiene algo llamado pruebas basadas en propiedades, que son pruebas que están en contra del documento de requisitos y el documento de diseño. Además, puedes tener esas creadas y ejecutadas. Lo recomendaría altamente, de esa manera te aseguras de que las tareas realmente se implementen correctamente. Normalmente también, un consejo rápido aquí, una vez que crea esta lista de tareas, le digo, por favor toma las cuatro tareas principales, ponlas en la parte superior y crea un MVP para mí primero. De esa manera, puedo verlo funcionando. Luego las implementaré. Implementaré primero la versión MVP.

Ahora, me encanta el model context protocol. No voy a entrar en todos los detalles de ello, pero es una forma, esencialmente, para que tus proveedores de modelos se conecten a diferentes fuentes de datos. Así que en este caso, estoy usando Kiro, y tal vez estoy usando algo como OpenAI o Anthropic, y queremos conectarnos a diferentes fuentes de datos. Tenemos este protocolo MCP en el medio, y conecta todo junto para nosotros, lo cual es increíble. Ahora, recibo esta pregunta, ¿no tiene MCP seis meses de antigüedad, y está muerto ahora? Ahora, mucha gente en internet tiene opiniones que cambian cada otro día. Algunas personas decían que, bueno, puedes hacer muchas cosas con MCP, solo con herramientas de línea de comandos. Realmente creo que MCP todavía está madurando. Hay un largo camino por delante para ello, especialmente con algunas de las cosas de seguridad que está haciendo. Yo mantendría un ojo en MCP.

Pero una de las principales razones por las que me gusta, especialmente para el flujo de desarrollo impulsado por especificaciones, es que puedes tener algo como Indira o Asana, todos tus tickets, todos tus documentos de requisitos grandes, y luego puedes tenerlo siendo extraído en tu flujo de desarrollo impulsado por especificaciones cuando crea tus especificaciones, lo que hace que sea mucho más fácil trabajar con ello. Así que si tienes un gerente de producto que realmente ha escrito un documento de requisitos, puedes extraer eso, y simplemente lo hace un poco más fácil. Estoy hablando de cualquier tipo de servicio de gestión de proyectos, y obtener detalles técnicos para ello. También puedes poner reglas adicionales en tus archivos steering o agents.md que le digan, así que si estás usando el flujo de desarrollo impulsado por especificaciones, asegúrate de obtener la información de este servidor MCP. Y de esa manera, sabe dónde buscar. O simplemente puedes especificarlo en el primer paso, como, oye, mira este servidor MCP cuando crees los requisitos. Así que déjame mostrarte una demostración rápida. Esta es la última versión de Qiro, la versión IDE. Y déjame darte una muestra rápida de ello. Ahora, solo por cuestión de tiempo, no tengo tiempo para entrar y crear un proyecto nuevo desde cero, pero uso este. Es una base de datos de películas, así que esto es más un proyecto nuevo de tipo greenfield, pero creo que aún así entenderás la idea. Estaba en el modo spec aquí, dije por favor créame un sitio web de películas. Así que lo que hizo fue comenzar con este documento de diseño, y en este caso, realmente le dije que comenzara con el diseño en lugar de los requisitos.

Ahí vamos. Y luego esto muestra la vista previa real del archivo markdown. Así que puedes ver que creó un montón de diferentes diagramas mermaid que muestran la arquitectura de esto, te da diagramas de secuencia. Y así fui de ida y vuelta con esto y lo actualicé y edité, y creó todo esto para mí. Si me desplazo hacia abajo hasta el final de este documento que creó, puedes ver aquí que creó un montón de pruebas de propiedades.

Y estas son pruebas realmente especiales. Utiliza FastCheck en este TypeScript en el mundo de Node para hacer estas pruebas, que en realidad se ejecutan docenas, si no cientos de veces con diferentes valores para asegurarse de que estos requisitos se satisfacen correctamente, lo cual es realmente agradable. Y luego creó este documento de requisitos en, una vez más, este formato ears. Así que es realmente muy simple con estos requisitos de historias de usuario. Déjame ver si puedo abrirlo de nuevo. Aquí está en vista previa. Así que aquí está el documento de requisitos. Requisitos uno, carga de datos de películas. Cuando la aplicación se inicializa, el motor de filtrado se cargará. Así que te da como una guía paso a paso de exactamente lo que está haciendo aquí.

Y luego, cuando fui de ida y vuelta con esto, llegué a la lista de tareas y le pregunté, oye, en la lista de tareas, ¿podemos crear como un MVP? Así que fue adelante y actualizó la lista de tareas e incluso dice aquí mismo, las tareas uno a cuatro entregan un MVP funcional. Cuadrícula de películas navegable con búsqueda, filtrado por género, ordenación, y el tema completo de synthwave de los 80. Así que realmente rehizo todos los requisitos y para obtener este básicamente MVP en funcionamiento y listo para salir, lo cual realmente disfruté.

Seguí adelante y simplemente los implementé todos después de eso, pero puedes ver cómo funciona. También puedes ver que creó estas pruebas basadas en propiedades, que son agradables, a las que puedo volver y echar un vistazo a la ejecución. Si paso el cursor sobre algunas de ellas, puedo ver los cambios. Así que puedo ver los cambios y exactamente lo que hizo. Definitivamente muy, muy útil en lo que está haciendo. También puedes déjame ver si me desplazo hasta el final aquí. Aquí está. Así que si simplemente paso el cursor, muestra como un poco de información sobre la prueba basada en propiedades, como con pruebas de propiedades, pruebas para el filtrado de géneros, para cualquier conjunto de datos de películas. Y si la lista de géneros extraídos debe contener exactamente un conjunto ordenado de géneros únicos. Así que me dice exactamente lo que hizo en este punto. Y luego incluso puedo mirar la ejecución de lo que hizo. Bien. Volvamos a la demostración. Solo nos queda un minuto. Así que si quieres aprender más, puedes ir a qro.dev o puedes unirte a nuestro Discord en discord.gg slash qro.dev. Recomiendo encarecidamente a todos los que están viendo, que lo revisen. Es bastante asombroso. También, aquí hay un código QR, toma una foto de esto, dame tu opinión sobre esta presentación. Déjame saber. Me encantaría saberlo. Y finalmente, tengo un código QR más. Si quieres ir a mi sitio web en Program With Eric, tengo estas diapositivas para que las descargues y las revises. Y asegúrate de conectarte conmigo en LinkedIn en Eric Hanchet. Me encantaría conectarme con tantas personas como pueda y también en Blue Sky en Ericch o X. Gracias.