Evals con Claude Code: build-eval y hillclimb paso a paso

Tu prompt saca un 98,9% en los casos con los que lo has afinado. Lo pruebas con casos que nunca ha visto y se queda en un 90,5%.

El ejemplo lo cuenta Anthropic en su artículo Automating eval design and hillclimbing with Claude, firmado por Lance Martin el 28 de septiembre de 2026. La misma configuración, dos notas distintas: una sobre los tickets con los que se había optimizado y otra sobre 14 tickets que el proceso nunca vio.

Los dos números mejoraban respecto al punto de partida. Pero si solo miras el primero, te crees que has ganado mucho más de lo que has ganado.

De ese hueco va este post. Y de las dos herramientas que Anthropic ha metido en la skill claude-api de Claude Code para cerrarlo: /claude-api build-eval y /claude-api hillclimb.

En este post vas a ver:

• Qué rasgos tiene una eval que merece tu confianza (y cuáles delatan una que te miente)
• Cómo build-eval convierte esos principios en una entrevista guiada dentro de tu repo
• Cómo elegir qué optimizar antes de ponerte a subir la montaña
• Cómo se cuela el sobreajuste en tu harness y cómo lo frenas
• Cómo trabaja hillclimb ronda a ronda y los dos casos reales que publica Anthropic

He llevado los ejemplos a casos en español: un clasificador de correos de soporte de una tienda online, un bot de devoluciones y cosas así. Las cifras son las del artículo original, sin tocar.

Una eval es una foto del trabajo real ¶

Una eval es un conjunto de casos de prueba con una forma de puntuarlos que te dice cómo de bien hace tu aplicación con IA una tarea concreta. Hasta ahí, nada nuevo. Lo difícil, según el artículo, es diseñarla para que sea fiable y, después, usarla para mejorar el sistema sin engañarte con la nota.

Anthropic resume las evals buenas en cuatro rasgos.

1. Las tareas se parecen a producción. Los casos salen del uso real que te importa. El atajo típico es quedarse con las tareas fáciles de generar o fáciles de corregir, y esa distribución casi nunca coincide con lo que de verdad llega a tu app.

Piensa en un bot que clasifica los correos de soporte de una tienda de zapatillas. Si tu eval está llena de “¿dónde está mi pedido?” porque son fáciles de etiquetar, pero en producción lo que duele son los correos mezclados (“me llegó la talla mal, quiero cambiarla y además me habéis cobrado dos veces”), tu eval mide otra tienda.

2. Más capacidad y más esfuerzo de razonamiento dan más nota. Un modelo más potente, o el mismo con más effort, debería puntuar más alto. Si pasa lo contrario, el artículo apunta a dos sospechosos habituales: tareas ambiguas o un corrector (el grader) mal calibrado que está hundiendo la nota.

3. Queda margen alcanzable en la frontera. El mejor modelo con el máximo esfuerzo tiene que quedar bastante por debajo del 100%. Si no, no puedes distinguir un cambio bueno de uno malo. Pero ese margen no puede venir de tareas imposibles o ambiguas. La pista para detectarlas: una tarea que falla siempre, la ejecutes las veces que la ejecutes.

La regla para saber si una tarea es buena es muy de sentido común: dos personas expertas en el dominio llegarían al mismo veredicto, y todo lo que comprueba el corrector está escrito en el enunciado de la tarea.

4. Poca varianza entre ejecuciones. Si la nota baila mucho de una ejecución a otra, suele ser por tareas ambiguas o porque el corrector da veredictos distintos para la misma salida. También se puede esconder en la configuración (un effort que no se aplica igual en todas las llamadas) o en el entorno: ficheros o historial de git que quedan de una prueba anterior y le chivan la respuesta al agente.

🔑 Si tu eval falla en alguno de estos cuatro rasgos, cada punto que ganes al optimizar puede ser ruido o un corrector mal calibrado. Arréglala antes de ponerte a subir la nota.

La trampa de elegir casos donde el modelo falla hoy ¶

Aquí hay un error que parece buena idea. Coges los casos en los que tu modelo actual falla y los metes en la eval. ¿Qué puede salir mal?

El artículo lo explica con una imagen: la capacidad de un modelo es dentada, tiene picos y valles repartidos por el espacio de tareas. Si eliges casos solo porque el modelo de hoy los falla, estás muestreando sus valles. Lo que mides es su huella de fallos, no lo que es difícil o valioso para tu aplicación. Llega el siguiente modelo, esos valles concretos desaparecen, y tu eval apenas te dice cuánto ha mejorado en todo lo demás.

La recomendación es elegir cada caso porque alguien ha juzgado que es difícil y puede explicar por qué antes de ver el resultado. Los fallos concretos que salen del tráfico real, de los informes de bugs o de los tickets de soporte valen.

Con un matiz que me parece oro: no te fíes a ciegas del tráfico de usuarios. La gente suele probar lo que espera que funcione. Si solo muestreas de ahí, tu distribución sale más fácil de lo que es.

En la tienda de zapatillas, “cliente pide factura con NIF de empresa para un pedido hecho como particular” es un caso difícil que alguien del equipo de atención reconoce a la primera. Mucho mejor candidato que “el modelo de esta semana confundió devolución con cambio en un correo con faltas de ortografía”.

Curso gratis · paso a paso

Si el corrector solo puede comprobar lo que está escrito, empieza por escribirlo

Una buena tarea de eval es una spec en miniatura. En la lección de proposal y spec del curso de SDD con OpenSpec ves cómo dejar por escrito qué tiene que hacer el agente antes de que toque una línea.

Entra en el curso gratis →

Qué hace /claude-api build-eval en tu repo ¶

/claude-api build-eval es un subcomando de la skill claude-api que lanzas dentro de Claude Code. Claude te entrevista, construye la eval en tu propio código y se para en puntos concretos para que tú apruebes antes de seguir. Según la cobertura de vibecoding.tech, necesitas Claude Code 2.1.259 o posterior.

De dónde saca los casos ¶

El orden de preferencia que sigue la skill para conseguir entradas es este:

1. Transcripciones de conversaciones en producción (antes te pregunta por retención de datos y datos sensibles)
2. Informes de bugs y tickets de soporte
3. Entre cinco y diez casos que escribes tú a mano
4. Casos sintéticos generados a partir de tu código

También puedes darle unos pocos ejemplos reales como ancla y que sintetice el resto a partir de ellos. Con las entradas listas, la skill genera una página sencilla con todas y espera tu visto bueno.

El ejemplo que enseña el artículo es un enrutador de bandeja de entrada con 24 entradas etiquetadas (“facturación”, “sencillo”, “ambiguo”…). La pregunta que te hace Claude es la que tendrías que hacerte tú siempre: ¿estas entradas representan lo que tu app se va a encontrar? ¿Falta algún caso obvio o sobra alguno que no importa?

Llevado a nuestro ejemplo, una entrada de la eval podría verse así:

{
  "id": "soporte-017",
  "input": "Hola, pedí unas Runner Pro en la 42 y me llegaron en la 44. Quiero cambiarlas, pero además veo dos cargos en la tarjeta. ¿Me lo solucionáis?",
  "tags": ["cambio", "facturacion", "ambiguo"],
  "expected": { "queues": ["cambios", "facturacion"], "priority": "alta" }
}

El corrector: el más barato que funcione ¶

La regla es elegir el corrector más barato que resuelva el problema. El artículo distingue dos familias.

Verificación por código. Cuando el espacio de salida está acotado, lo compruebas con un programa: coincidencia exacta, una etiqueta dentro de un conjunto fijo, un JSON que cumple un esquema o unos tests que pasan. Para nuestro enrutador, con colas cerradas, basta con algo así:

VALID_QUEUES = {"envios", "cambios", "devoluciones", "facturacion", "otros"}

def grade_routing(output: dict, expected: dict) -> float:
    """Returns 1.0 if the predicted queues match the expected ones."""
    predicted = set(output.get("queues", []))
    # Si el modelo se inventa una cola que no existe, suspenso directo
    if not predicted <= VALID_QUEUES:
        return 0.0
    return 1.0 if predicted == set(expected["queues"]) else 0.0

LLM como juez. Cuando la salida es abierta (hay muchas respuestas correctas, pero el criterio de calidad está claro) es la opción por defecto. Un segundo modelo lee la entrada, la salida y una rúbrica, y devuelve una nota con su justificación.

Dos detalles del artículo que marcan la diferencia:

• La rúbrica se escribe como afirmaciones comprobables, no como una escala del 1 al 5.
• Si hay una versión base con la que comparar, el juez lee las dos salidas en orden aleatorio, sin saber cuál es la base, y elige la mejor. El modelo juez lo eliges tú y no debería ser el mismo que estás evaluando.

Para un bot que redacta la respuesta a un cliente que quiere devolver un pedido, la rúbrica podría quedar así:

Evalúa la respuesta del agente. Marca cada afirmación como CUMPLE o NO CUMPLE:
1. Menciona el plazo de devolución de 30 días que figura en la política.
2. Explica cómo generar la etiqueta de devolución desde "Mis pedidos".
3. No promete un reembolso antes de que el almacén reciba el producto.
4. Trata al cliente de tú, como el resto de comunicaciones de la tienda.
5. No inventa costes de envío que no aparecen en la política.

¿Ves la diferencia con un “puntúa del 1 al 5 la calidad de la respuesta”? Aquí dos personas distintas marcarían lo mismo.

Valida el corrector antes de creerte la nota ¶

Antes de fiarse de nada, Claude corrige unos cuantos casos y te pregunta si tú habrías puesto otra nota en alguno. El artículo insiste: lee un lote de transcripciones corregidas antes de confiar en la puntuación, porque los fallos del corrector son una de las causas más habituales de una eval mal montada.

Con el corrector validado, la skill te dice el tamaño de la ejecución (casos × repeticiones × modelos, y cuánto va a tardar más o menos), lanza la versión base y te imprime la nota con su intervalo de confianza.

Lo que te llevas es bastante concreto:

• Los casos, el corrector y el ejecutor, dentro de tu repo
• Un JSON por caso y la transcripción completa de cada ejecución
• Una página sencilla con la nota de cada caso enlazada a su transcripción

En el ejemplo del artículo (marcado como ilustrativo), esa página de la versión base muestra una precisión media de 0,681 sobre los 24 casos. Si quieres gráficas u otra vista, le pides a Claude una página extra. Por defecto son ficheros estáticos que abres en local y que no cargan nada de internet.

Tres diagnósticos mientras se ejecuta la base ¶

Mientras lanza la versión base, la skill revisa tres cosas por su cuenta:

⚠️ Si tu eval ya está en el 95%, subir la nota no es el objetivo. Aprovecha para que Claude busque cómo bajar coste o latencia manteniendo el rendimiento.

Antes de subir la montaña, elige bien cuál ¶

Hillclimbing significa “escalar colinas”: haces un cambio pequeño, mides, te quedas con él si mejora y lo deshaces si empeora. Repites. El artículo lo presenta como una forma eficaz de ajustar los parámetros que intercambian coste por rendimiento, como el effort o el prompt.

Pero antes de ponerte las botas conviene elegir bien qué vas a tocar. Anthropic da tres criterios.

Iteración barata. Cambiar y deshacer tiene que costar poco en tiempo, dinero y esfuerzo. Por eso muchos proyectos internos y de clientes centran la escalada en texto, como prompts y skills: se editan y se revierten en segundos. Meterse con cambios abiertos en el harness del agente, en cambio, puede arrastrar un montón de código. Si el término te suena a chino, en qué es el AI harness lo tienes desmenuzado.

Atribuible. El cambio en la nota tiene que poder atribuirse a lo que estás tocando. El ejemplo del artículo es el disparo de una skill: la métrica (cuántas veces se activa) depende de la descripción que estás editando, sin intermediarios.

Objetivo acotado. El fallo más común es soltar un “mejora el rendimiento” sin haber mirado cuánto margen tiene la eval. Una eval casi saturada o un objetivo difuso (“toca el harness”) tienden a estancarse.

El coste es, según el artículo, un objetivo fuerte en casi cualquier proyecto. Aunque tu eval esté saturada, puedes pedirle a Claude que busque formas de abaratar sin perder rendimiento. Lo verás en el primer caso real.

💡 Una buena petición no es “mejora mi bot de devoluciones”. Es “reduce el coste por ticket de mi bot de devoluciones sin bajar de la nota actual en el conjunto de test”.

El sobreajuste, o cómo tu harness aprende a hacer trampas ¶

Ni la mejor eval es una copia exacta de las tareas que llegan a producción. Por eso es tan fácil sobreajustarse a ella: el sistema mejora en la eval y en producción se queda igual.

El artículo describe varias formas en que la eval se “filtra” dentro del harness (el código que rodea al modelo: prompt, herramientas y el bucle que llama a Claude). Su ejemplo: una tarea de la eval se resuelve mucho mejor con OCR, pero en producción el OCR casi no se usa. Durante la escalada, el harness puede acabar con una herramienta de OCR que sube la nota del benchmark y no cambia nada en producción.

En castellano de oficina: es como preparar el carné de conducir memorizando el circuito del examen. Apruebas, sí. El lunes te toca aparcar en otra calle.

El caso extremo es la filtración descarada: la respuesta está en un repo público y el harness se descarga la solución de referencia con un curl.

Las tres defensas que propone el artículo:

1. Divide los casos. Una parte de entrenamiento que el hillclimber (el Claude que propone los cambios) puede leer, y una de test que no ve nunca. Si la nota de entrenamiento sube y la de test se queda plana, huele a sobreajuste.
2. Nunca pegues los fallos en el prompt. El hillclimber puede leer las transcripciones que fallan, pero no debería copiar su contenido literal en el prompt.
3. Que la respuesta sea inalcanzable por estructura. Los modelos a veces hacen reward hacking y encuentran la respuesta de la eval por su cuenta. Monta el entorno para que no puedan llegar a ella.

La segunda regla es la más fácil de romper sin darte cuenta. Un ejemplo de cambio que parece inocente:

❌ Añadido al prompt tras ver un fallo:
"Si el cliente menciona 'Runner Pro' y 'talla 42', envíalo a la cola de cambios."

✅ Cambio que ataca la causa:
"Cuando un correo mezcla un problema de producto y uno de cobro,
asigna las dos colas y marca prioridad alta."

El primero arregla un caso de la eval. El segundo arregla una familia de correos que también va a llegar en producción.

Este problema no es exclusivo de las evals, por cierto. Es primo hermano de lo que cuento en errores comunes al construir un agente de IA.

Construye agentes con criterio

Construye el agente que luego vas a evaluar, capa a capa

El sobreajuste nace en el harness. En esta masterclass verás cómo se levanta un agente en seis niveles, de las tools a la orquestación, y cómo se evalúa con LLM as Judge.

Entrar a la masterclass →

6 niveles de arquitectura, en directo

Cómo trabaja /claude-api hillclimb ronda a ronda ¶

/claude-api hillclimb es el segundo subcomando. Con una eval ya montada, Claude itera sobre ella para mejorar tu sistema hacia el objetivo que le marques. Tú decides qué puede tocar:

• El system prompt
• Skills o ficheros de instrucciones
• Descripciones de herramientas
• Elección de modelo, effort y otros parámetros de la API
• Código del harness

Lo que pasa antes de la primera ronda ¶

Claude te pregunta qué quieres optimizar: rendimiento, o coste con el rendimiento igual. Después divide la eval al azar en entrenamiento y test.

Si el objetivo es coste, repasa las palancas habituales: prompt caching, que el prompt encaje con el modelo elegido y la combinación de modelo y effort.

Y un paso que me parece de lo más sensato de todo el artículo: antes de la primera ronda comprueba si el ruido de la eval (cuánto puede moverse la nota por puro azar) es menor que la mejora mínima que te haría actuar. Si no lo es, te lo dice claro y te sugiere más repeticiones o más casos.

¿Para qué vas a escalar si no puedes distinguir un paso hacia arriba de un tropiezo?

Cada ronda: un cambio, dos notas ¶

En cada vuelta, Claude lee las transcripciones de entrenamiento de la ronda anterior, propone un único cambio en forma de parche y vuelve a ejecutar la eval con esa versión. Busca cambios que puedan superar el ruido: arreglar la causa del fallo (reescribir la sección del prompt que lo provoca, añadir una regla que falta), no cambiar una frase por un sinónimo.

La decisión sigue tres reglas:

El artículo enseña una página de resultados de ejemplo (de nuevo, ilustrativa, no son medidas reales). Parte de una base con media 0,681 y 0,667 en test. La v1 define cada cola y añade una regla para desempatar: sube a 0,875 en la media y 0,875 en test, y queda marcada como la mejor. La v2 añade dos ejemplos de demostración: la media sube a 0,917, pero el test baja a 0,833. Se revierte.

Si solo miraras la media, la v2 parecería la ganadora. Con el test delante ves que esos dos ejemplos solo ayudan en los casos que el hillclimber ya había leído.

⚠️ En ese ejemplo el test tiene ocho casos, así que 0,875 y 0,833 se separan por un solo caso. Sirve para entender la regla, no como prueba estadística. Con tus evals, fíjate en los intervalos de confianza.

Cuando se atasca ¶

Si la nota se estanca dos o tres rondas, Claude deja de proponer cambios y lee uno a uno los fallos que quedan en entrenamiento para agruparlos por causa. Hace lo mismo antes de tiempo si ve que ningún arreglo individual podría superar el ruido, y entonces te propone más repeticiones o más casos.

Con esa clasificación Claude detecta casos ambiguos en la eval, errores del harness o simple varianza entre ejecuciones. Solo los fallos que tienen sentido pasan a las siguientes rondas.

Al terminar ¶

Claude deja tu código en la versión con mejor nota en test para tu objetivo y te informa de la diferencia con la base y su intervalo de confianza. Si la mejora cae dentro del ruido, te lo dice y te recomienda no hacer merge.

Esa última parte me gusta mucho. Después de horas de rondas, Claude puede acabar diciéndote que no merece la pena, y eso te ahorra meter en main una mejora que solo existe en la hoja de resultados.

Caso real 1: un 90% en tickets que nunca vio, a una quinta parte del coste ¶

Anthropic lanzó hillclimb sobre un benchmark interno de atención al cliente con el objetivo de bajar coste y subir rendimiento a la vez. El benchmark tenía 44 tickets: 30 para buscar mejoras y 14 reservados.

El punto de partida: Opus 4.8 con el effort por defecto (alto), un 74,4% de aciertos en los tickets de búsqueda y 4,6 céntimos de dólar en tokens por ticket.

El recorrido tuvo cuatro pasos:

1. Revisar el prompt. Fuera los rituales de llamadas obligatorias a herramientas, los pasos de borrador y las reglas que se contradecían entre sí.
2. Pasar a Opus 5.5 con effort bajo. 87,8% de aciertos, ya por encima del 74,4% inicial, y el coste baja a 1,9 céntimos por ticket, menos de la mitad. Parte del ahorro viene del precio: según el artículo, Opus 5.5 cobra un 20% menos que Opus 4.8 por token de entrada y salida, y un 60% menos en lecturas de caché.
3. Bajar un escalón más: Sonnet 5 con effort bajo. Como Opus 5.5 ya aprobaba, hillclimb probó si el modelo más barato también. 88,9% y alrededor de 1 céntimo, la mitad que el paso anterior.
4. Afinar el prompt. Añadir referencias cruzadas entre las reglas de enrutado y los límites de reembolso lleva a Sonnet 5 al 98,9% en los tickets de búsqueda, con un coste parecido.

Ahora mira los 14 tickets reservados. En los 14 tickets que el proceso nunca vio, la configuración final saca un 90,5%, frente al 78,6% de la original, y a más o menos una quinta parte del coste.

El 98,9% es el número que sirve para seguir la escalada. El 90,5% es el que cuentas en la reunión. Y ojo, que 14 tickets son pocos y el artículo no publica intervalos de confianza para esta cifra.

Traducido a un caso nuestro: si tu bot de devoluciones gestiona 20.000 correos al mes, pasar de 4,6 a 1 céntimo por correo son unos 720 dólares menos al mes solo en tokens. Echa tú las cuentas con tu volumen, que para eso están.

🔑 Fíjate en dónde cae el ahorro: en los pasos 2 y 3, al probar modelos más baratos con effort bajo en cuanto el anterior ya aprobaba. El prompt aportó sobre todo precisión. Si tú siempre usas el modelo grande “por si acaso”, ese paso te toca probarlo.

Caso real 2: la skill claude-api se evalúa a sí misma ¶

El segundo ejemplo tiene su gracia: la skill que se mejora es la propia claude-api, la misma que trae build-eval y hillclimb. Su trabajo es dar a Claude la información para usar bien la API de Anthropic, así que el equipo montó una eval derivada de la documentación para comprobar si el código que escribe Claude con la skill usa la API como toca.

Punto de partida: 66%. Al hillclimber le dieron acceso a la documentación y a los SDK para que pudiera encontrar y corregir los errores él solo.

Rellenar huecos. Claude detectó que a la skill le faltaba contenido sobre ocho funcionalidades. Con esas secciones añadidas, la nota subió al 74%. Después encontró errores en las tablas de tipos de C# y Java y llegó al 77%.

Pararse a pensar. Tras dos rondas sin avanzar, entró en el paso de clasificación: no tocar nada y agrupar los fallos restantes por causa.

El problema de verdad. Mirando los fallos en conjunto, el hillclimber vio que el contenido sí estaba en la skill. El problema era que Claude escribía código con la forma de versiones antiguas de la API, las que aprendió durante el entrenamiento. La solución fue una tabla de equivalencias al principio de la skill que lleva de lo que el modelo recuerda a lo actual. Por ejemplo:

Además movió en C# y Java el aviso contra el thinking con presupuesto fijo para que apareciera antes de los ejemplos de adaptive thinking. Resultado: 80%.

Arreglar la eval. Aquí el artículo da un criterio que me apunto: una tarea que no mejora aunque hayas cerrado un hueco de contenido evidente es señal de que el ejemplo o el corrector están mal. Una tarea pedía un programa que capturase un único tipo de error, pero el corrector exigía una cadena de al menos tres. Otro corrector tenía instrucciones que contradecían la documentación, y al probar contra la API real resultó que la documentación tenía razón.

Claude reescribió la tarea, corrigió los correctores, añadió más cambios a la skill y llegó a cerca del 88% (87,9% en la ronda 24).

Un apunte honesto: en ese último tramo se mezclan arreglos del corrector y mejoras de la skill, y el artículo no separa cuánto aporta cada cosa.

¿Quieres ver cómo se aplica una idea parecida a tus propias skills, con subagentes y comparaciones a ciegas? En skill-creator en Claude Code tienes el recorrido completo.

Una lista de comprobación para tu próxima eval ¶

Si juntas los dos casos, sale la idea que atraviesa todo el artículo: la eval también se equivoca, y hay que validarla antes de escalar sobre ella. El primer caso lo demuestra con los tickets reservados. El segundo, con los correctores que contradecían la documentación.

Antes de lanzar build-eval o hillclimb en tu proyecto, repasa esto:

1. ¿Los casos salen de tu tráfico real, de bugs o de tickets, y no solo de lo fácil de generar?
2. ¿Cada caso difícil lo es porque una persona lo juzgó así, no porque el modelo de hoy lo falle?
3. ¿Has leído un lote de salidas corregidas antes de fiarte del corrector?
4. ¿La rúbrica son afirmaciones comprobables y el juez es un modelo distinto al evaluado?
5. ¿Tienes separados entrenamiento y test, y el hillclimber nunca ve el test?
6. ¿El ruido de la eval es menor que la mejora mínima que te importa?
7. ¿Cuando algo se atasca, clasificas los fallos antes de cambiar más cosas?
8. ¿Lo que comunicas es la nota en test, con su intervalo de confianza?

Si tienes más de dos “no”, arregla la eval primero. Lo demás puede esperar.

Para empezar, dentro de Claude Code lanza /claude-api build-eval (puedes darle trazas u otros ejemplos para guiarlo, y tanto los casos como el corrector pasan por tu aprobación). Si ya tienes una eval, /claude-api hillclimb y dile tu objetivo: más rendimiento, o menos coste con el mismo rendimiento.

Preguntas frecuentes ¶

¿Qué es una eval en aplicaciones con LLM? ¶

Es un conjunto de casos de prueba con una forma de puntuarlos que mide cómo de bien hace tu aplicación con IA una tarea concreta. Sirve para comparar versiones de prompt, modelo o parámetros con datos en lugar de impresiones. Si está bien diseñada, se parece a lo que llega a producción y da notas estables.

¿Qué hace /claude-api build-eval? ¶

Es un subcomando de la skill claude-api de Claude Code que te entrevista y construye una eval en tu repo. Busca casos en transcripciones de producción, tickets, ejemplos tuyos o datos sintéticos, elige un corrector, lo valida contigo y lanza una versión base con intervalos de confianza.

¿Qué hace /claude-api hillclimb? ¶

Itera sobre una eval existente para mejorar tu sistema hacia un objetivo (rendimiento, o coste sin perder rendimiento). En cada ronda propone un solo cambio, ejecuta la eval y solo lo conserva si mejoran a la vez la nota de entrenamiento y la de test.

¿Qué significa hillclimbing en IA? ¶

Es un método de optimización por pasos pequeños: haces un cambio, mides y te quedas con él solo si la nota mejora. En aplicaciones con LLM se usa sobre prompts, skills, descripciones de herramientas, modelo y effort, porque son baratos de cambiar y de revertir.

¿Cómo evito el sobreajuste a mi eval? ¶

Divide los casos en entrenamiento y test, y que el optimizador no vea nunca el test. No pegues el contenido de los fallos en el prompt y asegúrate de que el modelo no pueda acceder a las respuestas. Si entrenamiento sube y test no se mueve, revierte el cambio.

¿Cuándo uso un LLM como juez y cuándo un corrector por código? ¶

Usa código cuando la salida está acotada: etiquetas de un conjunto cerrado, JSON con esquema, coincidencia exacta o tests. Usa un LLM como juez cuando la salida es abierta pero el criterio de calidad está claro, con una rúbrica de afirmaciones comprobables y un modelo juez distinto al evaluado.

¿Por qué no debo llenar mi eval con los casos que el modelo falla hoy? ¶

Porque la capacidad del modelo es dentada y estarías midiendo sus valles, no lo que es difícil para tu aplicación. Cuando salga el siguiente modelo, esos fallos pueden desaparecer y la eval dejará de informarte. Elige casos que una persona juzgue difíciles por un motivo que pueda explicar.

¿Qué hago si mi eval ya saca un 95%? ¶

La skill build-eval te avisa en ese caso porque queda poco margen para medir mejoras. La recomendación es cambiar el objetivo a coste o latencia, pidiendo a Claude que abarate el sistema manteniendo la nota.

¿Cuánto se ahorró Anthropic en su caso de atención al cliente? ¶

Según el artículo, el coste por ticket pasó de 4,6 céntimos con Opus 4.8 a alrededor de 1 céntimo con Sonnet 5 y effort bajo, más o menos una quinta parte. En los 14 tickets reservados, la precisión subió del 78,6% al 90,5%.

¿Estas cifras están verificadas por terceros? ¶

No. Son resultados internos que publica Anthropic en su propio blog, sobre sus propios modelos y su propia skill, sin reproducción independiente conocida. Además, algunas figuras del artículo están marcadas como ilustrativas. Tómalas como orientación y mide en tu proyecto.

TL;DR ¶

• 🎯 Una eval útil se parece a producción, sube con modelos más capaces, deja margen real y da notas estables entre ejecuciones.
• 🧪 /claude-api build-eval te entrevista, monta la eval en tu repo, valida el corrector contigo y te da una base con intervalos de confianza.
• 🧗 /claude-api hillclimb hace un cambio por ronda y solo lo conserva si suben a la vez entrenamiento y test.
• 💸 En el caso de soporte de Anthropic: del 78,6% al 90,5% en tickets nunca vistos, con el coste por ticket reducido a una quinta parte.
• 🛡️ Si la mejora cae dentro del ruido, la propia herramienta te recomienda no hacer merge.

Fuentes ¶

• Automating eval design and hillclimbing with Claude — Lance Martin, blog de claude.dev, 28 de septiembre de 2026
• Anuncio de ClaudeDevs en X
• Claude Code build-eval y hillclimb: versión requerida — vibecoding.tech

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter