Cómo hacer fiable un agente de IA: plan paso a paso, de la medición al trabajo autónomo

Por qué un agente no es fiable aunque el modelo sea potente

La fiabilidad de un agente es una propiedad de todo el sistema, no solo del modelo. Una tarea larga consta de decenas de pasos, y los errores se acumulan: con un 95 % de pasos correctos, alrededor del 60 % de las ejecuciones superan una cadena de diez sin un solo error (0.95^10 ≈ 0.60), y menos del 10 % superan una de cincuenta. No puede aumentar la precisión del modelo, pero sí puede atrapar un error en el mismo paso y hacer que sea barato. Eso es lo que hace el harness: instrucciones, herramientas, entorno, estado y retroalimentación alrededor del modelo.

A continuación, un plan que lleva del trabajo «a ojo» a una fiabilidad medible y, después, al trabajo autónomo. Los pasos siguen el orden de su rendimiento: cada uno se apoya en el anterior.

Paso 1. Deje de evaluar a ojo

Un ingeniero está convencido de que un nuevo prompt lo cambió todo, otro no ve diferencia, y nadie ha medido nada. Empiece con un registro de fallos: cada vez que el agente se atasca, rompe algo o informa de una funcionalidad defectuosa como terminada, anote una línea.

| fecha | tarea            | qué pasó                       | subsistema     |
|-------|------------------|--------------------------------|----------------|
| 10.10 | descuentos carrito | «listo», no ejecutó el e2e   | retroalimentación |
| 10.10 | webhook de pagos | no pudo levantar la base       | entorno        |
| 11.10 | refactor de API  | repitió una solución descartada | estado        |

La columna «subsistema» es la clave. Al cabo de una semana se ve dónde está el cuello de botella, y se repara ese en lugar de todo a la vez. Medir la fiabilidad por las ejecuciones exitosas es un error: es el registro de caídas el que muestra dónde falla el agente.

Paso 2. Introduzca dos métricas: MTBF y MTTR

La fiabilidad son dos números. El MTBF (tiempo medio entre fallos) de un agente es cuántos pasos supera antes de atascarse. El MTTR (tiempo medio de recuperación) es cuánto tarda en volver a un estado de trabajo tras una caída. La disponibilidad crece si aumenta el primero o disminuye el segundo.

Perseguir a un agente que nunca se equivoca es una carrera sin fin. Reducir el MTTR suele lograrse en un día. Por eso empiece por el segundo número.

Paso 3. Haga que los errores sean baratos

La autonomía es admisible no cuando el agente ha dejado de equivocarse, sino cuando el coste de un error ha bajado casi a cero. Para ello hacen falta tres cosas:

• Commits pequeños y limpios — cualquier cambio se revierte con un solo comando.
• Aislamiento — el agente trabaja en una rama o copia de trabajo propia, por ejemplo mediante git worktree, y en un entorno aislado sin acceso a producción.
• Un script de reinicio del entorno — la base de datos, las dependencias y los servicios vuelven al estado inicial con un solo comando.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # recrear la base de datos, aplicar migraciones, cargar fixtures

Mida con un cronómetro cuánto tarda la vuelta completa a un estado de trabajo. Ese es su MTTR. Además, limite el radio de daño: un tope para el tamaño del diff de una tarea y la prohibición de editar archivos fuera de su alcance.

Paso 4. Cierre el bucle de retroalimentación

Sin comprobaciones, el agente es su único juez y considera el trabajo terminado con total sinceridad. Déle comandos con los que pueda comprobarse a sí mismo, y hágalos obligatorios.

• Fail-fast: una comprobación falla al primer error con un mensaje claro, en lugar de imprimir cien líneas de ruido.
• Comprobaciones rápidas tras cada cambio: linter y comprobación de tipos mediante un hook del agente.
• Redundancia: una segunda comprobación independiente de la misma propiedad: un escenario E2E sobre las pruebas unitarias. Las pruebas unitarias en verde no demuestran que la funcionalidad funcione para el usuario.

Escriba el criterio de «listo» como una condición verificable: «el escenario E2E de compra con código promocional pasa», no «descuento implementado».

Paso 5. Traslade la memoria a archivos

El agente no recuerda la sesión anterior. Todo lo necesario para continuar debe vivir en el repositorio: el objetivo, lo hecho y cómo se comprobó, las decisiones con su motivo, los callejones sin salida y el siguiente paso. Una buena señal: una sesión nueva que recibe solo el repositorio y la palabra «continúa» se pone de inmediato a trabajar de forma útil.

Un historial de conversación largo y comprimido da sensación de continuidad, pero pierde lo más valioso: los motivos de las decisiones descartadas. Reiniciar la sesión de forma deliberada, con un estado escrito completo, suele salir más barato.

Paso 6. Una tarea cada vez

Ley de Little: el número de tareas en curso es igual a la tasa de llegada multiplicada por el tiempo que una tarea permanece en el sistema. Con un rendimiento fijo, las tareas en paralelo no aceleran el trabajo, solo alargan cada una. Para un agente es aún más estricto: tres funcionalidades son tres modelos de dominio en la misma ventana de contexto.

• Mantenga WIP=1: una funcionalidad hasta tener un resultado verificado.
• Corte las tareas a su tamaño: una capacidad verificable para el usuario, 1 a 3 archivos, una comprobación que tarde menos de un minuto.
• Cree un BACKLOG.md — una válvula para lo de «ya que estamos». Si el agente ve un defecto cercano, añade una línea al backlog en lugar de editarlo por su cuenta.

Paso 7. Separe al ejecutor del verificador

La autoevaluación del agente es un freno débil: la misma sesión que escribió el código tiende a considerarlo correcto. Deje que el resultado lo evalúe un subagente o una sesión aparte que reciba solo el requisito, el diff y los resultados de las comprobaciones, sin el razonamiento del ejecutor. El veredicto del verificador se apoya en comprobaciones automáticas, no en «parece bien».

Paso 8. Deje al agente trabajar en un ciclo autónomo

El harness hace fiable una sola ejecución; el ciclo hace autónoma una serie de ejecuciones. Un ciclo montado sobre un harness deficiente solo multiplica los errores más deprisa, así que este paso va el último. El ciclo más simple se describe en tres líneas:

Objetivo:    el escenario E2E de pago con código promocional pasa
Comprobación: make lint && make test && make e2e
Parada:      objetivo alcanzado O 15 intentos O 2 horas → avisar a una persona

Elija el tipo de ciclo según la tarea. Si el trabajo tiene una meta, necesita un ciclo orientado a objetivo: memoria del progreso, un verificador independiente y un presupuesto de pasos. Si no tiene fin (la comprobación de CI de cada mañana, la revisión de errores nuevos), sirve un ciclo programado. Un error frecuente es programar una tarea que sí tiene fin: cada ejecución la empieza de cero.

Reglas de autonomía segura

• La condición de parada debe ser solo verificable por máquina, con un límite de intentos y de presupuesto.
• Escalado: enumere de antemano lo que no se le confía al ciclo (migraciones de producción, dinero, borrado de datos).
• Si una tarea se atasca y el progreso no crece de verdad, es señal de pasársela a una persona, no de seguir girando.
• Lea los diffs. La velocidad del ciclo no debe superar su velocidad de lectura, o dejará de entender su propia base de código.

Errores frecuentes en este camino

Empezar reescribiendo las instrucciones

La respuesta más popular a un fallo del agente es añadir una regla a AGENTS.md. Unos meses después el archivo tiene cientos de líneas y las reglas importantes se pierden. Si el registro de fallos muestra que el agente no ejecutó las comprobaciones, lo que hay que arreglar es la retroalimentación: un comando de comprobación y un hook, no un párrafo más de texto.

Arreglar todo a la vez

Se quiere mejorar los cinco subsistemas del harness al mismo tiempo. Pero entonces no se sabe qué ayudó de verdad. Valore cada subsistema de 1 a 5, dedique media hora al más débil y ejecute el mismo conjunto de cinco tareas típicas antes y después. La diferencia en el registro de fallos mostrará si hubo efecto.

Confundir «las pruebas están en verde» con «la funcionalidad funciona»

El agente puede escribir una prueba que compruebe su propia implementación en lugar del requisito. Esa prueba siempre está en verde. La protección es una comprobación a nivel de usuario (un escenario E2E), escrita antes de la implementación o por un verificador independiente, y la regla de que el agente no modifique una prueba para que pase.

Desactivar comprobaciones para ganar velocidad

Las comprobaciones lentas tientan a saltárselas «esta vez». Es mejor separarlas: linter y comprobación de tipos rápidos tras cada cambio, y el conjunto completo de pruebas y E2E antes de escribir «listo». Así el bucle de retroalimentación sigue siendo corto y no estorba.

Tomar la ablación como primer paso

Se pueden desactivar los subsistemas del harness uno a uno y ver cuánto baja la calidad. Es una comprobación útil, pero costosa y no la primera: primero el registro de fallos señala el cuello de botella, y la ablación solo confirma la hipótesis. Una caída nula al quitar un componente no demuestra que sea inútil: quizá el conjunto de tareas elegido no lo necesitó.

La escalera de madurez

Resumen

Para hacer fiable a un agente de IA: medir, encontrar el subsistema débil con el registro de fallos, hacer baratos los errores, cerrar el bucle de retroalimentación, trasladar la memoria a archivos, mantener una tarea cada vez y separar al ejecutor del verificador. Solo entonces un ciclo autónomo con condición de parada verificable por máquina se vuelve seguro. Cada paso de este plan se trabaja en la práctica en el curso de harness engineering.