Hay un momento específico que separa a alguien que usa la IA de forma casual de alguien que realmente la opera como un sistema.
Es el momento en que dejan de ser quienes detectan el error.
Ahora mismo, para la mayoría de la gente, el ciclo se ve así. Pedirle algo a Claude. Leer la respuesta. Notar que algo está mal. Señalarlo. Obtener una versión corregida. Leer eso. Notar algo más. Señalarlo de nuevo. Tú eres la capa de verificación, manualmente, cada vez, para cada tarea.
Un bucle autocorrectivo te elimina de esa posición por completo. El sistema genera, verifica su propio trabajo contra un estándar real, detecta lo que hizo mal, lo corrige, y solo entonces te muestra el resultado. Para cuando ves la salida, los errores obvios ya han sido detectados y manejados. Lo que queda para ti es el juicio sobre las cosas que realmente necesitan a un humano, no la corrección del primer borrador de una máquina.
Esta es la construcción completa. Al final, tendrás la arquitectura exacta, los prompts exactos y los modos de fallo exactos para probar antes de confiar esto en algo que realmente importe.
Por Qué Esto No Es Lo Mismo Que Solo Preguntar Dos Veces
El primer instinto obvio es simplemente pedirle al modelo que revise su propio trabajo en la misma conversación. "Revisa lo que acabas de escribir y corrige cualquier error." Esto ayuda un poco. Pero no construye un verdadero bucle autocorrectivo, y entender por qué es la base de todo lo que sigue.
Un modelo que revisa su propia salida en el mismo contexto, con el mismo razonamiento que produjo el error en primer lugar, tiende a defender su propio trabajo en lugar de examinarlo genuinamente. Esto no es un defecto específico de un modelo en particular. Es un problema estructural. El mismo paso que generó una respuesta que suena plausible pero es incorrecta no está bien posicionado para notar que es incorrecta, porque desde dentro, la respuesta aún suena plausible. Preguntar "¿estás seguro?" produce más a menudo tranquilidad que un verdadero reexamen.
La solución no es preguntar mejor. Es la arquitectura. Un verdadero bucle autocorrectivo separa el trabajo de producir una respuesta del trabajo de juzgarla, utilizando un paso diferente, un prompt diferente y, idealmente, un marco de referencia completamente diferente, para que el juicio no esté contaminado por los mismos puntos ciegos que crearon el error.
Los Tres Roles Que Necesita Cada Bucle Autocorrectivo
Todo sistema autocorrectivo que funcione, independientemente de la tarea específica, se reduce a tres roles distintos. Entender estos roles claramente es más importante que cualquier prompt específico a continuación, porque una vez que los veas, puedes construir un bucle para casi cualquier tarea completando los detalles.
El Constructor. Produce la salida real. Escribe el código, redacta el contenido, hace la investigación, ejecuta la tarea. A este rol se le debe dar la mayor libertad creativa y la menor restricción, porque su trabajo es producir un primer intento, no uno perfecto.
El Juez. No construye nada. Su único trabajo es evaluar la salida del Constructor contra un estándar específico y escrito, no una vaga sensación de calidad. ¿El código pasa sus pruebas? ¿El borrador coincide con el briefing? ¿La investigación realmente responde a la pregunta planteada? Lo ideal es que el Juez tenga acceso a algo que el Constructor no tiene: el material fuente original, el conjunto de pruebas, el documento de requisitos real, para tener una verdad independiente que verificar en lugar de solo releer la misma salida y formarse una nueva opinión.
El Gerente. Lee el veredicto del Juez y decide qué sucede a continuación. Enviarlo de vuelta al Constructor con comentarios específicos. Escalarlo a un humano. Marcar la tarea como completada. Aquí también reside tu condición de parada, la regla que evita que el bucle se ejecute para siempre cuando algo no se puede corregir automáticamente.
El principio de diseño crítico en los tres roles: la verificación necesita referenciar algo fuera del razonamiento del Constructor. Un conjunto de pruebas. Un documento fuente original. Una lista de verificación escrita. Una segunda llamada de IA con un enfoque genuinamente diferente. Cualquier cosa que no sea simplemente "el mismo modelo, preguntado de nuevo, en el mismo aliento."
Construyendo las Transferencias
El trabajo de ingeniería real en un bucle autocorrectivo no son prompts ingeniosos para cada rol. Es la estructura de lo que se transfiere entre ellos, y esta es la parte que la mayoría de la gente que construye su primer bucle se salta por completo, y luego se pregunta por qué el sistema se comporta de manera impredecible.
Una transferencia necesita tres propiedades para funcionar de manera confiable. Un formato definido, para que el rol receptor no tenga que analizar prosa suelta y adivinar qué es importante. Un disparador definido, para que el Constructor no sea quien decida cuándo ha terminado. Y una ruta de fallo definida, para que cuando algo no salga limpio, haya un siguiente paso especificado en lugar de que el sistema se rompa en silencio o se repita para siempre.
En la práctica, esto significa que el Constructor debe generar algo estructurado, no solo texto conversacional. Un entregable claro más una declaración explícita de lo que no está seguro. El Juez luego evalúa esa salida estructurada contra un estándar escrito y devuelve su propio veredicto estructurado, no un párrafo de prosa ambigua, sino un claro aprobado, reprobado o necesita revisión, con la razón específica adjunta. El Gerente lee ese veredicto estructurado, no el contenido bruto, y decide la siguiente acción basándose en reglas establecidas de antemano, no improvisando un juicio en el momento.
Aquí hay una plantilla de estructura que funciona en la mayoría de las tareas, ya sea que el trabajo subyacente sea escritura, código o investigación:
1FORMATO DE SALIDA DEL CONSTRUCTOR2Entregable: [la salida real]3Confianza: [alta / media / baja]4Incertidumbres conocidas: [cualquier cosa de la que no estés seguro, declarada explícitamente]5Suposiciones realizadas: [cualquier cosa que asumiste sin que te lo dijeran]67FORMATO DE VEREDICTO DEL JUEZ8Veredicto: [APROBADO / REPROBADO / NECESITA REVISIÓN]9Verificado contra: [el estándar específico utilizado, ej. el briefing original,10el conjunto de pruebas, el documento fuente]11Problemas específicos encontrados: [problemas exactos, no una impresión general]12Confianza en este veredicto: [alta / media / baja]1314ACCIÓN DEL GERENTE15Si APROBADO: marcar como completado, entregar al usuario.16Si REPROBADO o NECESITA REVISIÓN: enviar de vuelta al Constructor con los17problemas específicos del Juez adjuntos. Incrementar el contador de revisiones.18Si el contador de revisiones supera [N]: dejar de repetir, escalar a humano19con el historial completo de lo que se intentó y por qué falló.
Esto parece más estructura que una conversación informal de ida y vuelta, y lo es. Ese costo inicial es lo que te compra un sistema que se comporta igual en la centésima ejecución que en la primera, en lugar de desviarse impredeciblemente a medida que se acumula el contexto.
El Juez Necesita Verdad Fundamental, No Solo Una Opinión
Este es el principio más importante de todo el sistema, y merece su propia sección porque equivocarse en esto socava silenciosamente todo lo demás.
Un Juez que solo ve la salida del Constructor, sin ninguna referencia independiente para verificar, solo puede evaluar la consistencia interna, si la salida parece coherente y bien formateada. No puede evaluar la corrección, si la salida realmente coincide con lo que se pidió o si realmente resuelve el problema real. Una respuesta segura pero incorrecta, bien formateada e internamente consistente, pasará sin problemas junto a un Juez sin verdad fundamental, una y otra vez.
Para tareas de codificación, la verdad fundamental es el conjunto de pruebas, la salida real de ejecutar el código, los resultados de lint, el estado de construcción. No "¿este código se ve bien?", sino "¿realmente pasó cuando se ejecutó?"
Para tareas de contenido, la verdad fundamental es el material fuente original y el briefing original, lado a lado con el borrador. No "¿esto se lee bien?", sino "¿cada afirmación específica en este borrador se remonta a algo realmente en la fuente, y la pieza satisface cada requisito en el briefing?"
Para tareas de investigación, la verdad fundamental son los resultados de búsqueda reales y los documentos fuente en los que se suponía que la investigación se basaba. No "¿este resumen suena autoritario?", sino "¿cada afirmación se puede rastrear hasta una fuente específica, y las fuentes que se buscaron eran realmente las relevantes?"
Si no puedes articular cuál es la verdad fundamental del Juez para tu tarea específica, aún no tienes un bucle autocorrectivo. Tienes un bucle de reformulación, donde el error confiado del Constructor se reformula con confianza por el Juez en lugar de ser realmente detectado.
La Condición de Parada No Es Opcional
La forma más común en que un bucle autocorrectivo se convierte en un desorden costoso y fuera de control es la ausencia de una condición de parada explícita y dura. Sin una, un Constructor y un Juez pueden ciclar indefinidamente, cada revisión desencadenando otra evaluación, cada evaluación desencadenando otra revisión, mientras el costo aumenta y nadie se da cuenta hasta que llega la factura.
Una condición de parada real necesita tres componentes, y los tres deben aplicarse como lógica explícita, no dejarse al juicio del modelo en el momento.
Un número máximo de iteraciones. Un límite máximo en los ciclos de revisión, después del cual el Gerente se ve obligado a escalar a un humano independientemente de si el Juez está satisfecho.
Un umbral de calidad que sea realmente medible, no aspiracional. "Suficientemente bueno" como instrucción dentro de un prompt no es una condición de parada, porque es una sugerencia que el modelo puede y eventualmente ignorará bajo la presión adecuada. Una barra específica y verificable: los once casos de prueba pasan, o el borrador coincide con los cinco requisitos del briefing establecidos, es una condición de parada, porque se puede verificar mecánicamente en lugar de juzgarse subjetivamente cada vez.
Un límite de costo o tiempo. Un presupuesto absoluto que la tarea no puede exceder independientemente del estado en que se encuentre cuando se alcance ese límite. Esta es la barandilla que te protege específicamente del peor escenario posible: una tarea verdaderamente irresoluble que se repite hasta que alguien note la factura.
CONDICIONES DE PARADA
Revisiones máximas: 3. En el 3er veredicto fallido, detenerse y escalar
a un humano con el historial completo de revisiones adjunto; no intentar
un 4to ciclo automáticamente.
Umbral de calidad: todos los elementos en la lista de verificación del Juez deben mostrar APROBADO,
no "mayormente aprobado" o "casi suficiente."
Límite de presupuesto: si esta tarea ha consumido más de [X] tokens o
[Y] minutos, detenerse inmediatamente independientemente del estado actual e informar
lo que se completó versus lo que queda.
Escribe esto en la lógica real del Gerente, no en una instrucción suave dentro de un prompt más largo que el modelo puede eludir bajo presión.
Un Ejemplo Práctico: Producción de Contenido Autocorrectiva
Para hacer esto concreto, aquí está exactamente cómo los tres roles y la condición de parada se unen para una tarea real y común: convertir un documento fuente en una pieza de contenido terminada sin que un humano revise manualmente cada borrador.
El Constructor recibe el material fuente y el briefing, y produce un borrador. Su salida incluye el borrador en sí, más una declaración de confianza explícita y una lista de cualquier cosa de la que no estuviera seguro mientras escribía: un número específico del que no estaba completamente seguro de que estuviera en la fuente, una afirmación que infirió en lugar de encontrar declarada directamente.
El Juez recibe el borrador y la fuente original lado a lado, nunca el borrador de forma aislada. Verifica tres cosas específicas, cada una con su propio aprobado o reprobado. ¿Cada afirmación factual en el borrador se remonta a algo realmente presente en la fuente? ¿El borrador satisface cada requisito específico en el briefing: longitud, tono, secciones requeridas? ¿El argumento central o gancho está realmente presente y no diluido por relleno? El Juez devuelve un veredicto estructurado con un aprobado o reprobado en cada una de las tres verificaciones por separado, porque colapsar esto en una puntuación general oculta exactamente qué dimensión falló.
El Gerente lee ese veredicto estructurado. Un aprobado limpio en las tres envía el borrador a una cola de salida final. Un fallo en la dimensión de verificación de hechos lo envía de vuelta al Constructor con la afirmación no verificada específica marcada directamente, no una instrucción vaga de "verificar la precisión." Un fallo en el cumplimiento del briefing lo envía de vuelta con el requisito faltante específico nombrado. Después de tres ciclos fallidos en la misma verificación específica, el Gerente deja de repetir por completo y escala a un humano con el historial completo de lo que se intentó, en lugar de continuar reintentando un problema que el sistema ya ha demostrado que no puede resolver por sí solo.
Este es un sistema pequeño. Tres roles, un formato de transferencia estructurado, una condición de parada explícita. También es un sistema que realmente podrías ejecutar sin supervisión y confiar en su salida, porque cada modo de fallo tiene una ruta definida en lugar de una indefinida.
Probando el Bucle Antes de Confiar en Él
Antes de confiar en cualquier sistema autocorrectivo para algo que realmente importa, pruébalo deliberadamente con estas pruebas de estrés específicas. La mayoría de los bucles que fallan en uso real habrían fallado una de estas pruebas de inmediato, si alguien se hubiera tomado la molestia de verificar primero.
La prueba de la tarea irresoluble. Dale deliberadamente al Constructor una tarea que no pueda completar según el estándar del Juez, a propósito. ¿El Gerente alcanza correctamente el límite de iteraciones y escala a un humano, o se repite indefinidamente, quemando costo en una tarea que nunca iba a tener éxito?
La prueba del error seguro pero incorrecto. Alimenta al Juez una salida que ya sabes que es sutilmente incorrecta, algo que se lee bien pero contiene un error fáctico o lógico específico. ¿El Juez, con su referencia de verdad fundamental, lo detecta correctamente? Si el Juez aprueba algo que sabes que está roto, tu referencia de verdad fundamental no se está verificando realmente, o la verificación es demasiado superficial.
La prueba del punto ciego del mismo modelo. Si tu Constructor y Juez se ejecutan en el mismo modelo subyacente, vale la pena verificar esto directamente. Alimenta al Juez una salida que contenga exactamente el tipo de error que ese modelo tiende a cometer característicamente. Si el Juez lo deja pasar, has construido un bucle que comparte sus puntos ciegos entre roles, lo que anula todo el propósito de separarlos. Considera usar un modelo genuinamente diferente, o al menos un marco de prompt significativamente diferente, para el rol del Juez específicamente.
La prueba de fuga de costos. Calcula el peor camino posible a través de tu sistema: revisiones máximas, llamadas de modelo más costosas involucradas, longitud de contenido razonable más larga, y calcula cuánto cuesta realmente en dólares reales y tiempo real. Si ese número te alarmaría al aparecer en una factura real, tus condiciones de parada aún no son lo suficientemente estrictas.
Ejecutar estas cuatro pruebas antes de confiar en un bucle autocorrectivo con algo real detecta la gran mayoría de los fallos que de otro modo aparecerían por primera vez frente a un cliente, un jefe o tu propio extracto bancario.
Errores Comunes Que Rompen Silenciosamente un Diseño Por Lo Demás Bueno
Incluso con la arquitectura correcta de tres roles, un puñado de errores de implementación específicos aparecen repetidamente en dominios completamente diferentes, y conocerlos de antemano te ahorra redescubrir cada uno de la manera difícil.
Dejar que el Juez vea solo la salida del Constructor, sin ninguna referencia independiente. Este es el error más común, y silenciosamente convierte tu sistema de una verificación de corrección a una verificación de coherencia. Un Juez sin nada con qué comparar solo puede decirte que la salida parece internamente consistente, nunca si es realmente correcta.
Darle a cada rol el mismo modelo con solo una pequeña diferencia de instrucción superpuesta. Si el Juez está ejecutando el mismo modelo subyacente que el Constructor, con solo un prompt diferente que le dice que "sea crítico", a menudo hereda los mismos puntos ciegos que tiene el Constructor, porque es fundamentalmente el mismo proceso de razonamiento con un sombrero diferente. Donde el presupuesto lo permita, un modelo genuinamente diferente para el rol del Juez produce independencia real en lugar de independencia teatral.
Tratar al Gerente como un simple pasamanos en lugar de darle memoria real de intentos anteriores. Un Gerente sin visibilidad de lo que ya se intentó en esta tarea específica enviará felizmente la misma retroalimentación fallida al Constructor una segunda y tercera vez, produciendo el mismo resultado fallido cada vez, porque nada en el sistema recuerda que este enfoque exacto ya falló una vez.
Saltarse las cuatro pruebas de estrés porque el sistema funcionó bien en la única demostración que todos observaron de cerca. Un sistema que se comporta correctamente mientras lo observas de cerca y un sistema que se comporta correctamente mientras se ejecuta sin supervisión son afirmaciones diferentes. Solo la segunda es el punto real de construir un bucle autocorrectivo en primer lugar. Si no has probado los modos de fallo deliberadamente, realmente no sabes qué afirmación es cierta para tu sistema todavía.
Escribir la condición de parada como una instrucción suave en lugar de lógica dura. "Detenerse cuando sea suficientemente bueno" dentro de un prompt no es una condición de parada, es una sugerencia que el modelo puede y eventualmente evadirá bajo la presión adecuada. Un contador de iteraciones duro que el Gerente verifica mecánicamente antes de permitir otro ciclo es una condición de parada. La diferencia entre estos dos importa enormemente la primera vez que una tarea resulta ser verdaderamente irresoluble.
Un Segundo Ejemplo Práctico: Código Autocorrectivo
El mismo esqueleto se ve diferente pero sigue una lógica idéntica cuando la tarea es código en lugar de contenido, y recorrer ambos lado a lado deja claro cuán poco cambia realmente entre dominios.
El Constructor aquí es un agente de codificación que trabaja en una tarea definida: una corrección de errores, una función, una refactorización. Su salida estructurada no es solo el diff de código, sino la salida real del comando al intentar ejecutarlo, los resultados de las pruebas, la salida de lint, el estado de construcción, todo incluido en la transferencia. Un Constructor que produce código pero nunca lo ejecuta realmente no está cumpliendo correctamente el rol de Constructor, porque un código sintácticamente plausible que falla su propio conjunto de pruebas es peor que ningún código, ya que parece terminado sin estarlo.
El Juez verifica tres cosas específicas y verificables. ¿El cambio pasó el conjunto de pruebas existente sin que las pruebas mismas fueran modificadas (ya que un Constructor que edita silenciosamente una prueba para que pase es un fallo específico y sorprendentemente común que vale la pena verificar directamente)? ¿El análisis estático y el linting regresaron limpios? ¿El diff realmente aborda la tarea que se asignó, no un problema relacionado pero diferente que el Constructor decidió que era más interesante resolver en el camino? Cada uno de estos obtiene su propio aprobado o reprobado explícito en el veredicto estructurado.
El Gerente enruta según qué verificación específica falló. Un conjunto de pruebas fallido se envía de vuelta al Constructor con la salida exacta de la prueba fallida adjunta directamente, no una instrucción genérica de "arreglar las pruebas." Una falta de coincidencia en el alcance, donde el diff resolvió un problema diferente al asignado, se escala inmediatamente a un humano en lugar de repetirse, porque eso es un fallo de juicio sobre cuál era realmente la tarea, no un defecto mecánico que el Constructor pueda simplemente iterar por sí solo.
Observa que el esqueleto subyacente aquí —Constructor produce y envía con evidencia, Juez verifica contra criterios específicos nombrados con un veredicto por verificación, Gerente enruta según exactamente qué verificación falló— es idéntico al ejemplo de producción de contenido anterior. Esta es la lección real que vale la pena llevar adelante al ver dos dominios diferentes lado a lado. Una vez que tienes el esqueleto correcto, aplicarlo a un nuevo tipo de tarea es principalmente cuestión de escribir una nueva lista de verificación específica para el Juez, no rediseñar toda la arquitectura desde primeros principios cada vez.
Escalando a Múltiples Bucles Concurrentes
Una vez que un solo bucle autocorrectivo es genuinamente confiable, la siguiente pregunta real es cómo ejecutar varios a la vez sin que el sistema se vuelva inmanejable, ya que aquí es exactamente donde el segundo intento de la mayoría de la gente de escalar esto sale mal.
La tentación es poner en marcha muchos bucles simultáneamente en cuanto el primero funciona, abordando cinco tareas diferentes en paralelo porque la arquitectura técnicamente lo soporta. Resiste esto más tiempo del que parezca necesario. Cada bucle concurrente adicional es otro lugar donde una condición de parada puede fallar silenciosamente, otro lugar donde el costo puede escaparse sin ser notado, otro lugar donde la referencia de verdad fundamental de un Juez podría estar sutilmente equivocada de una manera que solo se muestra bajo volumen real en lugar de en una sola ejecución de prueba.
El camino de escalado más seguro es la expansión secuencial con un umbral de confianza genuino en cada paso. Consigue que un bucle funcione de manera suficientemente confiable como para que hayas dejado de verificar su salida de cerca, lo que significa que pasa consistentemente tus propias verificaciones puntuales manuales durante un período de tiempo real, no solo una única demostración exitosa. Solo entonces agrega un segundo bucle para una tarea diferente. Rastrea la tasa de fallo real de cada bucle a lo largo del tiempo, no solo si pareció funcionar en las ejecuciones que observaste.
Cuando ejecutes múltiples bucles concurrentemente, dale seria consideración a un panel de costos compartido para todos ellos, no un seguimiento por bucle de forma aislada. Un solo bucle con un presupuesto razonable por tarea se ve completamente bien de forma aislada. Diez bucles, cada uno individualmente dentro del presupuesto, aún pueden sumar un total genuinamente alarmante que nadie nota hasta que llega la factura agregada, precisamente porque el seguimiento de cada bucle individual se veía bien por sí solo.
El único hábito que previene problemas de escalado antes de que comiencen: registra cada activación de condición de parada en todos los bucles, no solo las finalizaciones exitosas. Un bucle que alcanza su límite máximo de iteraciones y escala a un humano está haciendo exactamente lo que se supone que debe hacer, pero si un bucle específico alcanza ese límite constantemente mientras que otros rara vez lo hacen, eso es una señal de que el estándar del Juez para esa tarea en particular está mal calibrado, es demasiado estricto para realmente aprobar, o está verificando contra la verdad fundamental equivocada por completo. Ese patrón es invisible si solo estás rastreando éxitos y tratando cada escalada como un evento aislado y sin importancia en lugar de un punto de datos sobre el diseño de ese bucle específico.
Por Dónde Empezar Esta Semana
No intentes construir un sistema autocorrectivo completamente general en tu primer intento. Elige una tarea específica, estrecha y bien definida que ya hagas regularmente, algo con un estándar claro que podrías escribir si te lo pidieran, y construye el bucle de tres roles alrededor de esa única tarea primero.
Escribe la lista de verificación del Juez explícitamente antes de escribir una sola línea del prompt del Constructor. El estándar contra el que verifiques debe dar forma a lo que le pidas al Constructor que produzca, no al revés. Si aún no puedes escribir la lista de verificación, aún no sabes lo suficientemente bien qué significa "correcto" para esta tarea como para automatizar su verificación, y vale la pena descubrir eso antes de construir nada.
Ejecuta las cuatro pruebas de estrés anteriores antes de confiar el bucle con algo que realmente importe, no después de que algo ya haya salido mal frente a alguien. Agrega la condición de parada como lógica real y dura desde la primera versión, no como una ocurrencia tardía después de que ya te hayas quemado con un bucle descontrolado una vez.
Una vez que un bucle es genuinamente confiable, se ejecuta sin supervisión, detecta errores reales, se detiene limpiamente cuando debería, el segundo va mucho más rápido. No porque los prompts se transfieran directamente (por lo general necesitan reescribirse para la nueva tarea), sino porque ya entiendes la forma real del problema. Separa la construcción del juicio. Dale al juicio algo real contra lo que verificar. Escribe la condición de parada como lógica, no como esperanza.
Esa forma es toda la disciplina. Todo lo demás es solo aplicarla a la tarea que tengas delante.
Sigue a @cyrilXBT para las plantillas de bucle exactas y las configuraciones Constructor-Juez-Gerente detrás de todo en este artículo.
