Bucles de autocrítica: dejar que el modelo revise su propio resultado

Una segunda pasada de revisión, independiente, encuentra más errores que pedir «sé riguroso» en el mismo aliento.

El principio

En un bucle de autocrítica (critique-then-revise) dejas que el modelo evalúe después, en un paso separado, su propia solución — y solo entonces la revise. En vez de «resuelve la tarea con rigor» en un solo prompt, esto se hace en pasos deliberados: primero generar, luego revisar, luego mejorar.

Por qué las pasadas separadas funcionan mejor

Si pides solución y rigor en el mismo aliento, el modelo suele evaluar su resultado dentro de la misma línea de pensamiento en la que lo generó — los errores propios de esa forma de pensar normalmente quedan sin detectar. Una segunda pasada con una mirada fresca sobre el resultado terminado, en cambio, tiende a encontrar errores que eran invisibles durante la generación misma.

Un ejemplo práctico

Una pasada de revisor con contexto fresco: das solo el código terminado (sin el historial de razonamiento) en una nueva solicitud y pides explícitamente que se busquen errores. Sin recordar su propia «justificación» anterior, el modelo revisa el código de forma más neutral.

El límite: autoconfirmación

Los bucles de autocrítica no garantizan ausencia de errores. Ante un malentendido fundamental de la tarea, el modelo suele repetir ese malentendido también en su propia revisión. Para independencia real ayuda un segundo modelo o una persona como instancia de revisión.

EJEMPLO

Paso 1 (nueva solicitud): «Escribe una función que valide una fecha en formato DD.MM.AAAA.» Paso 2 (solicitud separada y fresca, solo con el código terminado como entrada): «Aquí hay una validación de fecha. Encuentra bugs y casos límite, sin saber cómo ni por qué se escribió.» Paso 3: «Revisa la función basándote en esta crítica.»

🛠️ EJERCICIO — PRUÉBALO TÚ

Construye un bucle de autocrítica en dos pasos para una pequeña tarea de programación.

Deja que el modelo escriba una función pequeña (p. ej. una validación de fecha).
Abre una nueva solicitud separada e ingresa solo el código terminado sin el historial anterior, con la petición 'Encuentra bugs y casos límite en este código.'
Deja que el modelo escriba una versión revisada basada en la crítica.
Compara la primera versión con la revisada.

✅ AUTOEVALUACIÓN

☐ ¿La pasada de revisión fresca encontró problemas que no se notaron al escribir originalmente?
☐ ¿'Sé riguroso' en la misma pasada habría llegado al mismo resultado?

QUIZ RÁPIDO

¿Por qué una pasada de revisión separada suele encontrar más errores que pedir «sé riguroso» en la misma pasada de respuesta?