Un test fallido debe cambiar el siguiente paso
Imagina un agente que corrige el filtro de fechas de una aplicación web. El encargo dice que seleccionar el 12 de octubre debe incluir los registros de todo ese día. Su primera modificación excluye los posteriores a medianoche. Si el agente solo relee su propia explicación, puede anunciar que ha terminado con total seguridad mientras el fallo sigue ahí.
Con una herramienta para ejecutar tests, la siguiente decisión puede apoyarse en una prueba concreta: falta un registro de la tarde. El agente revisa el cálculo del intervalo, propone otra modificación y vuelve a comprobarlo. Ese es el ciclo de ejecución: actuar, observar el resultado y decidir cómo seguir. La guía básica de Anthropic sobre agentes describe este uso de la información del entorno. [L1]
En este ejemplo hipotético, conviene definir el resultado esperado antes de editar: la fecha seleccionada incluye los registros correctos, las fechas contiguas quedan fuera y los tests existentes siguen pasando. De lo contrario, el agente puede dedicar varios intentos a resolver el problema equivocado.
Lo que hace útil un nuevo intento es la evidencia que cambia el siguiente paso.
Destacado editorial · Frase editorial original, sin atribución a terceros.
Deja un registro útil para el siguiente intento
El ciclo necesita un estado: comportamiento solicitado, versión actual del código, archivos modificados, comprobación que falló, intentos disponibles y preguntas pendientes. Una sesión posterior también debe saber a qué versión pertenece cada resultado. Un test aprobado sobre código antiguo puede dar una falsa seguridad sobre un cambio más reciente.
La memoria es la información conservada para decisiones posteriores. Aquí, una nota breve podría guardar la suposición errónea sobre medianoche y enlazar el resultado del test. Guardar ese registro no actualiza los pesos del modelo. Cambia la información disponible para la siguiente ejecución.
Mantén los requisitos del usuario separados de las notas de trabajo del agente. Un ejemplo reciente de automatización de Anthropic separa las preferencias fijas del estado modificable y advierte de que el contenido no fiable puede contaminar la memoria. [L4]
El grafo define los caminos
Al dibujar este proceso como un grafo, cada nodo representa un paso: inspeccionar, editar, probar o solicitar una revisión. Las conexiones indican las rutas posibles. Un test fallido puede devolver el proceso a la edición; un requisito confuso puede llevarlo a una persona; agotar los intentos puede detener la ejecución.
El grafo hace explícitas esas transiciones. Por sí solo, no enseña al agente una estrategia mejor para corregir el código. Repetir una ruta puede reproducir el mismo error. Mejorar exige información útil, una decisión distinta y una comprobación de que el cambio ayudó. Los prompts y las instrucciones de las herramientas siguen influyendo en esas decisiones.
Separa la ejecución del veredicto
En el ejemplo del filtro de fechas, deja los tests de aceptación fuera de los permisos de escritura del agente que modifica el código. Un ejecutor separado comprueba la versión propuesta y registra lo que ocurrió. Antes de editar, pide a una persona que aclare requisitos ambiguos, como la zona horaria que define el día seleccionado.
Un modelo puede ayudar en esa revisión, pero un segundo agente puede compartir los puntos ciegos del primero. La investigación de Anthropic sobre entornos de ejecución encontró ventajas al separar generación y evaluación, aunque reconoce que los evaluadores pueden seguir puntuando con demasiada generosidad. [L2]
Establece un límite concreto: un intento inicial y, como máximo, dos intentos adicionales, con un presupuesto fijo de tiempo y gasto. Detén el proceso antes si el requisito no está claro. Al llegar al límite, devuelve la modificación, las pruebas y el fallo pendiente. En este ejemplo, una persona aprueba la integración o el despliegue del código, aunque los tests pasen.
Mide la mejora más allá de una ejecución
Un ejemplo corregido solo demuestra ese resultado. Para evaluar el sistema, compáralo con una solución más sencilla en tareas representativas, incluidos casos excluidos del proceso de ajuste. La guía de evaluación de Anthropic recomienda casos reservados y cambios controlados para detectar el sobreajuste a los tests y las regresiones. [L3]
Registra las tareas completadas correctamente, las falsas declaraciones de éxito, la intervención humana y el coste por tarea completada, contando también los intentos fallidos. Examina las ejecuciones lentas además del tiempo medio. Mantén condiciones comparables y conserva los registros de los fallos. Dar más autonomía debe depender de esas pruebas; acumular iteraciones, por sí solo, no demuestra una mejora.
Fuentes y referencias
- Building effective agents
- Harness design for long-running application development
- Automating eval design and hillclimbing with Claude
- Building effective agent automations
- Lamis Mukta — Learning while you sleep: Beyond memory to dreaming — AI Native DevCon June 2026
¿Tienes otro punto de vista? Quiero escucharlo. hello@maisfps.com
