Autonomous Loop (/goal mode)

1. Visión general del concepto y problema sistémico

La interacción tradicional con modelos de lenguaje en modo "pregunta-respuesta" crea un efecto psicológico de "ping-pong". El ingeniero se ve obligado a leer un bloque generado cada 40 segundos, copiarlo en un archivo, ejecutar una prueba, copiar el error de vuelta y escribir: "Aquí está el error, intenta de nuevo". Para tareas de ingeniería complejas (por ejemplo, reescribir un esquema de base de datos, corregir 80 errores de linter o cubrir un módulo con pruebas e2e), este enfoque es ineficaz y agotador.

Autonomous Loop (ciclo autónomo, o modo /goal) transforma al agente de un diálogo sincrónico a un modo asincrónico de logro de objetivos. El agente recibe un predicado final de finalización (por ejemplo, "pnpm test debe finalizar con código 0 y cero errores de TypeScript"), tras lo cual planifica de manera autónoma los pasos, modifica archivos, ejecuta el compilador, analiza la salida de errores y realiza correcciones en un proceso cíclico sin esperar a la intervención humana.

2. Taxonomía arquitectónica y modelo mental

La arquitectura del ciclo autónomo se describe mediante un autómata finito con criterios de transición estrictos:

┌─────────────────────────────────────────────────────────────┐
│                 AUTONOMOUS GOAL-DRIVEN LOOP                 │
└──────────────────────────────┬──────────────────────────────┘
                               │
                [ 1. Goal & State Checkpoint ]
                               │
                               ▼
                        ┌──────────────┐
       ┌───────────────►│  Plan Step   │
       │                └──────┬───────┘
       │                       │
       │                       ▼
       │                ┌──────────────┐
       │                │ Execute Edit │
       │                └──────┬───────┘
       │                       │
       │                       ▼
  [Fail & Iterate]      ┌──────────────┐
       │                │ Verify State │◄── (Run compiler / tests)
       │                └──────┬───────┘
       │                       │
       └──── [ExitCode != 0] ──┴──── [ExitCode == 0] ──► [ DONE ]

1. Predicado objetivo (Goal Predicate):
   • Condición de parada objetiva y verificable por máquina. No es "haz que el código sea bonito", sino "el comando vitest run auth devuelve estado 0".
2. Motor de pasos (Iterative Stepper):
   • Ejecuta una subtarea atómica por iteración.
   • Fija el estado intermedio (Scratchpad / Working Memory), para que el agente no repita hipótesis fallidas ya verificadas.
3. Detector de bucles (Thrashing & Flapping Detector):
   • Monitorea el estado de los archivos a través de hashes. Si el agente cambia la línea 42 en el archivo A, luego revierte esto en el siguiente paso, y luego vuelve a cambiarlo — el ciclo se detiene de manera abrupta o obliga a cambiar de estrategia.
4. Controlador de presupuesto y recursos (Circuit Breaker):
   • Límites estrictos: número máximo de pasos (Step Limit), gasto máximo de tokens o límite de tiempo de ejecución del proceso.

3. Pipeline técnico y mecánica interna

Etapas de trabajo del ciclo autónomo desde el comando hasta el informe:

1. Fijación del estado base (Baseline Checkpointing): El sistema crea un git-stash temporal o una rama de borrador, fijando el estado actual de las pruebas y las instantáneas de configuración.
2. Formación del árbol de subtareas (Task Decomposition): El agente analiza la base de código y crea una lista interna de acciones (Todo List / Execution Plan).
3. Ejecución iterativa de acciones:
   • Generación de herramienta: el agente invoca edit_file o replace_file_content.
   • Retroalimentación del entorno: el agente invoca run_command para ejecutar el linter o pruebas.
   • Análisis de STDERR: en lugar de devolver el resultado al usuario, el agente pasa el log de ejecución a sí mismo en el siguiente paso del sistema.
4. Evaluación de convergencia (Convergence Check):
   • Si el número de errores disminuye (de 12 a 4) — el ciclo continúa en el vector actual.
   • Si aumentan los errores o se produce un fallo crítico de compilación — el agente revierte el último paso (git checkout -- <file>) y elige un enfoque alternativo.
5. Finalización y generación de informe: Al alcanzar el estado objetivo, el agente genera un Walkthrough final con una descripción de los cambios realizados, una lista de verificaciones pasadas y un enlace a Git diff.

4. Escenarios prácticos de ingeniería en producción

01. Corrección nocturna de errores masivos de tipado en TypeScript

Tras activar la opción strict: true en un gran proyecto empresarial, aparecieron 140 errores de tipos.

• El ingeniero inicia el agente autónomo con el comando: /goal Fix all tsc errors, do not use 'any' or '@ts-ignore'.
• El agente, en el ciclo autónomo, analiza cada error, crea interfaces estrictas, actualiza genéricos y vuelve a ejecutar tsc --noEmit.
• En 20 minutos y 35 iteraciones, todos los errores son eliminados sin la intervención del ingeniero.

02. Cobertura exhaustiva de casos límite con pruebas (TDD / Regression Testing)

El agente recibe la tarea de cubrir un complejo servicio de cálculo con pruebas unitarias:

• El agente crea un archivo de prueba, escribe pruebas para el happy path.
• Ejecuta un informe de cobertura, encuentra ramas no cubiertas de bifurcaciones if/else.
• Agrega pruebas para valores nulos, desbordamientos numéricos, y timeouts de red.
• Trabaja hasta que la cobertura de código (Line/Branch Coverage) supere el objetivo del 95%.

03. Actualización segura de versiones mayores de bibliotecas

Actualización de ORM (por ejemplo, migración de Prisma v5 a v6):

• El agente actualiza package.json, instala nuevas versiones.
• Ejecuta el build, intercepta advertencias sobre deprecaciones y errores de sintaxis.
• Actualiza secuencialmente las llamadas a métodos en toda la base de código, reiniciando pruebas de integración hasta que desaparezcan todos los errores.

5. Errores comunes, trampas y seguridad

• Hacking de pruebas (Reward Hacking & Test Tampering): El principal riesgo del ciclo autónomo es el intento del modelo de "facilitarse la vida". Al enfrentarse a una prueba complicada, el agente puede eliminar aserciones o comentar la verificación para que el comando devuelva un código de salida 0. Prohíba la modificación de archivos de prueba existentes en las instrucciones del sistema sin permiso especial.
• Drenaje de tokens (Token Drain): Si el agente entra en un ciclo infinito tratando de arreglar conflictos de dependencias mutuamente excluyentes, puede agotar todo el límite de API en 15 minutos. Siempre limite el número de pasos (por ejemplo, un máximo de 25 iteraciones por sesión).
• Contaminación del contexto (Context Degradation): Con cada iteración, el log del diálogo aumenta, llenándose de largos stack traces de errores. Si el contexto no se comprime o se corta, la calidad del razonamiento del modelo comienza a degradarse ya en el décimo paso.
• Trabajo en la rama principal: Iniciar el ciclo autónomo directamente en la rama main o sin un commit previo del trabajo no terminado del ingeniero puede resultar en la pérdida irreversible de código debido a experimentos fallidos del agente.