Com adaptar Claude Code al Spec-Driven Development: el flux de quatre agents de BettaTech

La inteligencia artificial ya puede escribir código. Pero ahora la pregunta es, ¿cómo podemos hacer para que realmente escriba el código correcto? Cada dos por tres están saliendo nuevas versiones de modelos de inteligencia artificial y nos pensamos que simplemente porque el modelo es mejor, ya va a automáticamente desarrollar mejor código, cuando en realidad la experiencia nos ha confirmado que lo que más impacto tiene es el ecosistema sobre el que trabaja el modelo, lo que conocemos como arnés. En este vídeo te voy a enseñar cómo he construido un arnés que trabaja sobre el flujo de spec Driven Development, el flujo que promete revolucionar la forma con la que interactuamos con la inteligencia artificial para desarrollar. Pero antes de enseñaros el código como tal, este vídeo es una expansión sobre el vídeo de Harness Engineering, en el que explico este concepto con mucho más detalle y que puedes ver en el enlace que te dejo en la descripción y en el comentario fijado. Muchos comentarios en ese vídeo tenían la duda sobre qué diferencia existía. entre el spec D R Diven Developomen y el Harness Engineering. Y antes de empezar quiero aclarar estos dos conceptos porque como yo lo entiendo, el Harness Engineering sería la disciplina para automatizar el flujo de trabajo con inteligencia artificial. Flujos de trabajo hay un montón. Por ejemplo, el famoso flujo de trabajo en cascada, en el que diseñamos el software primero y luego lo implementamos al completo. El flujo de trabajo iterativo en el que vamos haciendo pequeñas iteraciones por el camino. Un flujo de trabajo con TDD, por ejemplo, el test driven development, en el que primero implementamos los tests y luego desarrollamos flujos de trabajo que no ha existido durante toda la historia del desarrollo de software. Para mí el Harness Engineering es agarrar estos flujos de trabajo y intentar aprovechar la inteligencia artificial para automatizarlos, para generar agentes que hagan cada una de estas etapas de una manera eficiente. ¿Qué es el spec driven

development? pues no deja de ser un flujo concreto de trabajo. Un flujo concreto de trabajo en el que primero nosotros especificamos lo que queremos hacer en lo que se conoce como spec para a continuación realizar la implementación en código. Es decir, podemos crear un arnés utilizando harness engineering para implementar el flujo de trabajo de SDD. De la misma forma que podríamos hacer un arnés para implementar TDD o podríamos hacer un arnés para seguir principios ágiles. Con esta diferencia clara sobre harness y SDD, también quiero hacer nada un minutito de explicación sobre qué es o qué implica utilizar Spect Driven Development. Si quieres profundizar mucho más, de nuevo, tengo otro vídeo en mi cuenta de YouTube en el que puedes ver exactamente qué tipos de SDD existen y cómo se diferencian entre ellos. El que te voy a explicar ahora es el que a mí me gusta utilizar. Y es que como digo, con sdizar la forma de creación de software poniendo la especificación en primer plano. Pero claro, ¿qué sería una especificación en este caso? Pues sería cualquier forma de explicación sobre qué es el software que queremos implementar. Seguro que has trabajado con especificaciones 1 veces. Puedes haber trabajado con historias de usuario o puedes haber trabajado directamente con requisitos que llegan del cliente, que acostumban, ya sabemos, eh, a ser vagos, a no tener los detalles y todo eso. Estas dos metodologías, estas dos formas de definir una especificación serían la parte de la spec. Lo que nos dice Spectriben Developen es que nosotros utilizando este spec podemos aprovecharnos de la inteligencia artificial para generar código utilizando esta especificación como fuente de verdad. si lo llevamos al máximo nivel, el código nunca lo tocaríamos como desarrolladores, siempre estaríamos trabajando sobre la

especificación y haríamos esta fase de transformación con IA mentalmente como si fuera, pues, yo que sé, un compilador o un transpilador de código. Aquí podemos entrar también en discusiones sobre si es lo mismo, que si el determinismo o el no determinismo de la Pero sería la idea general que nosotros buscamos con SDD. Viendo este flujo en el que nosotros tenemos la especificación, le delegamos a la IA la generación del código y por lo tanto también luego necesitamos alguna cosa para validar que el código que hemos construido es correcto. Especificamos la IA implementa el código. La IA también potencialmente valida que este código sea correcto mediante testing, por ejemplo. Y volvemos a empezar todo el flujo de trabajo. Lo que necesitaríamos sería un arnés que nos obligue a implementar este flujo de trabajo. Este arnés lo podríamos montar con subagentes. Al final, en este flujo de trabajo, tenemos diferentes partes del flujo de trabajo de desarrollo de software. Por lo tanto, podríamos tener un agente de inteligencia artificial especializado en cada uno de estos elementos. Para la fase de especificación de software podríamos tener un agente al que yo llamo el Spec Author. Este agente sería el encargado de realizar toda la especificación de código y trabajar en un formato que nosotros hayamos negociado con él para definir exactamente el código. Luego, para la parte de implementación podríamos tener también otro agente especializado en implementar código, que sería el que yo he llamado implementer. Este agente simplemente implementa código utilizando la spec que le da el spec autor. Finalmente, para la parte de validación podríamos tener otro agente de inteligencia artificial que yo he llamado reviewer. En este caso es un agente que se encarga de evaluar el

código que se ha generado, asegurarse que pasa los test, asegurarse de que el estilo de codificación es el que yo le he pedido y por lo tanto validar que lo que ha construido el implementador continúa y sigue la spec determinada. Obviamente, estos serían cada una de las partes que nosotros tenemos en nuestro sistema, ¿no? En nuestro flujo de trabajo que trabajan de forma independiente. Necesitamos a alguien, otro agente de inteligencia artificial, que se asegure de organizar cómo funciona este flujo. En muchos sitios, en mucha literatura, lo veréis como orquestador. En mi caso, yo lo he llamado líder. El agente líder es el encargado de lanzar la etapa de spec, la etapa de implementación o la etapa de validación en función del estado actual del trabajo. Es decir, actúa como orquestador, actúa como jefe, podríamos decir. Y todo esto lo intentamos formalizar para que también tengamos una memoria externa. Y aquí quiero hacer un apunte. Recomiendo antes de ver este vídeo pausarlo ahora mismo, irte al vídeo de Harness Engineering que te he dejado aquí abajo, porque estoy asumiendo que te lo has visto y estoy asumiendo que tienes estos conceptos de memoria, contexto más o menos claros. Así que por favor te recomiendo que pauses ahora mismo este vídeo, vayas a ver ese y luego vuelvas a este de aquí para acabar de entender exactamente por qué he construido esto que te voy a contar en la forma en la que lo he construido. Bien, como iba diciendo, lo que vamos a tener es una memoria externa a los diferentes agentes para que cada uno tenga un contexto independiente. Por un lado, tenemos una memoria que es la lista de tareas que puede ser un JSON, puede ser una base de datos o puede ser una herramienta de ticketing. En mi caso, para hacerlo fácil, para el ejemplo, es un fichero punjon. Esta sería una memoria a la que accede el líder, es decir, es una memoria a alto nivel, una memoria del estado del proyecto. El líder agarra esta memoria y

determina si hay tareas pendientes o no. Si hay una tarea pendiente, por ejemplo, puede empezar a lanzar al agente de especificaciones, al Spec Autor. Este Spec Autor también lo que va a hacer es guardar partes de su contexto en unos ficheros externos, en unos ficheros que se van a guardar debajo de la carpeta spec con el nombre de la tarea que está realizando. De esta forma, si cancelamos la sesión, si la volvemos a empezar, siempre podremos volver a la parte del spec para leer exactamente qué es lo que había construido el otro agente y no tener que empezar de cero. ¿De acuerdo? esta filosofía de intentar sacar a ficheros externos todo el contexto interno de cada gente para que no se degrade el contexto con el tiempo. De la misma forma se va a utilizar este fichero para pasarle a el implementador solamente el contexto necesario. Es decir, no le pasamos el chat, los proms, el historial de la conversación que yo he tenido con el agente de spec, sino que cuando yo tengo el spec perfectamente implementado o lo tengo aprobado por mí como humano, le digo al implementador, "Ey, ya tienes este spec listo para ser implementado." Entonces el implementador tiene el contexto mínimo necesario para poder hacer su trabajo. De misma forma, una vez se ha terminado de implementar todo esto, se lanzará el reviewware para validar también contra este spec, pues que los test tienen sentido, que el estilo de código es el que quiero y que todo está construido de la forma correcta. Esto sería a alto nivel lo que yo he estado intentando montar y el resultado ha sido este código de aquí. Básicamente tengo los diferentes agentes guardados aquí en la carpeta agents y como puedes ver pues tengo al implementador que se encarga de ejecutar una sola feature de la lista,

¿de acuerdo? siguiendo los specs que yo tengo en la carpeta de specs. Tengo una serie de precondiciones que se tienen que comprobar antes de empezar a trabajar y finalmente tengo un protocolo que tiene que seguir para acabar de hacer su trabajo. No tengo un proceso que todos los agentes tienen que seguir. De nuevo, esto está mucho mejor explicado en mi vídeo de Harness Engineering. Luego, aparte del implementador, pues tengo el reviewer, que su única función es aprobar o rechazar cambios. Básicamente leyendo pues un documento donde tengo definida la arquitectura y las convenciones de mi proyecto y luego tengo un spec Author. Me he inspirado mucho en Kiro, que es una herramienta de Amazon, ¿no?, que sigue este flujo de Spectriven development para montar exactamente el cómo quiero trabajar. Principalmente el Specor va a crearme dentro de la carpeta specs tres ficheros, un fichero de requerimientos, un fichero de diseño y un fichero de tareas. El fichero de requerimientos va a incluir, pues, por ejemplo, las historias de usuario. En este caso no estoy utilizando historias de usuario, estoy utilizando otro formato que es un poquito más conciso, pero puedes utilizar el formato de definición que tú necesites. Luego tendríamos un fichero que sería la parte de diseño, que ya es un fichero con explicación técnica exactamente, pues qué ficheros se tienen que cambiar, qué clases se han de crear, qué funciones se han de implementar. Y finalmente el fichero de tareas, que sería el fichero que agarraría el implementador para ya empezar a ejecutar. Fíjate que lo que estoy haciendo es filtrar el contexto, curarlo, acabar de definir exactamente qué es lo que se tiene que hacer para que el implementador tenga un contexto muy pequeño, sepa exactamente que tiene que ir a tal fichero, a cambiar la línea 40 y a generar una función que se llama validation, por ejemplo. Todo esto está orquestado con el que yo he llamado el agente líder, que sería el orquestador,

que fíjate que es el que tiene determinado el flujo de spec driven development. En este caso, le estoy diciendo que este repositorio va a utilizar SDD, que vea la documentación de specs que tengo definido aquí a la derecha y que tiene que pasar por las fases de Spectri de Develomen con aprobación humana. ¿De acuerdo? Yo no soy muy fan de eliminar el humano del ciclo de trabajo. Siempre me gusta entender qué es lo que la está construyendo y siempre quiero tener claro y visibilidad de qué es lo que está haciendo porque si no a la larga sabemos que perdemos el contexto de nuestro software y puede ser muy peligroso. Por lo tanto, el flujo que yo estoy utilizando es una tarea que está en pending, se la delegamos a spec, pasamos la tarea, el estado de la tarea a spec ready. nos quedamos pausados como agentes hasta que el humano nos apruebe que la especificación es correcta. Una vez es correcta, la pasamos a en progreso, el implementador y el reviever empiezan a trabajar y finalmente terminamos. Fíjate que tengo una serie de normas que intentan, ¿no?, que el agente siempre vaya por el camino del Spectrient development. Y tengo aquí las explicaciones de en cada estatus, en cada situación, qué es lo que tiene que hacer. Por ejemplo, si el estatus es pending de la tarea, pues tengo que lanzar un agente de spec Autor, redactar estos tres ficheros y parar sin lanzar al implementer cuando termina las specs. Entonces, fíjate que aquí tengo todo esto. No te preocupes porque este repositorio también te lo dejo abajo en la descripción para que te lo puedas descargar, probarlo, jugar con él e investigar lo que necesites. Antes de hacerte la demo exacta de cómo funciona esto, déjame explicarte un poquito qué es lo que tengo en la documentación de SPECs. Y es que aquí es donde defino el formato con el que quiero trabajar. En este fichero tengo pues los tres documentos que quiero implementar. Y

fíjate que en la parte de requerimientos tengo, por ejemplo, en este caso a utilizar notación EARS. La anotación EARS es una anotación muy sencillita para definir requerimientos. Podría haber puesto que quiero que utilice historias de usuario con criterios de aceptación. podría haberle dicho que quiero que utilice lenguaje natural, lo que necesitéis. En este caso, utilizo EARS porque pues es bastante sencillito, ¿no? Un ejemplo de EARS podría ser cuando el usuario ejecuta X comando, el sistema debe imprimir hasta cinco notas por orden descendente, por ejemplo. Sería un ejemplo de requerimiento de notacións. Entonces, cada spec va a seguir el formato o debería seguir el formato, mejor dicho, que está definido en specs.m. Con todo esto, en este proyecto de ejemplo, que es nada un proyectito en Python, que es un gestor de de notas internas, pues ya podríamos empezar a trabajar utilizando este sistema de harness engineering para SDD. Y date cuenta de una cosa, aunque estemos hablando de conceptos que parecen superclejos, que si agentes de inteligencia artificial, que si me lanzo un reviewer, que si me lanzo un implementer, no dejan de ser ficheros MD, ¿vale? no dejan de ser ficheritos que yo tengo aquí con exactamente qué es lo que quiero hacer y luego pues el fichero de cloud.md que lo que hace es oye, empieza como líder, ¿vale? Sigue como el punto de entrada. De nuevo, este vídeo es una segunda parte de mi vídeo de hardness engineering, por lo que ya estoy asumiendo que ciertos conocimientos los tienes, pero quiero recalcar, eh, aunque parezca complejo, es muy sencillo. Puedes implementarte tú utilizando la base de este repositorio, el arnés que necesites de una forma superfácil. Incluso pide la Claude que te modifique los propios agentes y el propio líder para montarte el flujo de trabajo que a ti te funcione. Dicho esto, ¿cómo se trabajaría, no?, con este proyecto, cómo se ve trabajar con SDD utilizando este arnés. Para lanzar esto, me puedo ir a

mi proyecto y yo, por ejemplo, utilizo cloud. Si utilizas otras CLI como Open Code, por ejemplo, bastaría con investigar cómo se llaman las carpetas en las que tienes que colocar eh los agentes, etcétera, en cada uno de tus CLIs, ¿de acuerdo? y sería mover esto. El CLI no es lo importante, lo que importa es un poquito la organización del flujo de trabajo. Yo me podría ir a mi proyecto, le doy a cloud y como tengo el cloud.md que está apuntándome al líder, ya va a empezar con el líder, es decir, ya ha empezado un poquito con ese rol. Entonces yo le puedo decir implementa la siguiente tarea pendiente. Fíjate que lo primero que hace es leer el fichero de leader.md porque es lo que yo le he dicho en el cloud y como tengo el flujo obligatorio en que siempre ejecute los tests y compruebe que tiene los ficheros necesarios, ya lo está haciendo aquí. Es decir, tengo un fichero init.sh SH que siempre Cloue va a estar obligado o el líder, mejor dicho, a ejecutarlo. En este caso ve que el entorno está todo correcto y que tengo una feature pendiente que es la siete. Y fíjate que yo la había marcado con sdrue. Si yo me voy a mi fichero y me voy a mis tareas que tengo por aquí, fíjate que yo les tengo puestas un buleano cuando quiero que utilicenD y cuando no, ¿vale? porque hay tareas que son muy cortas, muy sencillas, que utilizar ese DD sería bastante molesto, bastante overkill. Entonces, fíjate que en esta tarea está lanzando un Spec Author, un agente Spec Author. Aquí lo lanza y empieza a generar los primeros specs. ¿De acuerdo? Date cuenta, eh, aquí me está generando la primera feature que se llama CLI Resent, en este caso, que es el nombre de la feature. Le damos a yes para

permitir que escriba los ficheros eh necesarios y en este caso, date cuenta que ya me está escribiendo todos los requerimientos. Entonces, bueno, aquí podía ser un poquito molesto de eh de leer, pero date cuenta, featur ta ta ta. Cada requirement está redactado en formato EARS como tal como le hemos indicado. Y aquí tenemos los requisitos. Cuando el usuario ejecuta este comando, sin pasar guion guion-ion limit, que es un parámetro de de este ejemplo, el sistema debe imprimir como máximo cinco notas. Cuando el usuario ejecuta pa con un entero n mayor a 0, el sistema debe imprimir como máximo n. Date cuenta que el formato EARS es muy útil porque cada uno de estos requisitos se podrá traducir luego directamente a un test, ¿vale? A diferencia de una historia de usuario, que a veces una historia no puede requerir mucho código, muchos test, aquí en este formato, cada R, cada requisito va a ser traducido a un test. Entonces le dejamos que escriba los requerimientos. Por lo tanto, ahora aquí ya tenemos un requirements.md y ahora deberíamos tener ya el fichero de diseño, que sería la siguiente fase de SDD. En este caso, fíjate que ya son detalles de implementación. Vale, es un fichero design.md md donde tenemos, mira, vamos a tocar estos archivos con estos cambios, por ejemplo, añadir el comando que nos hace falta, registrar un nuevo parseador, añadir cuatro test nuevos, por ejemplo, qué ficheros no se han de tocar, cómo tiene que ser el nuevo comando. Entonces, aquí ya está el agente tomando decisiones de diseño, agarrando los requisitos que nosotros hemos creado para acabar de definir exactamente qué es lo que se tiene que hacer. En este flujo es en el que yo tendría que ir revisando, ¿no?, como humano los requerimientos que está implementando y en caso de que yo considere que no

están correctos, decirle que no y decirle e esta parte cámbiala, ten en cuenta esto, etcétera, ¿no? Yo iría trabajando sobre estos ficheros. En este caso, le dejamos que vaya para adelante. Y ahora acabaríamos con un fichero que sería la lista de tareas, el tasks.md. Bien, fíjate, son estas de aquí. las que están iniciadas con T4, T5 y T6. Yo porque le he definido que en mi flujo me genere este fichero de tareas, yo le podría haber dicho que utilizara, yo que sé, el MCP de Linear, que es una herramienta de gestión de tickets y de tareas, ¿vale? Para que en vez de guardarlo en mi fichero MD lo guardara directamente en linear. Es decir, date cuenta que si yo modifico aquí mis agentes, yo puedo decirle que haga lo que quiera. Puedo decirle, "Ves a Linear y créame un proyecto por cada spec" en vez de yo tenerlo guardado aquí. De forma que también podría tener compartido con mi equipo pues las diferentes especificaciones, las diferentes tareas y los diferentes cambios que hacen mis agentes. Yo lo estoy haciendo en local para que se vea, pero con MCPS y con skills yo esto lo puedo expandir como necesite, ¿de acuerdo? Por lo tanto, puedes descargarte el repo y hacer tus propios experimentos. En este caso, yo podría decirle que las tareas ya las escribirá directamente en linear para tenerlas ahí guardadas. Entonces, fíjate el potencial que tiene todo esto, ¿no? En este caso, le podemos decir que sí, que me parecen bien estas tareas. Y recordemos que yo tenía puesto lo de el human in the loop. En este caso, fíjate que me está preguntando, "¿Quieres pasarlo de pending a spec ready?" Le decimos que sí. Date cuenta que no se ha puesto. Implementar todavía, ¿de acuerdo? Solamente tenemos la spec. ¿Por qué? Porque yo le había dicho en el líder que el flujo de SDD requiere el humano para

probar. Por lo tanto, es mi responsabilidad como humano ahora irme a mi lista de tareas, buscar la tarea que tengo como expect, que en este caso es esta, revisar que todo tiene sentido. Fij, fijaros que tengo aquí las los tres ficheros para ir revisando qué es lo que se tiene que hacer. Pues yo puedo meterme aquí, mirar las tareas que se tienen que hacer, tomarme el tiempo que yo necesite para entender qué es lo que está pasando y pedirle a Cloue que me cambie las cosas para luego tener que irme aquí y decirle, "Mira, ya no es solamente spec ready, quiero que lo pases a in progress." Esto podría ser yo ahora que cambiándolo o yo en linear o en Gira pasándolo de un estado a otro. Vale, podría ser cualquier cosa de estas. Yo lo marco como in progress y aquí ya le digo a Claude, "Oye, ya he aprobado." En este caso era la feature si vemos que vuelve a leer la lista eh de características, la lista de tareas. Y como ya está en progress, va a lanzar el implementador con el spec aprobado. Y ahora esto va a lanzar otro agente de IA con el implementer. Le va a pasar las tareas necesarias porque tiene ya los MDS en el spec. Fíjate aquí que estaba leyendo, ¿no? Si hacemos el control o para expandir, está leyendo las specs necesarias y ahora ya se ha puesto a trabajar para implementar. Yo me puedo ir aquí a la parte de progreso y vemos que me ha escrito este fichero que es la tarea actual en la que está trabajando el implementador y veo que es que está ejecutando las tareas definidas en tasks MD. añadir este comando, registrar este parser, añadir estos cuatro test y finalmente verificar con init.sh, que es un fichero que se encarga de verificar entorno y ejecutar todos los test que hagan falta, ¿vale? Entonces,

fíjate que ya tendría todo el flujo de trabajo con SDD definido. Fíjate que aquí ya está implementando. Eh, yo aquí ya podría ir haciendo la revisiones y trabajar normal con Cloud Code, pero me está obligando a seguir un flujo de trabajo que a la larga me puede ayudar porque me guarda los specs, me da todo el contexto y utiliza agentes especializados que yo puedo personalizar para cada fase de mi desarrollo. Una vez termine cada una de las tareas, fíjate que las va marcando como completadas, que yo luego, como digo, quiero guardarlo en tickets, cambio eh mis prompts, ¿no? Cambio mis agentes para que lo utilicen. Que yo quiero utilizar un MCP de memoria para que no me guarde ahí las tareas o me vaya guardando decisiones en otro sitio, lo puedo implementar. Le digo, "Utiliza esta herramienta, esta tool para guardarme las cosas en una memoria, que yo quiero que por cada tarea que va guardando me haga un comit." Nada, pues yo me voy aquí al implementer y le digo, "Oye, el protocolo es que en cada tarea que vayas haciendo hagas un comit para registrar el cambio." O le digo al líder, "Cada vez que empieces una nueva spec, générame una branch." Yo esto lo puedo personalizar como mi flujo me permita, como yo quiera hacerlo. Ese es el potencial del harness engineering. Hay un montón de sitios en internet que te van a compartir herramientas opinionadas. con opinionadas, me refiero a que te comparten su propio flujo de trabajo. Para mí, lo realmente importante es que aprendas a construirte el tuyo propio. Entiende cómo quieres trabajar, entiende a montarte tu propio arnés y estarás desbloqueando una habilidad que cada vez será más buscada. Como ves, esto sigue implementando todas sus tareas y finalmente aquí está implementando ya todos los tests. Obviamente yo como desarrollador me gusta leerme los tests que implementa, ver qué tienen sentido y ayudar a la

gente a implementar los tests correctamente. Al final, esto es tu capa de validación. Esto es lo que se asegura de que tu agente está construyendo el código correcto, por lo que es importante que tú como humano lo revises. De nuevo, no soy muy fan de dejar a la gente de ella trabajando 24 horas. y solamente mirar el resultado final, ¿vale? No cuesta tanto revisar los test. Entonces, le damos a yes y al final, cuando termine de implementar todo, aunque todavía quedan algunas tareas, lo que debería hacer es lanzar el reviewer. Una vez terminado, fíjate, ahora ya está lanzando el reviewer para validar la trazabilidad y las tareas. Lee el fichero de la gente de reviewer para saber exactamente qué es lo que tiene que hacer. lee las convenciones y toda la documentación que yo quiero que tenga en el contexto, lo que tenía que construir porque está leyendo las specs. Y fíjate que también está leyendo los test, por lo tanto se está encargando de verificar que los test tienen sentido y además los está ejecutando para asegurarse de que realmente funciona. E insisto, eh, que sé que me pongo muy pesado con esto. Una vez hemos llegado a este punto, yo ya he revisado la implementación en dos fases, en la fase de diseño y en la fase de implementación de los test, ¿vale? Insisto, eso es importante para poder mantener la calidad del software. Por mucho que utilicemos IA, no tenemos que perder nuestro propio criterio como desarrolladores, nuestra experiencia y nuestros conocimientos. Una vez el reviewer ha terminado, marcamos la tarea como e como don, en este caso en la lista de tareas. Movemos la memoria al fichero de history.md, donde voy guardando el historial de todo lo que ocurre. Y finalmente ya vemos un resumen de todo lo que ha hecho mi agente de inteligencia artificial aquí en Cloud Code. Pero si yo me voy a mi fichero history.md y me voy al final, voy a ver que tengo exactamente todos los cambios de los agentes que han ido trabajando, todo lo

que se ha ido haciendo y los cambios que se han ido implementando. De nuevo, esto sería un arnés de SDD básico, sencillo, con un flujo muy claro y sin herramientas externas. Como digo, yo esto lo puedo vitaminar, modificar, personalizar como yo necesite. ¿Dónde guardar el historial? Si quiero no guardar cosas intermedias, si quiero que se guarden decisiones en la nube, si quiero que guarde los tickets en una herramienta de tickets, si quiero que haga o no comics, cuándo quiero que haga pull request, todo lo puedo definir aquí. Esto lo que me permite es aprovecharme de la vitaminación y las mejoras que me da el desarrollo con IA, pero sin perder mi cabeza y poder seguir revisando el código y tomando decisiones de arquitectura por mí mismo. De nuevo, lo digo, utilizar la IA está genial. nos podemos aprovechar muchísimo de estas herramientas para mejorar nuestro flujo de trabajo. Ahora bien, nunca tenemos que perder nuestra experiencia, nuestros conocimientos y nunca tenemos que dejar de mejorar y de aprender. Y siguiendo en esta línea, si quieres aprender más sobre diseño y arquitectura de software, voy a estar dando un curso en directo totalmente gratuito sobre aplicaciones Serverless en la nube, concretamente con Amazon Web Services. Vamos a ver cómo implementar lambdas, cómo exponerlas al público con APIGateway, cómo utilizar colas de SQS, cómo utilizar notificaciones con SNS y, en definitiva, cómo montar aplicaciones sin servidor en la nube más utilizada del mercado, Amazon Web Services. Te dejo el enlace aquí abajo en la descripción y en el comentario fijado para que te puedas apuntar. Y si este vídeo te ha gustado y te ha parecido interesante, por favor, suscríbete y déjame un buen like. Aunque creo que ahora también está esto del hype, que no sé si hace algo o no, pero bueno, tú por si acaso también machaca el botón de hype. Sin mucho más, muchísimas gracias por ver este vídeo y nos vemos en el siguiente con más informática. Hasta otra. M.