INTER-20 — Loop Engineering y Reverse Goal Discovery: una homología parcial, no una equivalencia

Autor conceptual: Claude (Anthropic). Originador y director: Javi Ciborro. 

Nota de marco previa: este documento describe una homología estructural entre una práctica de la industria (loop engineering, tal como la ha popularizado Boris Cherny en Anthropic) y un componente ya existente de la Biblioteca de IA Aplicada al Negocio (Reverse Goal Discovery, RGD). No es un mecanismo causal demostrado ni una validación externa del marco RGD — es una lectura comparativa entre dos formulaciones que comparten estructura en un punto concreto y difieren en otro que conviene no diluir. 

La cita y lo que dice literalmente

Durante 2026 circuló ampliamente una declaración de Boris Cherny, responsable de Claude Code en Anthropic: ya no escribe prompts individuales, construye sistemas — bucles — que generan sus propios prompts de seguimiento, actúan, evalúan el resultado y deciden el paso siguiente sin intervención humana en cada turno. La práctica se ha bautizado en la comunidad como loop engineering.

Descrita así, la idea central es sencilla: sustituir el ciclo manual (escribir prompt → leer resultado → escribir el siguiente prompt) por un sistema que ejecuta ese ciclo de forma autónoma, dentro de un marco que el ingeniero diseña de antemano — qué herramientas tiene disponibles el agente, qué cuenta como "hecho" y cuándo debe detenerse.

Dónde coincide con RGD

RGD ya distingue, en su capítulo 3, cuatro niveles de autonomía en orden creciente de delegación, desde la consulta asistida (nivel 1, cada paso requiere decisión humana explícita) hasta la ejecución autónoma con revisión posterior (nivel 4, el sistema completa el ciclo entero sin pausas intermedias y la supervisión ocurre después, sobre el resultado ya producido).

Lo que Cherny describe públicamente encaja, en su forma más básica, en ese nivel 4: un sistema que ejecuta el ciclo completo — recoger contexto, actuar, verificar, repetir — sin que un humano intervenga turno a turno. La Parte VI de RGD, dedicada a automatización y a la delegación cognitiva multinivel, ya contemplaba esta clase de arquitectura: un supervisor que distribuye subtareas entre especialistas, con validación intermedia y validación humana en puntos distintos de la cadena, no en cada paso.

En ese sentido estricto, loop engineering no introduce un concepto ausente en RGD. Es una instancia concreta, del dominio de la ingeniería de software, de algo que RGD ya había nombrado en términos generales antes de que el término loop engineering existiera como etiqueta.

Dónde no coincide, y por qué importa mantener la distinción

RGD toma su nombre del principio que lo organiza de punta a punta: preguntar antes de resolver, validar el objetivo reconstruido antes de comprometerse a un plan (capítulo 4), hacer visible esa reconstrucción para que la supervisión humana pueda revisarla y no solo el resultado final (capítulo 29). Ese principio es, explícitamente, anterior a la ejecución — el punto donde el sistema se detiene a confirmar qué problema está resolviendo.

Loop engineering, tal como se describe en las fuentes disponibles, optimiza el extremo opuesto de esa misma escala: una vez que el objetivo y el marco de actuación quedan fijados en el diseño del bucle, la validación desaparece de los pasos intermedios por diseño, no por descuido. No hay ningún indicio, en el material público sobre esta práctica, de un paso de descubrimiento de objetivo equivalente al que describe RGD en sus capítulos 1 a 4 — el bucle ejecuta lo que su diseñador definió al construirlo, sin cuestionar ese objetivo dentro de la propia ejecución.

Esto no convierte loop engineering en un antipatrón de RGD — el propio marco contempla el nivel 4 como legítimo cuando el coste de revertir un error es bajo (capítulo 3, nota de marco) —, pero sí significa que ambas prácticas resuelven partes distintas del mismo problema. RGD se ocupa principalmente de cómo llegar a un objetivo bien definido antes de actuar; loop engineering se ocupa de cómo ejecutar de forma eficiente un objetivo que ya se dio por bien definido en el momento de construir el bucle. Tratarlas como intercambiables perdería justamente el matiz que hace útil a cada una por separado.

Lo que no está verificado

Varias cifras que circulan junto a esta cita — mejoras de productividad de varios múltiplos, porcentajes concretos de código o revisiones gestionadas por el sistema — provienen de blogs y agregadores de terceros que reproducen la declaración original sin remitir a un dato de origen contrastable ni a un benchmark reproducible. Ninguna fuente primaria de Anthropic con esas cifras acompaña, en el material disponible, la declaración de Cherny. Siguiendo la norma INTER-8 de este corpus, esas cifras se excluyen de esta nota: no se citan como hecho porque no están en condición de serlo.

Hipótesis y condición de falsabilidad

H1. La transición de un sistema de RGD de nivel 1-2 (consulta o planificación supervisada) a nivel 4 (ejecución autónoma) sin mantener un registro explícito y auditable del objetivo reconstruido — el mismo requisito que el capítulo 29 de RGD exige como buena práctica — produce una tasa de deriva de objetivo (el plan ejecutado deja de corresponder al objetivo real validado al inicio) medible y superior a la de un sistema equivalente que conserva ese registro en cada iteración del bucle.

Condición de falsabilidad: comparar, sobre un conjunto de tareas de complejidad similar, la tasa de corrección post-hoc necesaria en bucles con registro de objetivo trazable frente a bucles sin ese registro. Si ambas tasas resultan estadísticamente indistinguibles, H1 queda refutada.

Programa de seguimiento

No se propone aquí una línea de investigación futura genérica. El seguimiento concreto es: registrar, en los propios flujos de trabajo del corpus que usan agentes con memoria persistente (APT-IA, OPEN-CAREER-COACH), la frecuencia con que un bucle de ejecución autónoma se aparta del objetivo validado al inicio de la tarea, frente a la frecuencia equivalente en flujos con validación intermedia explícita. Es un dato obtenible con el propio historial de esos proyectos, no una promesa de estudio futuro. 

Resumen

• Loop engineering (Cherny, Anthropic) y el nivel 4 de autonomía de RGD comparten estructura: ejecución de un ciclo completo sin intervención humana turno a turno.
• La diferencia relevante no está en la ejecución, sino en si existe un paso previo de descubrimiento y validación del objetivo — RGD lo exige explícitamente; loop engineering, tal como se describe públicamente, lo asume ya resuelto al construir el bucle.
• Las cifras de productividad asociadas a la cita circulan sin fuente primaria verificable y se excluyen de esta nota por norma INTER-8.
• H1 (deriva de objetivo en ausencia de registro trazable) queda formulada con condición de falsabilidad explícita, pendiente de contraste con datos propios del corpus.