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

Hola a todos. Mi nombre es Eric Handshed, 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 codifiques más rápido, sino que realmente queremos que crees código de mayor calidad a partir de ello. Y creo que realmente 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, se crean especificaciones estructuradas 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 grandes modelos de lenguaje 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é? ¿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 grandes modelos de lenguaje 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 del camino. Y realmente el desarrollo dirigido por especificaciones ayuda a guiarlos en la dirección correcta.

Recuerdo cuando era pasante y en uno de mis primeros trabajos, teníamos un vicepresidente que caminaba y simplemente se le ocurrían ideas aleatorias de la parte superior de su cabeza. 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 vicepresidente dijo algo. Y luego aprendí que tienes que tomar la información que te da, escribirla ponerla en tu agenda, hablar con mi gerente al respecto. Así que estaba un poco demasiado ansioso. Y esto es lo que los pasantes de IA son básicamente estos grandes modelos de lenguaje hacen hoy en día y tenemos que tener cuidado con ello. Realmente no les di mucha introducción. Así que se las doy 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 buscar 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 dirigido por especificaciones 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 darle al modelo de lenguaje grande, a estos modelos, más contexto es realmente importante porque realmente ayuda a guiarlo en la dirección correcta. Y con nuestro software siempre cambiando y con los requisitos siempre cambiando, y con nuevos paradigmas, cambios, siempre necesitas guiarlo hacia donde necesita ir. Algunos modelos de lenguaje grandes, algunos arneses están comenzando a pensar más sobre 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 algunas cosas en mente antes de avanzar demasiado. Hay bastante información por ahí.

Tengo algunas opiniones. Estas son mis opiniones. Házmelo saber. Conéctate conmigo en LinkedIn si estás de acuerdo o en desacuerdo. Pero creo que necesitas tener esto en mente antes de usar el desarrollo dirigido por especificaciones o VibeCoding o cualquier cosa intermedia. Tenemos que, tienes que tener cuidado con el contexto. Ahora te dije antes que el desarrollo dirigido por especificaciones te da mucho contexto que se alimenta en 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. Yo tendría mucho cuidado de no poner demasiada información o muy poca información en eso. Algo así como esa zona de Ricitos de Oro de información es lo que necesitas. Así que solo necesitas darle suficientes reglas y pautas para que sepa qué hacer.

Así que eso es exactamente de lo que estaba hablando, agents.md o dirección. Lo llamamos documentos de dirección en Kera, de lo cual hablaré 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 dirigido por especificaciones 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á 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 dirigido por especificaciones. Puedes realmente añadir habilidades cuando crea tus documentos de diseño o cualquier otra cosa. Puedes usarlas en paralelo o con el desarrollo dirigido por especificaciones o cuando realmente implementas las tareas.

Y solo ten cuidado de no dar demasiada confianza. Recuerda, todo en el flujo de desarrollo dirigido por especificaciones eres tú, lo que significa que tú eres el humano en el bucle, por así decirlo. Necesitas ser el revisor de código de todo el código que se genera a través de este proceso. 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. Eso no quiere decir que no usemos herramientas para ayudar a hacer revisiones de código. Alguien una vez me dijo, ¿estás diciendo que eres el humano en el bucle, haces 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 de IA normales y herramientas de revisión para ayudarte a revisar cualquier solicitud de extracción que crees. O CRs.

Así que, permíteme 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 haciendo vibe coding, estaban usando estos asistentes de codificación, pero no estaban obteniendo los resultados que querían. Y lo que vimos es que 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 todo esto 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 la gente está comenzando a usar más las CLIs que los IDEs. Así que, si te gusta hacer eso, puedes usar el CLI. Pero en lo que realmente nos enfocamos con Kiro es, como puedes ver en estas capturas de pantalla, es este modo vibe y spec. Así que, vamos a entrar en el modo spec en un momento.

Pero realmente pensamos que esto realmente abarcaba lo que estábamos escuchando de nuestros clientes, que 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 verlo. Puedes descargar nuestro CLI, nuestro IDE, y probarlo, porque estamos realmente orgullosos de ello. Es divertido. Cuando lanzamos esto, en realidad se volvió un poco viral. Obtuvimos decenas de miles de descargas. Mucha gente nos estaba preguntando sobre Kiro.

Así que, estábamos realmente contentos de lanzar esto. Y 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 proceso de desarrollo dirigido por especificaciones sin Kiro, y hay algunas maneras. Una es que básicamente, tienes que simplemente... Podrías hacer esto manualmente con cualquier cosa. Podrías decirle a tu asistente, tu modelo de lenguaje grande, que incluya lo siguiente.

Primero están los requisitos del usuario. Les dirías, por favor, basado en XYZ, 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 miras de ida y vuelta y te aseguras de que esté bien. Luego le dices al asistente que cree el documento de diseño, luego miras 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.

Así que podrías hacer esto de una manera manual si lo deseas. Quiero dar un reconocimiento a Speckit. Esta es la forma de código abierto de GitHub de hacer este proceso. Puedes instalarlo en una variedad de diferentes asistentes de codificación. Ahora, en Qro, tienes esta versión IDE. Tenemos el modo plan dentro del CLI, si prefieres el CLI. Pero en el IDE, elegirías spec, y luego seguirías adelante y le darías 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 esta especificación solo buena para proyectos nuevos de campo verde? Yo diría que absolutamente no. He visto aplicaciones existentes que tienen años, tienen docenas y docenas de estos diferentes archivos de especificaciones en ellas. Este ejemplo, es un poco más de campo verde, pero definitivamente puedes usarlo para proyectos heredados 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 de especificación para correcciones de errores, también. Puedes usarlo para cosas más pequeñas, aunque puede que prefieras simplemente codificar esas cosas en modo vibe.

Aquí está cómo se ve nuestro documento de requisitos. En la primera parte, crea esta fase de requisitos, donde está en este formato de oídos, y te da la introducción, como 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 de plan rápido que acabamos de añadir, que generará rápidamente todos estos documentos para ti basándose en las preguntas y respuestas que proporciones. Hay muchas maneras diferentes de hacer esto.

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 toman este diseño y requisitos, los combinan, pero típicamente, con nuestro flujo de desarrollo dirigido por especificaciones, puedes comenzar con uno u otro. Luego podrías tener diagramas de mermaid aquí, arte ASCII con toda la información. En este punto, recomendaría encarecidamente, si estás probando esto en casa, detenerte y actualizarlo con tu conocimiento, experiencia y gusto para que sea exactamente lo que buscas. Solo es tan bueno como lo que introduces, 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. Los archivos markdown 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. Si además puedes hacer que se creen y se ejecuten, lo recomendaría encarecidamente. De esa manera, se asegura 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 protocolo de contexto de modelo. 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. En este caso, estoy usando Kiro, y tal vez estoy usando OpenAI o Anthropic. Queremos conectarnos a diferentes fuentes de datos. Tenemos este protocolo MCP en el medio. Conecta todo para nosotros, lo cual es increíble.

Ahora, recibo esta pregunta, ¿no tiene MCP seis meses y ya está muerto? Ahora, mucha gente en internet tiene opiniones que cambian cada 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 él, especialmente con algunas de las cosas de seguridad que está haciendo.

Yo mantendría un ojo en MCP. Una de las principales razones por las que me gusta, especialmente para el flujo de desarrollo dirigido por especificaciones, es que puedes tener algo como Endura o Asana, todos tus tickets, todos tus grandes stocks de requisitos, y luego puedes tenerlo siendo integrado en tu flujo de desarrollo dirigido por especificaciones cuando crea tus especificaciones, lo que hace que sea mucho más fácil trabajar con ello. Si tienes un gerente de producto que realmente ha escrito un documento de requisitos, puedes integrarlo eso. Simplemente lo hace un poco más fácil. Estoy hablando de cualquier tipo de servicio de gestión de proyectos, y tomar detalles técnicos para ello. También puedes poner reglas adicionales en tus archivos steering o agents.md que le digan eso, así que si estás usando el flujo de desarrollo dirigido por especificaciones, asegúrate de tomar 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. 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 rápida demostración de ello. Ahora, solo por cuestión de tiempo, no tengo tiempo para entrar y crear un proyecto completamente nuevo desde cero, pero usé este. Es una base de datos de películas, así que esto es más un proyecto de campo verde, completamente nuevo, pero creo que aún así entenderás la idea.

Estaba en el modo de especificación 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 diseño en lugar de requisitos. Ahí vamos, y luego esto muestra la vista previa real del archivo markdown, para que puedas ver que creó un montón de diferentes diagramas de mermaid que muestran la arquitectura de esto, te da diagramas de secuencia, y así fui de un lado a otro con esto y lo actualicé y edité, y creó todo esto para mí.

Si me desplazo 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 realmente 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. Luego creó este documento de requisitos en, una vez más, este formato de oídos, por lo que es realmente muy simple con estas historias de usuario, requisitos. Déjame ver si puedo abrirlo de nuevo. Aquí está en vista previa. 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, paso a paso, exactamente lo que está haciendo aquí.

Y luego, cuando fui de un lado a otro 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, clasificación y un tema completo de synthwave de los 80. Así que realmente rehizo todos los requisitos para obtener este MVP básicamente en funcionamiento fuera de la puerta, lo cual realmente disfruté. Fui adelante y simplemente implementé todos ellos después de eso, pero puedes ver cómo funciona. También puedes ver que creó estas pruebas basadas en propiedades, que son agradables, que puedo volver a entrar y echar un vistazo a la ejecución. Si me coloco sobre algunos de ellos, como puedo mirar los cambios, así que puedo mirar 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 me coloco, muestra como un poco de información sobre la prueba basada en propiedades. Es como, con pruebas de propiedades para el filtrado de géneros para cualquier conjunto de datos de películas y 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 puedo incluso mirar la ejecución de lo que hizo.

Bien, volvamos a la demostración, solo me 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 instantánea 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 descargues y eches un vistazo. Y asegúrate de conectarte conmigo en LinkedIn en erichandschat. Me encantaría conectarme con tantas personas como pueda. Y también en BlueSky en erichch o x.