> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2026/w29-the-boundary-between-loop-engineering-and-rsi.md).

# W29-La frontera entre Loop Engineering y RSI

Últimamente se habla mucho de Loop Engineering y de RSI. A primera vista se parecen: ambos introducen a la IA en un ciclo de proponer, ejecutar, verificar, registrar y volver a empezar.

La similitud está en la forma; la diferencia, en aquello que modifican.

**Loop Engineering entrega el trabajo a un ciclo. RSI entrega también al ciclo la capacidad de mejorar el propio mecanismo de mejora.**

**El primero optimiza principalmente el sistema de ejecución. El segundo empieza a intervenir en el sistema que genera capacidades. Esa es la frontera más importante.**

### Loop Engineering es, en esencia, diseño del entorno de ejecución

Hasta hace poco, usábamos la IA sobre todo en modo conversación. Una persona planteaba una pregunta y la IA devolvía una respuesta. Si el resultado no era bueno, la persona añadía contexto, cambiaba el prompt y volvía a pedirlo.

La operación central seguía siendo que una persona diera indicaciones continuas a la IA. La IA era la herramienta y la persona estaba al volante.

Loop Engineering eleva esa relación un nivel. La persona diseña un pequeño sistema capaz de decidir por sí mismo cuál debe ser el siguiente prompt.

Un ciclo típico necesita al menos varios elementos.

Primero, una condición de activación: una tarea programada, un fallo de CI, una incidencia que entra en una cola o un objetivo que todavía no se ha alcanzado.

Segundo, estado. El agente no puede empezar de cero cada vez. Necesita recordar qué intentó, dónde falló y qué caminos ya descartó.

Tercero, herramientas. Debe poder leer código, modificar archivos, ejecutar pruebas, consultar registros y presentar un diff.

Cuarto, un verificador. Pruebas, lint, compilación, benchmarks o un evaluador externo: algo debe poder rechazar los resultados malos.

Quinto, condiciones de parada. El presupuesto, el número de rondas, el tiempo y las aprobaciones humanas tienen que estar definidos.

Por eso Loop Engineering se parece al diseño de un entorno de ejecución: cómo entra el contexto, cómo se llaman las herramientas, cómo se verifican los resultados, cómo se conserva el estado y cómo se delimitan los permisos.

También explica por qué se dice que la capacidad de intervención del ingeniero se ha desplazado del prompt al ciclo. Lo valioso es un flujo de trabajo repetible, verificable y reversible.

### RSI actúa un nivel más profundo

RSI, Recursive Self-Improvement o automejora recursiva, plantea una cuestión de otro nivel.

En Harness Engineering for Self-Improvement, Lilian Weng remonta su definición tradicional a I. J. Good y Yudkowsky: un sistema utiliza la inteligencia que ya tiene para mejorar el mecanismo que produce inteligencia. En el contexto actual, ese mecanismo no tiene por qué limitarse a los pesos del modelo. Puede incluir el proceso de entrenamiento, la generación de datos, los sistemas de evaluación, el harness de despliegue y el proceso de investigación.

Anthropic usa un marco parecido en When AI builds itself. La IA ya acelera el trabajo de ingeniería e investigación de las empresas de modelos; si se avanza por ese camino, podría participar en el diseño y el entrenamiento de sus sucesores. Anthropic también aclara que la RSI completa todavía no ha ocurrido ni tiene por qué ocurrir necesariamente.

Lo decisivo es qué modifica el ciclo.

Si un agente corrige lint, actualiza dependencias y resuelve fallos sencillos de CI cada día, está automatizando trabajo.

Si puede cambiar su propio flujo para resolver mejor los fallos de CI en la siguiente ronda, empieza a formar parte de un harness que se mejora a sí mismo.

Si esa mejora alcanza el entrenamiento de modelos, las decisiones de investigación, la búsqueda de experimentos y la generación de datos, produce una siguiente generación más capaz y esa generación vuelve a mejorar la posterior, entonces nos acercamos al núcleo de RSI.

Yo situaría aquí la frontera:

**Loop Engineering se ocupa de la capacidad de procesar tareas. RSI se ocupa del aumento de capacidades.**

**Los beneficios de Loop Engineering suelen ser locales: corregir errores más deprisa, ejecutar experimentos antes y reducir la supervisión humana del proceso.**

Los riesgos y beneficios de RSI tienen un efecto compuesto: el sistema mejora el mecanismo que producirá mejoras futuras, y tanto la velocidad como el alcance pueden amplificarse.

### AutoResearch ocupa una posición intermedia

AutoResearch permite observar bien esa frontera.

El repositorio autoresearch de Karpathy tiene un diseño muy limpio. Ofrece al agente un entorno pequeño pero real de entrenamiento de un LLM; le permite modificar `train.py`; fija cada entrenamiento en cinco minutos; usa `val_bpb` como métrica; y conserva o revierte los cambios según mejoren o empeoren el resultado. La persona modifica principalmente `program.md`, es decir, la organización de la investigación y los límites de las instrucciones.

Por su forma, es un caso de Loop Engineering: objetivo claro, respuesta rápida, métrica objetiva, estado registrable y código reversible. El agente completa todo el ciclo: formula una hipótesis, cambia el código, ejecuta el experimento, observa la métrica, escribe el registro y pasa a la siguiente ronda.

Pero se acerca más a RSI que un ciclo de ingeniería corriente, porque optimiza la receta de entrenamiento del modelo. Ya está junto a la cadena de producción de capacidades de IA.

First Steps Toward Automated AI Research, publicado por Recursive en junio de 2026, profundiza en esa dirección. Su sistema investiga de forma automática en tres tareas: NanoChat Autoresearch, NanoGPT Speedrun y SOL-ExecBench. Propone ideas, las implementa, ejecuta experimentos, verifica resultados y elige la siguiente prueba. Los benchmarks comparten varios rasgos: objetivos claros, respuesta rápida, varianza baja y evaluadores relativamente fáciles de reforzar.

Esto indica que hoy la investigación automática encaja mejor en espacios de investigación medibles y abordables mediante ingeniería: entrenar con un presupuesto fijo, acelerar modelos pequeños u optimizar kernels de GPU. Todos ofrecen una recompensa definida y permiten registrar los fallos.

Más interesante aún es Bilevel Autoresearch. Añade un ciclo externo que modifica el mecanismo de búsqueda del interno, en vez de limitarse a cambiar el código de entrenamiento. El artículo afirma que, en el benchmark de preentrenamiento GPT de Karpathy, el meta-autoresearch externo obtuvo una mejora cinco veces mayor que el ciclo interno estándar.

Se supera así un escalón importante: el sistema busca respuestas y también busca cómo buscarlas.

Eso va más allá de Loop Engineering corriente, pero todavía no constituye RSI completa. La razón es sencilla: no cambia el modelo base, la persona sigue definiendo el objetivo, el evaluador permanece fuera y el espacio de búsqueda es estrecho. Muestra que empieza a funcionar la automejora de mecanismos; no demuestra que la IA ya pueda producir recursivamente una IA más potente.

### Por qué importa esta frontera

Confundir Loop Engineering y RSI conduce a dos errores.

El primero es subestimar Loop Engineering.

Algunos dirán que solo es un script de automatización. Esa descripción es demasiado limitada. Un script tradicional suele seguir un proceso fijo y falla ante una bifurcación no prevista. Loop Engineering sitúa al agente en un entorno controlado, donde puede probar repetidamente entre objetivos, herramientas, estado y verificadores.

Su efecto en la productividad de ingeniería es concreto. La clasificación de fallos de CI, las actualizaciones de dependencias, las correcciones de lint, la ampliación de pruebas, las actualizaciones de documentación, la limpieza de datos o el ajuste de benchmarks pueden pasar de una persona vigilando a la IA a una persona diseñando un sistema que funciona de manera continua.

El segundo error es sobreestimar RSI.

Que un agente cambie código en un ciclo no significa que la RSI ya haya ocurrido. La mayoría de esos ciclos automatizan la ejecución y, como mucho, mejoran localmente un harness. No han producido una verdadera acumulación recursiva de capacidades.

RSI exige condiciones más rigurosas: lo que se mejora debe influir en la generación futura de inteligencia; las nuevas capacidades deben transferirse a tareas más amplias; el evaluador no debe poder contaminarse fácilmente mediante reward hacking; el ciclo no debe poder eludir sus permisos ni sus límites de seguridad; y las personas deben conservar el juicio en el nivel de abstracción adecuado.

Las evidencias más sólidas siguen concentradas en ámbitos de respuesta rápida, métricas claras y experimentos repetibles. Cuanto más nos acercamos a la investigación abierta, el criterio de producto, la arquitectura de largo plazo o la colaboración organizativa, más débiles son los verificadores y más fácil es que el ciclo se convierta en un generador de ruido seguro de sí mismo.

### Una mirada económica: quien controla el evaluador controla la capacidad de mejora

Desde la economía, Loop Engineering y RSI modifican lo mismo: el coste de probar y equivocarse.

Antes era alto porque cada ronda exigía que una persona comprendiera, ejecutara, esperara y juzgara. La IA reduce ahora el coste de ejecución y el ciclo reduce el de organización. Si verificar es suficientemente barato, el sistema puede intercambiar más rondas de prueba por mejores resultados.

Eso también cambia qué resulta escaso.

La diferencia decisiva procede de la calidad del evaluador.

En ingeniería, el evaluador son las pruebas, el sistema de tipos, los registros de ejecución, las métricas de usuarios y los conjuntos de regresión.

En investigación de IA, son los benchmarks, la pérdida de entrenamiento, el coste de inferencia, el desempeño en tareas reales, la validación con datos reservados y los mecanismos contra las trampas.

En producto y organización, evaluar es todavía más escaso, porque muchos resultados no se pueden medir de inmediato. El coste de mantenimiento a largo plazo, la confianza del usuario, la salud de la arquitectura y el deterioro de una marca no se resuelven con un benchmark rápido.

Por eso el límite de un ciclo suele ser el límite de su evaluador.

Donde existen verificadores firmes, se puede automatizar con decisión. Donde solo hay juicios difíciles de formalizar, hay que conservar la intervención humana. Sin verificador, el ciclo solo fabrica errores más deprisa.

### Mi criterio

Ahora tiendo a entenderlo así.

Loop Engineering es una capacidad básica de la ingeniería de software en la era de la IA. Resuelve cómo introducir agentes en sistemas controlados para que trabajen de forma sostenida.

RSI trata de la recursión de capacidades en un nivel superior: si el sistema puede mejorar el mecanismo que genera inteligencia y lograr que esa mejora impulse la siguiente.

AutoResearch queda entre ambos. La versión de Karpathy se parece más a automatizar el flujo de investigación; el sistema de Recursive, a una primera forma industrial de investigación automática de IA; Bilevel Autoresearch empieza a explorar la mejora del propio mecanismo de mejora.

La frontera sigue siendo clara.

Cuando el ciclo cambia el resultado de una tarea, hablamos de Loop Engineering.

Cuando cambia el proceso para realizar la tarea, hablamos de un harness que se mejora a sí mismo.

Cuando cambia el mecanismo que genera la siguiente capacidad y las mejoras pueden acumularse recursivamente, se acerca a RSI.

Esta distinción evita dos extremos: rebajar una capacidad real de ingeniería a un simple script y confundir la automatización local con una explosión de inteligencia.

Loop Engineering ya produce resultados reales. RSI sigue siendo una frontera de capacidades a la que nos acercamos. Entre ambas, merecen especial atención los sistemas que integran ciclos, harnesses, evaluadores, permisos y criterio humano.

Quizá lo que los ingenieros necesiten aprender de verdad en los próximos años sea diseñar un ciclo que no pierda el control, no se engañe a sí mismo y acumule experiencia útil de forma estable.

### Referencias

* [karpathy/autoresearch](https://github.com/karpathy/autoresearch)
* [Loop Engineering: The Karpathy Method](https://x.com/0xCodila/article/2072329149520232639)
* [Loop engineering: the 14-step roadmap from prompter to loop designer](https://x.com/0xCodez/status/2064374643729773029)
* [Loop Engineering: The 14-Step Roadmap from Prompter to Loop Designer](https://medium.com/coinmonks/loop-engineering-the-14-step-roadmap-from-prompter-to-loop-designer-bda3edc46fbc)
* [First Steps Toward Automated AI Research — Recursive](https://www.recursive.com/articles/first-steps-toward-automated-ai-research)
* [When AI builds itself — Anthropic](https://www.anthropic.com/institute/recursive-self-improvement)
* [Harness Engineering for Self-Improvement — Lilian Weng](https://lilianweng.github.io/posts/2026-07-04-harness/)
* [Bilevel Autoresearch: Meta-Autoresearching Itself](https://arxiv.org/abs/2603.23420)
* [Auto Research with Specialist Agents Develops Effective and Non-Trivial Training Recipes](https://arxiv.org/abs/2605.05724)
