En el anterior vídeo vimos las guías y los sensores propios del harness en genérico, y ahora, en este vídeo, vamos a centrarnos sobre todo en las guías, que al final lo que vienen a ser son técnicas, instrucciones, habilidades que permiten a las inteligencias artificiales seguir un camino orientado en la construcción de nuevo software. Pero antes hay que subrayar que en el mundo del software y la inteligencia artificial en general cada semana o cada pocos días están saliendo modelos nuevos, técnicas nuevas, proveedores nuevos, etcétera. Es un mundo en constante cambio. Por eso no podemos caer en el error, si estamos desarrollando nuestra aplicación, de atarnos a un determinado proveedor, por ejemplo Claude, porque pensamos que es lo que mejor nos ofrece calidad, y empezamos a acoplar todas nuestras guías y sensores a ese proveedor. Eso sería un error garrafal, porque al final, en este mundo tan cambiante, de repente salen proveedores más baratos y tecnologías nuevas en diferentes proveedores. Nuestro objetivo es diversificar, y si uno de repente sube mucho el precio, poder irnos a otros con mucha facilidad. Por eso este vídeo no se centra solo en explicar qué son las guías, sino también en cómo podemos desarrollarlas de tal manera que seamos independientes desde el principio. Así que nada, empecemos. Vale, pues empezamos con AGENTS.md. Esta guía lo que hace es que cada vez que nosotros abrimos una conversación con Codex, Claude, Antigravity o Mistral, lo primero que hace la IA es leer este archivo, y es la primera guía que va a utilizar para construir lo que le pidamos. Normalmente, si nosotros tenemos un monorepo, seguimos un poco la filosofía de Google y tenemos backend, front, contratos, proyectos de data scientists, infraestructura, todo dentro de un mismo repo. Normalmente este archivo AGENTS.md, que van a empezar a leer las IA como primera toma de contacto de manera automática, no va a tener todo de todos los subproyectos, sino que va a tener una visión global. Entonces lo primero que tenemos que hacer es declarar otros AGENTS.md en cada área. Este es del front, este es del backend de Python y este es del backend de lógica de negocio. Entonces nosotros tenemos acotadas las directrices que le damos a la IA según el área sobre la que estamos trabajando, y de esta manera queda mucho más limpio, organizado, y las ideas se organizan un poco mejor en su entendimiento de la aplicación. También es importante señalar que Codex, Antigravity y Mistral por defecto leen AGENTS.md, y Claude Code se sumó hace poco al estándar de la industria y también lo lee automáticamente, pero hay que tener una versión reciente de Claude Code, también hay que decirlo. Entonces, otro aspecto importante es la documentación. Nosotros tenemos que hacer en nuestro proyecto, por regla general, documentación. Vale, esto es documentación de Eurmes, y no tenemos que hacerlo solo para la IA: tenemos que hacerlo lo más comprensible, fácil e intuitivo posible para las personas. Tenemos que explicar muy bien de qué va todo, de qué va nuestra seguridad, de qué va nuestra visión, nuestra lógica de negocio, nuestra infraestructura, para facilitar la incorporación de nuevos compañeros al equipo, o incluso, por cierto, para nosotros mismos. Si nosotros desarrollamos un día una cosa, es probable que dentro de tres días nos olvidemos de todo lo que hemos desarrollado porque estamos con otras cosas. Entonces, incluso para nosotros mismos o para compañeros de equipo, es importante tener una muy buena documentación, y también porque la IA la va a leer, y nosotros aquí lo que le indicamos es que, dependiendo del área funcional que vaya a tocar, lea una documentación u otra. También podemos poner reglas absolutas que afectan a todo, tanto back como front como infra, y aquí tenemos, por ejemplo, reglas de TypeScript, porque tanto front como back están en TypeScript, y también tenemos reglas asociadas a un MCP. Un MCP es un servicio que se le ofrece a la IA, es decir, un conjunto de herramientas que puede utilizar, y estas herramientas suelen estar muy acotadas en lo que hacen y lo que reciben. Entonces, al final, tenemos un MCP interesante de comentar, que es codebase-memory, que es de terceros. Vale, y aquí lo que hacemos es que optimizamos la búsqueda de conocimiento en nuestro proyecto. Es decir, si ahora le digo: «Oye, cambia la práctica, quiero otra lógica diferente: que cuando el usuario le dé a me gusta le demos las gracias». Vale, antes lo que empezaba a hacer es: «Hostia, pues voy a buscar a ver si está en infraestructura lo de los me gusta; voy a ver si está en front, a ver por aquí, voy mirando», ¿no? Vale, es un poco más inteligente la búsqueda, lógicamente, pero bueno, para que os hagáis una idea, va buscando por todos lados. Y lo que hace codebase-memory es indexar todo nuestro proyecto en un árbol de búsqueda, y en vez de ir buscando por todo el proyecto cosas que necesita cambiar, va directo al grano. La búsqueda está más acotada y ya ella directamente dice: «Vale, esto está en la parte de práctica de lecciones». Entonces eso es lo que consigue con este MCP: que el proyecto esté en forma de árbol mucho más reducido que este árbol gigante que tenemos aquí de carpetas y archivos, y facilita la búsqueda. Al facilitar la búsqueda también estamos haciendo que la tarea sea más limpia: no contaminamos el pensamiento de la IA con «busco en front, luego busco en infra, luego busco en backend y por fin lo encuentro, y luego tengo que ir a buscar otra cosa». Todo eso contamina el proceso de creación de nuevo software o de mantenimiento. Entonces queremos que la búsqueda sea limpia, y eso lo convierte en una guía, porque al ser más limpio, guía mejor la construcción. También tenemos otro MCP, que es Context7, que lo que hace es comprobar las versiones de las librerías, y que la IA, cada vez que vaya a tocar código, sepa sobre qué versión del software lo está haciendo, sobre todo para usar herramientas modernas recién salidas al mercado o para descartar herramientas obsoletas. También aquí le damos unas directrices más adaptadas a nuestra arquitectura, como por ejemplo: yo personalmente no quiero que me cree mil archivos por funcionalidad, sino que intente siempre agrupar por concepto, por dominio, en un único archivo, o dos o tres, pero siempre intentando minimizar, porque luego para las personas es difícil si tenemos veinte mil archivos. Cuantos menos archivos y más agrupado todo, mejor. Y otras cosas que se mencionan por aquí: dónde declaramos las apps, dónde declaramos las librerías, patrones de nombres o de cómo utilizar las cosas, cómo denominar las capas clean. Muy importante: el tema de comentarios. La IA contamina mucho el código con comentarios gigantes. Tenemos que evitar eso porque contamina todo el código, y hay dos maneras de controlarlo. Una es con esta guía, que lo que le dice es: «Oye, no te enrolles ni pongas muchos comentarios por todos lados: pocos y cortos, y nunca comentes un cambio superficial». Y la segunda manera es con sensores: nosotros con ESLint comprobamos que los comentarios no tengan más de X longitud ni más de X líneas; si las tienen, no dejamos subir al repositorio, porque al final contamina todo el código. Y finalmente le recordamos que tiene que ejecutar ciertas tareas cuando acabe una tarea, por ejemplo comprobar que compila o los temas de ESLint. Ya si vamos un poco más abajo, con los AGENTS.md de cada área funcional, vemos que aquí ya hablamos de cosas específicas del front, de Angular, de i18n, y que cuando cerremos una tarea pasemos el linter, el Stylelint, que pasemos la configuración de TypeScript, temas de la clean architecture. Todo esto está adaptado a cada proyecto, lo mismo para el back y para la infraestructura: cada uno tiene su AGENTS.md donde se dan directrices. Partimos del siguiente caso, que es que tenemos estos ejercicios y nosotros queremos crear un nuevo tipo de ejercicio, que es que el alumno escuche una palabra y le pidamos bien que rellene letras de esa palabra cuando está comenzando a aprenderla o cuando es un nivel muy básico, A1, o podemos pedirle que escriba la palabra entera, o que escriba dos letras, tres letras, etcétera. Entonces ese tipo de ejercicio no lo tengo aquí, y crear uno nuevo implicaría pues crear su icono, su título, su descripción, todo su formulario con sus normas, con las posibilidades que tiene cada uno de los formularios, cuando le damos a «Crear con IA», qué implica crear desde cero, qué vamos a solicitar cuando creamos desde existente, para cada ejercicio. Entonces nosotros tenemos que crear la habilidad de que la IA lo haga por nosotros, y por eso se llama habilidad, skill, porque al final le estamos dando esa habilidad. Entonces vamos a partir de cómo se utiliza una habilidad, qué resultado tiene, y ya después explico cómo hacerla. Nosotros vamos a invocar una habilidad dándole a la barra: add-practice-lesson-exercise. Esto es una habilidad que yo he creado, y ya le dice a la IA el modo en el que se tiene que poner. Y después de esto copio un prompt que tengo pegado por tema de tiempo y le explico el tipo de ejercicio que quiero: «Quiero añadir un nuevo tipo de ejercicio que se llama Escucha y deletrea, que escucha una palabra y tiene que escribirla; a veces son letras, a veces es un hueco, a veces la palabra completa, todo configurable». Vamos a ver el resultado de esto. Una de las primeras respuestas que me ha dado es esta de aquí, donde yo, a través de AGENTS.md, le he dicho que siempre que vaya a empezar a desarrollar una nueva tarea, primero me haga un listado de lo que va a cambiar, lo que va a mover, lo que va a crear. Esto es muy importante porque nosotros tenemos una responsabilidad con el software que hacemos: siempre tenemos que vigilar lo que va a hacer la IA, y simplemente es una revisión superficial de que va a tocar donde tiene que tocar. Una vez visto esto, pues le decimos simplemente que continúe porque todo está bien. Y una vez acaba, nosotros podemos ver que en «Añadir ejercicio» ha aparecido uno nuevo que se llama Escucha y deletrea, y este ejercicio, cuando entramos, ya tiene todas las opciones y todas las cosas que lo hacen encajar en el ecosistema. Nosotros podemos elegir que sea escribir la palabra entera o que sea escribir un número de letras determinado. Aquí vemos que la estrategia para añadir nuevas palabras sigue una filosofía como la de los hermanos, es decir, los hermanos también tienen este tipo de selectores, tienen este tipo de carruseles. ¿Por qué? Porque lo he especificado todo en la habilidad. Entonces vamos a ver si también podemos crearlo con IA. Vamos a crear un ejercicio, ponemos: «Son cinco, cinco», y bueno, aquí tenemos las opciones de la palabra entera, y vamos a poner seis palabras básicas del A1 para alimentos, por ejemplo. Le damos a generar, vale. Aquí lo que vemos es que ya ha creado la IA todos los ejercicios; los guardamos y, una vez está guardado, está creando el enunciado y el título automáticamente. Y aquí vemos que tenemos un reproductor y escribir la palabra entera: milk. Y ya nuestro trabajo, una vez está creada la skill, es darle un poquito mejor diseño o probar cosas, ponerla un poco a prueba, que ejecute pruebas. Entonces hemos visto que con esta habilidad podemos crear muchos tipos de ejercicios diferentes en cuestión de minutos y de manera muy fácil. Entonces, ¿cómo hemos definido esta habilidad? Nosotros tenemos una carpeta llamada skills que va dentro de .agents, y en estas skills tenemos diferentes habilidades, por ejemplo, la que vimos ahora es la de add-practice-lesson, y aquí vemos un montón de instrucciones que se reutilizan en la creación de todos los ejercicios. Vemos que no es nada trivial: es muchísimo trabajo detrás de todo esto, muchísimo ensayo y error, y al final nosotros aquí estamos dando todo el plan, el plan complementario, cada vez que utilizamos la barra. Entonces, al final, una skill no es más que una serie de instrucciones que nosotros damos: «vete a este archivo, añade esto, vete a no sé dónde», que orientan y guían a la IA en crear ese nuevo ejercicio. Por eso las skills son guías. Otras skills son, por ejemplo, añadir un ejercicio de examen, añadir un proveedor de IA, que yo creo que este prácticamente lo van a tener que tener todos los proyectos, porque si no, si al final nosotros trabajamos solo con un proveedor, volvemos a un problema de dependencia, y nuestro objetivo es que si sale un modelo más barato, más rápido y con mejor calidad, cambiemos rápidamente. Entonces añadimos una habilidad reutilizable que lo que hace es añadir nuevos proveedores de IA a nuestro sistema. Por ejemplo, ha salido un nuevo modelo, el Gemini 4 de Google, y quiero añadirlo rápido: pues simplemente invoco esta skill y la IA lo añade rápido a mi ecosistema. Añadir bloques teóricos, generar audios, arreglar problemas de lint... Puedes crear tantas habilidades como quieras, y al final simplemente son, por decirlo de una manera más entendible, instrucciones reutilizables. Y dos skills que voy a adjuntar en este vídeo van a ser tutor-step-by-step. Esta la considero muy importante porque te ayuda a desarrollar código sin hacértelo, y esto es importante para entender tu propio sistema. Al principio es mejor que te oriente la IA creando nuevas funcionalidades, no que te las haga, para que tú entiendas todo el sistema. Y ya, incluso si tú no quieres programar, solo quieres entender un poco el ecosistema por encima, puedes utilizar detailed-step-by-step, que hace lo mismo que esta pero te da el código. Esta habilidad la voy a adjuntar en el vídeo. Te da el código, pero te dice: «vete a este archivo y pégalo aquí, vete a este archivo y pega esto aquí, vete a este archivo y mueve esto, o reemplaza esto, o elimina esto». Entonces te va diciendo paso a paso lo que ella haría, pero lo haces tú, y parece una bobería, pero haciendo eso tú ya estás entendiendo el ecosistema. Y todo esto lo recomiendo: estas dos habilidades las recomiendo utilizar sobre todo para cosas muy nuevas. Para crear, editar o eliminar ejercicios, pues no, porque es un CRUD de toda la vida, pero para lo que es entender tu código, orquestación de agentes, generación de imágenes, generación de todas esas cosas nuevas que están saliendo ahora, montar un MCP, primero hazlo a nivel tutorial, y ya en el futuro lo delegas todo en la IA, pero por lo menos entiende un poco lo que hay detrás, para que, si tú tienes que intervenir, sepas lo que estás haciendo. Vale, continuamos con el tema. Vale, otra cosa que hay que mencionar es que nosotros tenemos un sistema de sincronización de skills, y aquí empezamos a hablar ya de la independencia del proveedor. Tanto Mistral como Codex y también Antigravity usan .agents/skills; las creamos en un único sitio y todos las usan. Sin embargo, Claude todavía va un poco por libre y las sigue declarando en su propia carpeta .claude/skills. Entonces, ¿cómo conseguimos nosotros que, solo añadiéndolas en .agents, que suele ser el estándar de la industria, se sincronicen automáticamente en Claude? En este caso en Codex no, porque Codex ya también cumple con el estándar. Esto lo hacemos con un script de sincronización. Nosotros tenemos en el package.json la sincronización de skills, y esto lo que hace es ejecutar un script, que también lo adjuntaré, que coge todas las skills de .agents, las adapta al formato de Claude y las copia en su carpeta de skills, manteniéndolas sincronizadas, sobrescribiendo si hay cambios, eliminando si se elimina. Entonces, al final, el objetivo es ese: que todas las nuevas habilidades que defina las puedo sincronizar entre el estándar de la industria y Claude. Da la casualidad de que las skills en Codex, en Antigravity, en Vibe, todos utilizan .agents y no hay que sincronizar mucho, pero hasta hace poco, por ejemplo, Codex iba un poco también a su ritmo con su propia carpeta. Al estándar poco a poco se van sumando. Entonces aquí es importante reseñar eso: que las skills tienen que estar sincronizadas entre diferentes proveedores, y eso nos da independencia. Continuemos con los MCP. Los MCP son como una especie de funcionalidades que encapsulamos en un software y que permiten a la IA utilizar esas funcionalidades, es decir, un conjunto de herramientas que puede utilizar. Y hay multitud de MCP en el mundo del software, es decir, si nosotros vemos aquí, hay catálogos como Glama que te muestran pues miles de MCP que cubren diferentes necesidades. Nosotros, como guías para orientar a la IA, utilizamos Angular CLI, que lo que hace es que la IA va construyendo software de Angular intentando seguir buenas prácticas que obtiene a través de este MCP; Context7, que lo que permite es saber la documentación de las versiones de software que nosotros usamos, por ejemplo, si sale una nueva herramienta que se llama signals de Angular, pues que esté al día y no utilice cosas viejas cuando construye software, es decir, que siga guiando la construcción; o codebase-memory, que ya lo vimos al principio del vídeo. Y también MongoDB: la base la utilizamos como guía porque al final obtiene los esquemas, la arquitectura de la información como está en Mongo, y eso ayuda a tomar mejores decisiones. Una vez tenemos definidos nuestros servidores MCP, tenemos que sincronizarlos entre los diferentes proveedores, porque aquí cada uno sí que va un poco por su propio camino. Entonces ahora podemos hacer npm run sync:mcp. Este script os lo dejaré adjunto en el vídeo, en los archivos adjuntos, y al ejecutarlo, lo que hemos visto es que se ha creado un archivo .mcp.json. Esto es para adaptarse a Claude: Claude lo quiere en la raíz del proyecto, y se declararían de esta manera, y le estamos diciendo cómo instalar ese MCP. Y en el caso de, por ejemplo, Mistral, vemos que están definidos de esta manera, totalmente diferente. En el caso de Codex, por ejemplo, lo mismo: tenemos el mismo formato, que de casualidad es muy parecido al de Mistral. Y en .agents lo tenemos definido en este archivo de aquí, de esta manera. Entonces vemos que hemos conseguido con un script una especie de independencia del proveedor, porque creándolo en un único sitio, que es en .agents, que es el sitio centralizado, el único punto de verdad, ya se sincroniza con los otros proveedores. Y si en el futuro un proveedor se acopla al estándar, que es hacerlo en .agents, pues simplemente cambiando el script de sincronización lo arreglamos. Finalmente, podemos utilizar también el test-driven development como sensor del harness engineering, es decir, aquí nosotros vamos definiendo testing unitario antes de crear el código HTML, TypeScript, etcétera, y nosotros definimos qué debe hacer ese componente: sin valor, muestra el texto de «Sin seleccionar»; con valor, muestra la opción que le corresponde; no enseña las opciones hasta que se abre. Es decir, estamos especificando con un test unitario cómo debe ser el componente. Y esto nos sirve tanto como guía como como sensor del harness. Como guía, porque si solo le damos este test, ella va a guiarse con este test para crear el componente de selección, y como sensor, porque una vez construido el componente se ejecuta este test y tiene que dar todo en verde. A modo de recapitulación, en este vídeo hemos visto cómo podemos utilizar las guías para orientar a las IA en el proceso de construcción de software con diferentes técnicas y de manera agnóstica, es decir, que podemos cambiar de proveedor fácilmente. También hay que subrayar que probablemente mañana o dentro de una semana salgan nuevas técnicas. Entonces, al final, esto es un poco la base del estado del arte actualmente, pero es verdad que a medida que pase el tiempo irán surgiendo nuevas guías que orienten mejor aún a la IA. Espero que te haya gustado este vídeo, y en el próximo vamos a ver cómo utilizar técnicas avanzadas de TypeScript tanto como guía como como sensor. Nos vemos pronto.