Cómo dar a tu agente de programación con IA un bucle de retroalimentación que detecte sus propios errores

Cuando un agente de programación con IA escribe código que parece correcto pero rompe algo en silencio, el problema normalmente no es el modelo: es que el agente nunca vio el fallo. Escribió el cambio, cantó victoria y siguió adelante, porque nada le dijo que la suite de tests ahora estaba en rojo. La solución es cerrar el bucle: hacer que las propias herramientas del agente le reporten de vuelta automáticamente.

Esta guía muestra cómo construir ese bucle de retroalimentación para que tu agente detecte sus errores antes que tú.

La idea central: los errores deben volver al contexto

Un flujo de trabajo de agente fiable tiene cuatro tiempos: explorar, planificar, construir, verificar. La mayoría de la gente se detiene en "construir". El paso de verificación es lo que separa a un agente que produce código que funciona de uno que produce código que parece plausible.

Verificar significa ejecutar comprobaciones reales tras cada cambio —tu ejecutor de tests, tu linter y tu verificador de tipos— y devolver la salida al agente. Cuando una comprobación falla, el mensaje de error aterriza en el contexto del agente, y el modelo lo trata como cualquier otra instrucción: lee el fallo y lo corrige. Sin un humano en el bucle para las idas y venidas aburridas.

Puedes hacerlo de dos maneras: pedirlo en las instrucciones de tu proyecto, o automatizarlo para que no se pueda saltar.

Opción 1: Simplemente pídelo, en la configuración de tu proyecto

La versión que menos esfuerzo requiere es una línea en tu CLAUDE.md o AGENTS.md (el archivo de instrucciones en texto plano que la mayoría de los agentes leen al arrancar):

## Verification
After any code change, run `npm run typecheck && npm test`.
If either fails, fix the cause and re-run before reporting done.

Esto funciona sorprendentemente bien, pero es solo orientativo. Un agente ocupado puede olvidarlo, o decidir que un cambio es "demasiado pequeño" para verificarlo. Para cualquier cosa que te importe, haz que la verificación sea determinista.

Opción 2: Automatízalo con un hook

Los hooks de Claude Code te permiten ejecutar un comando de shell en respuesta a eventos del ciclo de vida, independientemente de si el modelo recuerda hacerlo. El relevante aquí es PostToolUse, que se dispara después de que el agente edita un archivo. Como lo expresa una guía práctica sobre hooks, PostToolUse está pensado para reacciones —formatear, registrar, ejecutar tests— y su salida se inyecta de vuelta en el contexto del agente para influir en su siguiente paso.

Aquí tienes un hook mínimo que ejecuta tu verificador de tipos tras cualquier edición de archivo y devuelve los fallos al agente. En .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run typecheck"
          }
        ]
      }
    ]
  }
}

Ahora el ciclo es automático: el agente escribe código → el hook ejecuta tsc → si hay un error de tipos, el mensaje vuelve como contexto → el agente lo corrige → el hook se ejecuta de nuevo. La referencia de hooks documenta cómo el código de salida distinto de cero y la salida se le presentan al modelo. Este bucle se ejecuta en cada escritura, sin necesidad de pedirlo.

Mantén el bucle rápido y acotado

Un bucle de retroalimentación solo ayuda si es rápido. Algunas reglas prácticas:

• Ejecuta las comprobaciones baratas en cada edición y las costosas con menos frecuencia. Un verificador de tipos o un linter sobre el archivo modificado es rápido. Una suite de integración completa no lo es; somete eso a un hook Stop (cuando el agente termina un turno) o a un comando manual, no a cada pulsación de tecla.
• Acota a lo que cambió. Ejecutar toda tu suite de tests tras un retoque de una línea de CSS desperdicia tiempo e inunda el contexto. Donde tu herramienta lo permita, apunta a los archivos afectados.
• Haz que los fallos sean legibles. El agente solo corrige lo que puede leer. Los linters y verificadores de tipos con mensajes de error claros y localizados (file:line: message) le dan al modelo exactamente lo que necesita; un genérico "build failed" no.

Un antes y un después concreto

Sin un bucle: le pides al agente que renombre una función. Actualiza tres puntos de llamada, se le escapa un cuarto en un archivo que no abrió, e informa de que ha terminado. Descubres el import roto en tiempo de ejecución una hora más tarde.

Con el bucle: el mismo renombrado dispara typecheck al guardar. tsc informa Cannot find name 'oldFn' en el punto de llamada que se escapó. Ese error aterriza en el contexto, el agente abre el cuarto archivo, corrige la referencia y la siguiente comprobación pasa, todo antes de decirte que ha terminado.

La conclusión

Los agentes de IA son buenos produciendo código y malos notando cuándo está mal. Cierras esa brecha dándoles la misma señal en la que tú te apoyas: un test en rojo, un error de tipos, una regla de lint que falla, entregada automáticamente, justo después del cambio. Empieza con una línea en las instrucciones de tu proyecto y luego promueve tu comprobación más importante a un hook para que se ejecute recuerde o no el modelo. Los agentes que parecen "inteligentes" suelen ser simplemente los que están conectados a un bucle de retroalimentación estrecho.