Cómo hago que mis agentes se mejoren a si mismos con esta skill
La metodología que uso para que Claude Code se mejore a si mismo a través de medir, proponer hipótesis, iterar y validar resultados
Colaboradores: Ivan Garcia Villar
El problema con los agentes no es construirlos, es optimizarlos para que funcionen realmente como tu quieras.
Escribes una idea, ajustas el prompt , haces unas pruebas y confías en que siempre funcionará.
¿Qué pasa si no consigues que funcione exactamente como esperas?
Haces unos cambios, más pruebas… ¿esto te parece una manera fiable de construir tus agentes?… A mí me suena a un proceso de prueba y error en el que no sabes muy bien por qué funciona lo que funciona, y por qué falla cuando falla. Y mucho menos que pasa cuando vuelves a tocar algo.
Hoy te traigo una metodología y una skill que te ayudan no solo a hacer este proceso de forma más profesional sino a automatizarlo (parcialmente), dejando que sea la propia IA la que se mejore a sí misma.
¿Suena bien, cierto?
LLM como Juez, la base del sistema
Esta metodología se basa en que los modelos de IA son mucho mejores valorando resultados que generándolos, por eso este sistema funciona. Pones a una IA a valorar lo que otra IA hace y a optimizarla para mejorar el resultado.
Obviamente tiene límites. El criterio de la IA que actúa como juez es limitado, pero dado que los modelos son mejores valorando que generando, funciona incluso cuando el modelo que valora es igual de potente que el que genera.
El agente que actua como juez (claude code) puede modificar tanto el prompt como la arquitectura de los agentes a los que valora (si hay más de un paso), proponer usar otros modelos, investigar por internet diferentes técnicas, etc.
Si no mides no mejoras
Imagina que empiezas a ir al gimnasio. El primer día te pesan: 75 kilos. Ese número es tu baseline, el punto de partida con el que vas a comparar todo lo que viene después.
Ahora hay que decir cuál es tu objetivo, pongamos que es bajar unos kilos.
Si al mes tienes 74 kilos, sabes que la rutina funcionó. Si tienes 76, algo no va bien. Sin ese número inicial, no tendrías idea de si el mes de entrenamiento sirvió para algo.
Con los agentes funciona igual. Una métrica es un número que te dice qué tan bien está funcionando tu sistema: cuántas respuestas correctas da, cuántos errores tiene, cuánto tarda. Sin ella, no puedes saber si un cambio mejoró las cosas o las empeoró.
El error que comete casi todo el mundo al empezar: ajustar el prompt, probar a mano un par de casos, y concluir “parece que funciona mejor”. Eso no es mejorar sistemáticamente. Es intuición disfrazada de iteración.
Lo que necesitas es un punto de partida medible: un programa que pruebe tu agente automáticamente con un conjunto fijo de casos y te devuelva una métrica comparable. Siempre los mismos casos, siempre el mismo juez, siempre el mismo proceso. Así los números son comparables entre experimentos.
Si esa comparación puede hacerse sin un LLM mucho mejor. Por ejemplo, si tienes un dataset extenso y el modelo tiene que conseguir obtener una lista exacta de resultados que sabes de antemano, es algo que puedes hacer sin LLM. Ya tienes la lista, tan solo tienes que comparar cuántos ha encontrado.
En los casos en los que es imposible definir cuál es el resultado ideal, Claude Code actúa como juez.
Paso 0: Sentar las bases
Definir que quieres mejorar
El primer paso y más importante: definir correctamente un punto de partida medible y qué significa “mejor” o “peor” antes de cambiar nada.
Antes de empezar, hay que responder cuatro preguntas:
¿Cuál es la métrica principal que quieres mejorar? Por ejemplo: “Quiero que el agente clasifique correctamente el 95% de los textos que recibe.”
¿Qué otras métricas no pueden empeorar? Si haces que el agente sea más preciso, pero ahora tarda el doble, quizás no es una mejora. Define qué no puedes sacrificar.
¿Qué hace que un resultado sea mejor o peor? Tienes que darle a tu juez el suficiente contexto como para que sepa valorar si el resultado de un experimento es mejor que otro
¿Qué conjunto de inputs vas a usar para medir? Necesitas ejemplos representativos del problema real: los casos habituales y los casos difíciles que suelen fallar. Si cambias los ejemplos de test entre experimentos, los números dejan de ser comparables y el proceso entero pierde sentido. Esta condición no es negociable. Si necesitas cambiar el conjunto de datos, estás estableciendo un nuevo baseline, no lo compares con resultados anteriores.
Con esas preguntas respondidas, la skill construye el script de evaluación, lo ejecuta sobre el sistema actual sin modificar nada, y registra esos números. Ese es tu punto cero.A partir de aquí, todo se mide contra ese número. No contra tu impresión, no contra “la última vez que lo probé”. Contra ese registro.
Diseñar el experimiento
El agente diseña un experimento ejecutable que toma el sistema que quieres optimizar, hace las medidas que le has propuesto y te devuelve un resultado
Por ejemplo, si estás optimizando cómo un agente hace búsquedas en internet para encontrar clientes para tu negocio y la métrica que quieres optimizar es la relevancia de los contactos, el agente diseñará un script que ejecutará tu algoritmo de búsqueda para una serie de búsquedas predefinidas y juzgará el resultado en las métricas que le has indicado a tiene que tener en cuenta. Con esto se tomarán las siguientes decisiones.
El ciclo de seis pasos
Con el baseline establecido, el siguiente paso es que nuestro agente entre en un ciclo de automejora iterativa
Paso 1: Leer el estado actual. Claude code lee las métricas del baseline y el historial de experimentos anteriores
Paso 2: Proponer una hipótesis. Claude code razone, investiga en internet, propone una nueva hipótesis y la documenta: qué quiere cambiar, por qué cree que va a funcionar, y qué resultado espera ver en los números.
Paso 3: Aceptar la hipótesis. En este punto puedes apoyar al modelo, lee la hipótesis y decide si tiene sentido probarla o prefieres iterar. Puedes indicarle que se salte este paso al principio para que pruebe él solo las cosas más obvias.
Paso 4: Implementar y medir. Claude code hace el cambio en el código, ejecuta el script de evaluación, y registra los nuevos números.
Paso 5: Decidir. ¿Mejoró la métrica principal sin empeorar las secundarias? Adoptar. ¿No mejoró, o empeoró algo? Descartar. Puedes tomar tu la decisión o delegarla en Claude, depende de si tu modelo es lo suficientemente bueno juzgando el resultado o no.
Paso 6: Documentar y commit. Si se adopta, hace un commit con la descripción del experimento. Si se descarta, hace un revert y documenta por qué no funcionó. Después vuelve al paso 1.
Lo importante no son los pasos en sí, sino que el agente los siga en orden sin saltárselos. Sin metodología explícita, los modelos tienden a combinar varios cambios a la vez porque “todos parecen buenos”, a no revertir cuando algo falla, o a olvidar el baseline entre iteraciones. Con instrucciones explícitas en la skill, eso no pasa.
Lo que aprendes después de varios ciclos
El conocimiento negativo vale igual que el positivo. Un experimento descartado con sus números y su razonamiento es información real. Si en seis meses alguien propone la misma idea que ya se probó, podrás comprobarar si ya se probó antes y cuál fue el resultado.
El sistema es capaz de proponer hipótesis y mejorarse por si mismo. El agente puede llevar horas en este ciclo mientras haces otra cosa. Cuando vuelves, no tienes un sistema igual con un par de ajustes: tienes un log de experimentos, un baseline actualizado, y muchas variaciones ya evaluadas. Lo que antes eran días de iteración manual se comprime en unas pocas horas de ejecución autónoma.
¿Cómo uso esta skill?
Descargas el fichero y lo añades a tu proyecto de Claude Code. A partir de ahí, cuando quieras arrancar una sesión de optimización, le dices algo tan simple como:
“Quiero optimizar el agente de clasificación. Sigue la metodología /experiment-driven-optimization”
Claude Code lee la skill, sabe exactamente qué tiene que hacer, y te hace las preguntas del Paso 0: qué métrica quieres mejorar, qué no puede empeorar, qué casos de test vas a usar. Si ya tienes un baseline establecido de una sesión anterior, lo lee del README y entra directamente en el ciclo.
Lo que cambia cuando tienes la skill es que no tienes que recordar el proceso ni supervisar cada paso. Claude code te guia cada paso para que no te tengas que preocupar por los detalles.
Una sesión típica funciona así: le dices que empiece, le explicas que quieres conseguir, Claude crea el script de evaluación, lo ejecuta y documenta, genera hipótesis, comienza a trabajar. Puedes indicarle que no te pida validación para ejecutar las hipótesis para tener una buena base de pruebas antes de empezar a interactuar con él.
Para qué sistemas funciona esto
La metodología no es específica de ningún tipo de agente. He usado este ciclo para optimizar pipelines de recuperación de información, estrategias de búsqueda de datos online, generación de contenido automático… Prácticamente puedes aplicarlo a cualquier algoritmo que incorpore IA o que no tengas muy claro cómo optimizar.
Solamente necesitas cumplir dos condiciones.
- Eres capaz de diseñar un conjunto fijo de inputs que representa bien el problema real. \
- Puedes calcular automáticamente si el output es mejor o peor, ya sea de forma algorítmica o a través de un agente que hace de Juez.
Esta base de tests también te será muy útil si en el futuro quieres cambiar el modelo que usas en tu sistema agéntico, tan solo tienes que cambiar el modelo, medir y comparar. Lo único que no puedes cambiar es el Juez, si lo cambias necesitas establecer una nueva baseline.
Un concepto nuevo cada semana
¿Cuántos casos de test necesito en el test runner?
Depende del problema. Lo más importante no es el número exacto, sino que los casos sean lo suficientemente variados y representativos: incluye los casos habituales y los casos difíciles que suelen fallar.