Self-Correction Loop

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

Una de las mayores ilusiones al trabajar con IA es esperar que un modelo de lenguaje escriba código funcional y complejo en el primer intento. En la vida real, incluso los desarrolladores experimentados dependen constantemente de herramientas de diagnóstico: ejecutan el compilador, observan la resaltación de errores en el IDE y analizan los mensajes de las pruebas.

Si se priva al agente de un ciclo de retroalimentación:

1. Alucinaciones sintácticas ciegas: El modelo utiliza con confianza métodos obsoletos de bibliotecas o se refiere a propiedades inexistentes de objetos.
2. Incapacidad para cerrar bugs complejos: Sin el análisis del stacktrace, el agente no conoce el verdadero punto de fallo del programa en tiempo de ejecución.
3. Carga rutinaria sobre el desarrollador: La persona tiene que copiar manualmente los mensajes de la terminal en un chat y pedir que se corrija el error.

Self-Correction Loop (Ciclo de auto-corrección fundamentado) transforma la generación de código en una línea de producción de ingeniería controlada: el agente realiza cambios, ejecuta herramientas de verificación, analiza la salida del entorno y repite intentos hasta que las pruebas se vuelven "verdes".

2. Taxonomía arquitectónica y modelo mental

Un ciclo de auto-corrección confiable se basa en tres niveles de oráculos de retroalimentación deterministas (Feedback Oracles):

• 1. Oráculos sintácticos y estáticos (Static Oracles): Herramientas de compilación y verificación de tipos (tsc --noEmit, mypy, cargo check). Funcionan en milisegundos y proporcionan coordenadas precisas del error (archivo, línea, columna, tipo esperado y real).
• 2. Oráculos de prueba de comportamiento dinámico (Dynamic Test Oracles): Ejecutores de pruebas (vitest, pytest, jest). Verifican la lógica real de ejecución, la reacción a condiciones límite (Boundary Conditions) y la ausencia de regresiones.
• 3. Linters estilísticos y arquitectónicos (Linters): eslint, biome, ruff. Controlan el cumplimiento del estilo de código de la empresa, la prohibición del uso de any y las fugas de variables no utilizadas.
• 4. Estrategias de corrección:
  • Surgical Diff (Parche quirúrgico): reemplazo de solo unas pocas líneas objetivo de la función.
  • Full File Rewrite (Reescritura completa de archivo): método peligroso que a menudo introduce bugs externos.

3. Pipeline técnico y mecánica interna

Ciclo de vida de la corrección iterativa de errores:

1. Patch Generation & Application (Generación y aplicación de parches): El agente genera un parche para el archivo fuente y registra los cambios en el sistema de archivos.
2. Oracle Execution (Ejecución del oráculo): El runtime ejecuta automáticamente el comando de validación en un proceso aislado (por ejemplo, npm test).
3. Exit Code & Stacktrace Extraction (Evaluación del resultado):
   • Si el código de salida es 0, la tarea se considera completada y el ciclo termina con éxito.
   • Si el código de salida es != 0, el runtime analiza stderr/stdout, elimina el ruido visual innecesario y forma un mensaje de error estructurado.
4. Context Injection & Re-prompting (Inyección de contexto y re-pregunta): El agente recibe el mensaje: «La prueba user-auth.test.ts falló en la línea 42 con el error: Se esperaba el estado 200, se recibió 401. Aquí hay un fragmento del archivo alrededor de la línea 42. Encuentra la causa y sugiere una corrección». El proceso se repite con un contador de intentos.

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

01. Autocorrección de errores en TypeScript

El agente actualiza la firma de un método en una biblioteca compartida. La ejecución de tsc detecta 8 archivos con contratos violados. El agente recorre secuencialmente cada archivo, corrige los tipos de parámetros y se detiene solo cuando el compilador produce una salida sin errores.

02. Desarrollo guiado por pruebas (TDD)

El ingeniero escribe un conjunto de pruebas unitarias estrictas que describen los requisitos comerciales para una nueva API. El agente recibe la tarea de escribir el código de implementación. Trabajando en un ciclo de auto-corrección, el modelo escribe el código, ejecuta las pruebas, analiza las discrepancias y lleva todas las pruebas a un estado verde sin intervención humana.

03. Migración automática de dependencias obsoletas

Durante la transición a una nueva versión principal del framework, el agente ejecuta un conjunto de pruebas y, a partir de los mensajes sobre métodos obsoletos (Deprecation Warning), actualiza automáticamente el código de la aplicación a las API modernas.

5. Errores comunes, trampas y seguridad

• Eliminación o debilitamiento de pruebas (Test Cheating): Al enfrentarse a una prueba complicada, el modelo puede intentar resolver el problema agregando it.skip() o comentando expect(). Siempre bloquee la posibilidad de editar archivos de prueba o verifique el Git Diff por modificaciones en la carpeta de pruebas.
• Oscilación y "ciclado suave" (Flip-Flop Edits): El agente corrige un error en el archivo A, rompiendo el archivo B; luego corrige el archivo B, rompiendo nuevamente A. Si el sistema detecta una repetición del mismo estado del código, el ciclo debe detenerse de inmediato.
• Reescritura en lugar de curación (Over-Fixing): En lugar de corregir un argumento incorrecto, el agente reescribe toda la función de 300 líneas, perdiendo optimizaciones y detalles importantes. Exija al agente que utilice parches diff localizados.