Harness engineering: com construir un entorn fiable per als agents de programació

Seguramente ya has probado herramientas como Chat GPT, Cloud, Copilot y te has dado cuenta de algo curioso. A veces hacen cosas totalmente increíbles, pero otras veces parece que fallan en lo más simple. Y es que gran parte de las grandes mejoras que ha habido en el ecosistema del desarrollo Conia no han sido tanto mejores modelos como mejores entornos en los que estos modelos se ejecutan. Estos entornos son los que hoy en día se conocen como arneses. En este vídeo te voy a explicar realmente qué son los arneses, qué es este nuevo concepto que ha aparecido que se llama harness engineering y cómo tú puedes dejar de tratar la inteligencia artificial como un simple chatbot y puedes empezar a construir sistemas encima de los modelos. es que el hecho de hacer código es cada vez más sencillo o al menos cada vez más rápido. Yo mismo tengo un montón de vídeos en los que comentaba que el código se leía muchísimo más de lo que se escribía, pero parece ser que hoy en día esta tendencia está empezando a girar. La dificultad de escribir código cada vez se va reduciendo y por lo tanto cada vez estamos generando muchísimo más código haciendo que leerlo sea cada vez más difícil. En resumen, tenemos una máquina capaz de generar miles y miles y miles y miles de líneas de código. Y ahora mismo nuestra responsabilidad entra en intentar controlar este caballo desbocado. Es por esto precisamente que se le ha llamado Harness Engineering a la práctica de construir un entorno, un ecosistema para controlar a este caballo, a este modelo de inteligencia artificial. Se llamaría arnés porque lo equiparamos a nivel metafórico a pues las riendas o a la silla que nosotros le ponemos a un caballo para intentar controlarlo. Hoy

en día se le ha puesto el nombre de Harness Engineering a todas las prácticas que consisten en agarrar un modelo de inteligencia artificial y definirle el entorno que le rodea. ¿Qué sería este entorno? Pues por ejemplo, por un lado tendríamos el contexto que nosotros le queremos enviar. Por otro lado, tendríamos las diferentes herramientas a las que este modelo puede ir para ejecutar ciertas acciones. También tendríamos aparte algún sistema de memoria para darle a este modelo de inteligencia artificial contexto sobre qué es lo que está haciendo, qué es lo que ya ha hecho y las cosas importantes de las que se tiene que acordar. Y también una forma de validación. Date cuenta que una de las cosas que nos ofrece el Harness Engineering es que nosotros definimos todo el envoltorio que rodea este modelo para luego poder ir sustituyendo el modelo de inteligencia artificial a medida pues que se va actualizando, que van saliendo nuevos modelos o incluso que aparecen modelos que son mucho más baratos que modelos actuales. Sería básicamente una forma en la que tú puedes tener un sistema al que simplemente le cambias el cerebro. Teniendo este concepto claro, aquí viene lo interesante y es que mucha gente viendo esto puede pensar, "Vale, pues agarro el modelo, le doy un montón de herramientas, que si skills, que si mps, que si le incremento la cantidad de contexto que le doy al modelo, que si le doy más instrucciones y ya está. tengo un arnés que está supervitaminado y que es superpotente, pues pasa justamente lo contrario. Ha quedado demostrado que cuanto más complejo haces el arnés, peor funciona. Paradójicamente, equipar a los agentes de inteligencia artificial con herramientas hiperespecializadas ha

demostrado ser algo contraproducente, empeora de forma notoria su comportamiento. En este artículo que ha publicado Oversell, en el que se muestra como eliminaron el 80% de las tools de sus agentes de IA, queda demostrado cómo mejora el rendimiento cuando le das herramientas más sencillas. En este artículo se puede ver un ejemplo de desarrollo de un agente de Versel. La mayoría de nosotros conocemos V0, esa herramienta de VEL para poder desarrollar UIs o diseños de aplicaciones y páginas web. Pues Bcel tiene otro agente que se llama D0, cambiando la V por la D, para tener un agente que se encarga de hacer queries y de analizar altas cantidades de información. Sería algo así como un agente de big data. En primera instancia, lo que hizo Vercel fue desarrollar un montón de herramientas pensando que si le daban herramientas especializadas, por ejemplo, para hacer queries SQL o para conectarse diferentes bases de datos a este modelo, le iban a simplificar el trabajo. El modelo no tendría que preocuparse sobre realmente cómo escribir, por ejemplo, queries de SQL de manera correcta. De la misma manera que le intentaban dar una especie de wrapper, una especie de envoltorio que controlara la manera en la que este modelo iba a razonar. Es decir, le querían marcar de una forma muy precisa el camino. Ahora bien, a partir de aquí empezaron a hacerse una pregunta. ¿Y si realmente le quitáramos los ruedines a nuestro modelo de inteligencia artificial y le dejáramos ir por su cuenta? le damos las herramientas mínimas para que pueda empezar a hacer cosas que quizá nosotros como desarrolladores no nos hemos planteado. En este punto, los ingenieros decidieron quitar las herramientas hiperespecializadas y dejar al modelo acceso a herramientas sencillas del

ecosistema Unix, por ejemplo, AGRP para poder buscar entre ficheros, CAT para poder leer ficheros, LS para poder listar directorios y en definitiva dejarles solamente lo necesario para poder empezar a navegar dadas diferentes casuísticas. El resultado, un incremento de más de tres veces en la velocidad y un 37% menos en el consumo de tokens, es decir, literalmente le salía muchísimo más barato hacerlo así. Según se dice incluso en el artículo, esta nueva versión con herramientas más simples venció a la otra en todas las peticiones. Aparte de la degradación de los modelos de IA cuando tienen herramientas hiperespecializadas, también ocurre algo muy curioso con el contexto. Y esto lo hemos vivido todos los que hemos utilizado cloue u otros agentes en grandes sesiones de desarrollo. Y es que parece ser que cuanto más tiempo estás utilizando una inteligencia artificial, más tonta se vuelve. Y es que ha quedado demostrado que a pesar de tener ventanas de contexto muchísimo más grandes que en modelos anteriores, la degradación de los resultados de la IA se ven mucho antes de que se llene. De hecho, hay un issue abierto en GitHub en el que se comenta que a partir del 40% ya se recomendaría limpiar toda la ventana de contexto o abrir una nueva ventana de Cloud Code, empezando esta degradación alrededor del 20%. Por lo tanto, la gestión del contexto y evitar que se inunde la ventana de los diferentes modelos de ella es algo necesario en el ecosistema de la ingeniería de arneses. Y es por ello que cuando hablábamos de esta pieza de darle a la IA el contexto adecuado, también le tenemos que sumar el sistema de memoria, es decir, de alguna forma tenemos que sacar la

información relevante para el modelo de inteligencia artificial de su propia ventana de contexto a partes externas, por ejemplo, a un sistema de ficheros o a una base de datos. Es decir, podemos entender que la ventana de contexto sería este cuadradito de aquí que tenemos dentro del modelo de IA y lo que queremos hacer es poder sacar cosas hacia fuera para que esta ventana de contexto no esté siempre llena. Es por esta misma causa que en general pedirle a un agente de inteligencia artificial que te construya una aplicación completa o dejarlo ejecutando durante horas y horas y horas sin darle un arnés bueno, hace que los resultados sean muy malos. Es por ello que incluso Antropic ha publicado artículos para desarrollar arneses efectivos para estas largas sesiones de codificación para controlar precisamente qué contexto le damos al modelo de IA. En este artículo se explica claramente pues por ejemplo cómo gestionar la cantidad de tareas que nosotros queremos realizar. Un ejemplo que utilizan aquí es utilizar un fichero de Jason en el que se describe, pues, por ejemplo, las tareas que queremos desarrollar para tenerlo de una manera estructurada y que la gente de IA pueda ir agarrándolo en función de lo que considere necesario. Y de esta forma también te puedes permitir tener múltiples agentes trabajando sobre diferentes tareas, porque cuando quieren revisar el estado de cada uno de ellas se pueden ir a este fichero externo y analizar exactamente qué es lo que está ocurriendo en cada momento. También en este artículo se definen otras técnicas para poder utilizar subagentes. Y es que algo que sucede muy a menudo es que nosotros vamos trabajando con estos agentes de inteligencia artificial y, por ejemplo, tenemos una gran parte del contexto relleno, pues ya sea porque ha leído el código, porque ha leído el

proyecto, ha analizado las tareas que se tienen que hacer y a partir de este agente padre nosotros podemos crearnos diferentes subagentes para generar diferentes tareas. Vamos a llamarlos agente uno y agente dos. Claro, lo que queremos evitar es que precisamente cada uno de estos agentes herede todo el contexto que tiene la agente padre. Lo que queremos es precisamente que cada uno de estos agentes tenga menos contexto relleno para que solamente tenga información de lo que realmente tiene que hacer. de forma que como tiene el contexto menos lleno, va a ser más eficiente haciendo esa tarea. No te preocupes porque vamos a ver un pequeño ejemplo de cómo montar esto al final de este vídeo. Ahora bien, incluso si eres capaz de trabajar con un arnés que te intenta solucionar todo esto, hay un problema muchísimo más peligroso y es que realmente no puedes confiar en todo lo que te dice la inteligencia artificial. El código generado con IA puede parecer 100% convincente y puede ser incluso difícil detectar esas pequeñas partes donde realmente no está cumpliendo su objetivo. Recordemos que la IA está entrenada para parecer verosímil, para darte respuestas que parecen ciertas, pero no tienen por qué serlo. Entonces, la pregunta que nos hacemos es, ¿cómo haces que la IA no simplemente diga que algo está hecho, sino que realmente lo demuestre? A un agente de inteligencia artificial tienes que darle herramientas para verificar lo que está construyendo. Estas herramientas pueden ser varias. Podemos pedirle o incluso construir nosotros test automatizados. Podemos pedirle que se levante un navegador y que empiece a hacer alguna prueba, por ejemplo, con Papetir o con las propias Death Tools de Google Chrome. Es decir, nunca tenemos que dejar que sea solamente el agente de

IA que nos diga que algo está realmente hecho. El agente de IA nos tiene que demostrar forzosamente que lo que ha hecho es correcto y está terminado. Y esto solamente se consigue con la capacidad que tiene el desarrollo de software, que es de ser autificable. Pero claro, también hemos dicho que cada vez los agentes de IA desarrollan más código y que puede ser muy complicado tener que estar nosotros verificando y revisando lo que va haciendo. Es por ello que también está apareciendo otra corriente que es la de también utilizar la propia IA como agentes revisadores de código. Una solución que está apareciendo es añadir esta capa de verificación al arnés, es decir, darle instrucciones a la illa sobre cómo tiene que validar que hace un buen trabajo y cómo lo tiene que revisar. Pero muy bien, todo esto suena muy bien en la teoría, pero ¿cómo se ve esto en un sistema, en un proyecto de verdad? Ahora vamos a ver cómo lo hace exactamente Antropic porque lo compartieron en un artículo. En este artículo que se titula Cómo hemos construido nuestro sistema multiagente de investigación, Antropic explica cómo utilizan múltiples agentes con cloue para explorar temáticas de una forma más efectiva. Se trata de un agente que se dedica a investigar temas que quieren, pues, no sé, implementar o de los que quieren aprender. En este artículo se ve claramente como tienen un sistema multiagente en el que tienen un agente que se encarga de orquestar otros pequeños subagentes que se dedican literalmente a buscar información y a guardarla en la memoria. Es decir, tenemos un agente grande que es el orquestador y otros agentes pequeños que realmente hacen el trabajo. Incluso nos dan un diagrama sobre cómo viaja el mensaje y la respuesta hacia el usuario, viendo claramente que el usuario manda

la query hacia el sistema. El sistema crea este agente de orquestación y luego le va delegando de forma iterativa a diferentes subagentes junto con la memoria para poder realizar esta investigación y una vez ha terminado, simplemente le acaba devolviendo la información al usuario. Entonces, habiendo visto todo esto, podríamos definir toda esta arquitectura de arneses y toda esta gestión de los modelos de IA en tres pilares diferenciados. El primer pirar, recordemos, era utilizar el propio repositorio como el sistema, intentar huir de usar la simplemente como un chatbot, intentar montar dentro del propio repositorio este arnés que luego se vitamina con el propio modelo LLM. El segundo pilar sería la orquestación multiagente. Lo hemos visto con el ejemplo de Antropic. Tenemos un agente orquestador que es el líder, es el que gestiona y luego tenemos pequeños agentes que son los que hacen el trabajo. Es responsabilidad del agente orquestador el lanzar, spawnear estos agentes pequeñitos. Y finalmente la parte de verificación. El propio arnés tiene que ser capaz de verificar el trabajo hecho, incluso a veces automejorarse. Si se detecta que algo no están cumpliendo las características o las necesidades del proyecto, se puede actualizar. ¿Por qué? porque el propio arnés es parte del propio proyecto. Por lo tanto, si tenemos un agente que no está haciendo el trabajo correctamente, lo podemos con el propio arnés actualizar, cambiar el prompt, cambiar las reglas para que las siguientes veces que lo lanzamos funcione mejor. Entonces, todo esto está muy bien, pero te quiero compartir un pequeño ejemplo de un proyecto para que veas realmente cómo luce un arnés que tú puedes empezar

a utilizar como desarrollador y que además te vas a poder descargar porque te dejo el enlace en la descripción de este vídeo. Para poder empezar a experimentar desarrollando arneses de IA para vitaminarte a la hora de desarrollar, no necesitas instalarte 1000 cosas ni tener un sistema superclejo. Mi recomendación personal es empezar de menos a más, ir entendiendo cada paso que vas haciendo y ver exactamente para qué sirve. Un proyecto que tiene un arnés implementado podría lucir parecido a esto de aquí. Es decir, nosotros tenemos diferentes agentes, ¿no?, definidos en nuestra carpeta punto cloud. Pues tenemos, por ejemplo, un implementador de código, tenemos el líder y tenemos el revisor para tener estas diferentes patas. Date cuenta, eh, que estos son agentes sersencillos en los que le ponemos un nombre y luego definimos exactamente qué es lo que tiene que hacer. Fijaros en la importancia del protocolo. Cada agente para que forme parte del arnés tiene que seguir las mismas reglas. Por lo tanto, le decimos que lea el Agents MD y diferentes documentos de arquitectura y convenciones de nuestro repositorio. Pero aquí lo que te quiero enseñar realmente es el fichero agents.m. Este fichero sería el punto de entrada de todos los agentes, es decir, es lo primero que va a entrar en el contexto, en esta ventana que hemos comentado de memoria interna del modelo y por lo tanto va a incluir las reglas que tiene que hacer cada gente antes de empezar. Recordemos eh lo que queremos es controlar exactamente qué es lo que está haciendo nuestro caballo, pues poniéndole riendas y controlándolo con esta serie de herramientas. Por ejemplo, aquí le estamos diciendo que antes de empezar cualquier cosa tiene que ejecutar un script que es el init.sh SH y verificar que todo funciona

correctamente. Este script es un script muy sencillo que se utiliza como scaffolding o como script de inicialización de los agentes y puede incluir lo que tú consideres importante. En este proyecto de ejemplo, lo que le hemos incluido ha sido, pues, por ejemplo, verificar que Python está instalado, verificar que existe un agentes MD, que tenemos una lista de características y un fichero de progreso y que todo sigue el formato que nosotros habíamos definido. también que los test se ejecutan, funcionan y están todos pasando. Y finalmente nos dice, "Mira, el entorno está listo, puedes trabajar oye, ha fallado alguna cosa, hay un test que está fallando, no te pongas a trabajar sobre esto o nos fallan ficheros necesarios para que yo pueda trabajar, tampoco continúes." El objetivo de este script es decidir si el proyecto está en un estado suficientemente bueno para que mi agente de IA pueda empezar a trabajar. Si no, para. Entonces, volviendo a la MD, si todo ha pasado con éxito, lo que vamos a hacer a continuación es mirar si tenemos trabajo pendiente de la última sesión o si además tenemos tareas pendientes que podemos empezar a agarrar. Estas tareas estarían definidas en un fichero que se llama featurist.jonjason, Jason, similar al que vimos recomendado por Antropic, que sigue este formato, pues una lista de features en los que tenemos criterios de aceptación y una pequeña descripción de lo que tenemos que hacer junto con el estatus. Tenemos algunas tareas que están realizadas, estas que están aquí en estado don y otras que están en pendientes. Como puedes ver, es algo muy sencillo, no estamos haciendo magia, no hay florituras, luego lo puedes ir complicando como quieras. No quieres tener la lista de tareas aquí en un fichero y lo quieres tener en Linear o en Gira, bueno, ahí ya te puedes montar

un MCP para leer las tareas pendientes y añadírselo aquí a la AGM MD para que en vez de leer este fichero de Jason, pues agarre las tareas pendientes de tu sistema remoto. Pero fíjate que lo importante, insisto, es la estructura. Tenemos el punto de entrada que es el agents MD. También si queremos aquí le podemos dar un mapa del repositorio para que sepa exactamente dónde mirar en cada momento sin tener que leer todo el proyecto y por lo tanto llenarse el contexto. Y una serie de reglas y normas que nosotros le podemos dar, por ejemplo, que no declare una tarea como don, si no ha ejecutado los test y están pasando. Fíjate que aquí estamos cumpliendo el primer pilar, el pilar de que el propio repositorio, los propios ficheros del repo determina el sistema de arneses, lo que va a utilizar nuestra inteligencia artificial, todo su contexto y todas estas series de reglas. Luego también tenemos aquí implementado un sistema de orquestación multiagente, que date cuenta es algo muy sencillo. Ya habíamos visto que tenemos los tres agentes, el líder, el que se encarga de escribir código y el que se encarga de revisarlo. Fíjate que utilizamos la misma información. El líder lo que tiene que hacer es que para cada tarea que nosotros queremos realizar, que viene dada desde el Agents MD, recordemos que mirábamos la primera tarea pendiente para poder trabajar en ella, pues el líder identifica si necesita uno o más agentes. En este caso, pues si es una sola tarea, le decimos que lance un implementer o que si es una tarea de investigación que lance un Explorer. Y también le decimos que una vez termine el implementer que lance un agente de reviewer. Entonces, fijaros que lo que hace el líder es orquestar lo que hacen

los diferentes agentes. Ahora bien, lo que queremos evitar es que se pierda información de lo que van desarrollando los diferentes agentes y que además puedan también compartir cosas entre ellos. Esto es lo que se conoce como evitar el teléfono descompuesto. Aquí le estamos diciendo explícitamente al líder que cuando lance subagentes les diga de forma explícita que escriban los resultados en archivos, concretamente en la carpeta progress. Por ejemplo, si nos vamos aquí a la carpeta progress, pues vemos por un lado la ejecución actual, que en este caso es ninguna porque no estamos desarrollando nada ahora mismo, pero tenemos resultados de diferentes ejecuciones que yo he hecho hace un rato. Tenemos, por ejemplo, aquí un resultado de un agente de exploración con diferentes métricas, diferentes funciones que ha añadido y diferentes dependencias. Aquí tendríamos otro resultado de la exploración y finalmente un fichero también de histórico en el que vamos viendo exactamente qué es lo que va haciendo cada agente. De forma que cuando lancemos un nuevo agente no tenemos que leer todo el proyecto, basta con ir a progreso y ver exactamente qué es lo que se ha ido haciendo. Tenemos un sistema de memoria, no es para nada magia, no es nada complicado, simplemente estamos guardando en un fichero lo que va ocurriendo. Podríamos hacer 1000 cosas. Podríamos en vez de guardarlo en una carpeta, ir un poquito más allá y guardarlo en una base de datos local. Podríamos tener un SQL Lite o cualquier cosa, un DB local y irlo guardando ahí directamente. Bastaría con cambiar cómo nosotros gestionamos pues nuestro sistema de memoria, cómo le pedimos que lo guarde, en vez de que lo guarde en Jason, que lo guarde en SQL. Incluso podríamos llegar al punto de decir, ahora no lo guardes en esta copia SQL local, sino que te vas

a conectar a esta base de datos remota y lo vas a guardar ahí, teniendo entonces incluso como una especie de memoria compartida entre diferentes agentes de IA, pero lo importante es conocer cómo funciona todo esto, que luego lo quieras decorar y lo quieras mejorar de diferentes maneras, va a depender de hasta qué punto tú quieras llegar con tu configuración de tu propio arnés. Y finalmente tenemos también el agente de reviewer, que es el que se encarga de añadir al Arnes esta capacidad de revisión de código. Básicamente lo que va a hacer es aprobar o rechazar el trabajo que le da el implementador. Es decir, el trabajo del reviewer es leer las convenciones y lo que tenemos que hacer, incluso la memoria de nuestro repositorio para hacerse diferentes preguntas. Es decir, por ejemplo, respetamos las peticiones de arquitectura, respetamos las convenciones, vamos a también a ejecutar el fichero init.s SH, que recordemos que ejecutaba los test y tenía ciertas pruebas de calidad para validar que todo pasa. De esta forma, el reviewer le va a dar feedback al implementador para asegurarse de que todo lo hacemos correctamente. Y lo interesante es que como todo esto son ficheros del propio repositorio, si el reviewer se da cuenta de que está revisando cosas o que faltan cosas por mejorar, puede incluso modificarse a sí mismo. Puede modificar el fichero punmd de su propia definición y automejorarse. Entonces, al final la práctica de ingeniería de arneses no es otra cosa que montarte un sistema en tu propio repositorio para ti o para todos tus compañeros, en el que tienes esta configuración que realmente puede exprimir el uso de la inteligencia artificial y va mucho más allá de simplemente trabajar con el chat de cloud o con el chat de Copilot. Incluso

si lo llevas un poquito más allá, puedes implementarte hooks, es decir, por ejemplo, Cloue te da hooks para que tú puedas ejecutar ciertos scripts o ciertas acciones cuando lanzas un agente de IA. En este caso, por ejemplo, yo me he definido un hook en el que cuando yo cierro cloud code quiero ejecutar init.sh SH para asegurarme de que no dejo mi proyecto en un estado fallido. Por ejemplo, si yo ahora mismo abro cloud code en este proyecto, le puedo pasar este prompt en el que le digo, "Oye, lee agents MD y sigue el protocolo, ejecuta init, lee el progreso y elige una feature. Le damos a enter y en principio debería tender a seguir las instrucciones que nosotros le hemos dicho. Fijaros lo eficiente que es el contexto. Directamente lee agents mdon a ejecutar init.shutando SH ejecutando los test. B que los tests están en verde y ve que solamente queda una feature pendiente en la lista que es la búsqueda por CLI. lee directamente la documentación que yo le he dicho que me interesa. En este caso, architecture MD, las convenciones, la verificación y el código ya existente. Y lo primero que va a hacer va a ser marcar esta tarea como en progreso. Todavía no está empezando a implementar, simplemente está diciendo que sigue el protocolo que yo le he pedido. También me actualiza, fijaros, el fichero de la tarea actual para tener contexto guardado fuera de la ventana de contexto para otros agentes. Recordemos la parte del teléfono descompuesto y a continuación tengo al implementador, pues por ejemplo ya implementando los tests que van a ser necesarios para que init.sh SH pase. Finalmente, una vez avalidado que todo funciona porque los test pasan y todo tiene sentido,

marcamos la tarea como don, me lo pone en el fichero history.md en esta especie de change lock y me deja el fichero current, el fichero actual otra vez limpio. Es decir, si tengo un buen arnés, voy a ser capaz de poder implementar cosas con inteligencia artificial intentando guiar la calidad, las metodologías y las herramientas que quiero que utilice. Obviamente, tener un arnés bien montado va a ayudar muchísimo, pero también va a ayudar mucho la calidad del proyecto. Cuando tienes un proyecto consistente, con buenas prácticas, con una estructura clara y no solamente clara, sino también repetible, es decir, que todos los módulos, todas las funcionalidades, todas las secciones de tu proyecto están construidas de una misma manera, para la IA va a ser mucho más fácil predecir cómo tiene que montar nuevas features. Es por ello que siempre digo que seguir buenas prácticas a la hora de implementar código no te ayuda solamente a ti, también ayuda a la inteligencia artificial, porque si tu proyecto sigue buenas prácticas, es más probable que lo nuevo que implemente también la siga. Si sumas buenas prácticas de código, experiencia en programación más un buen arnés en tu equipo de desarrollo, vas a ser capaz de sacarle el máximo partido a la inteligencia artificial. Si quieres ver todavía algunas metodologías para desarrollar con inteligencia artificial de una forma mucho más consciente, te dejo por aquí un vídeo en el que te hablo del Spect Driven Development. Y no es solamente un vídeo en el que te explico lo que es, sino que vas a ver una herramienta con la que lo puedes aplicar y cómo en función de cómo enfocas el SDD puede cambiar por completo tu manera en la que desarrollas. Si te ha gustado este vídeo, por favor, suscríbete y déjame un buen like y nos vemos en el siguiente con más informática. Hasta otra. M.