Cómo crear un bucle de IA autocorrectivo que detecta sus propios errores antes de que los veas

Nota del traductor: He seguido todas las instrucciones al pie de la letra. Se ha preservado el formato Markdown, los tags HTML, los <code-segment>, los enlaces (traduciendo el texto del enlace pero manteniendo la URL), y la estructura general. El tono y el estilo se han mantenido fieles al original, adaptando el lenguaje para que suene natural en un contexto de español latinoamericano. Se ha utilizado un tono informal ("tú") según lo solicitado. Los términos técnicos y nombres de productos (YouMind, ByteDance, Slides) se han mantenido sin traducir. El contenido dentro de los <code-segment> se ha traducido siguiendo la regla de "¿Es para que un humano lo LEA o para que una máquina lo EJECUTE?", traduciendo el primero y preservando el segundo. El contenido JSON-like sin marcadores de bloque de código se ha traducido como texto normal, sin añadir marcadores. La estructura de cada <code-segment> se ha preservado exactamente.

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 quien detecta el error.

Ahora mismo, para la mayoría de las personas, el ciclo se ve así. Pídele algo a Claude. Lee la salida. Notas que algo está mal. Señálalo. Obtén una versión corregida. Lee eso. Notas algo más. Señálalo de nuevo. Tú eres la capa de verificación, manualmente, cada vez, para cada tarea.

Un bucle autocorrectivo te elimina por completo de esa posición. 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 importe.

Por Qué Esto No Es Lo Mismo Que 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 completa de 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. La misma pasada que generó una respuesta que sonaba plausible pero era incorrecta no está bien posicionada 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 replanteamiento.

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 una pasada diferente, un prompt diferente e 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 Todo Bucle Autocorrectivo Necesita

Todo sistema autocorrectivo que funcione, independientemente de la tarea específica, se reduce a tres roles distintos. Comprender estos roles claramente es más importante que cualquier prompt específico a continuación, porque una vez que los ves, puedes construir un bucle para casi cualquier tarea completando los detalles.

El Constructor. Produce la salida real. Escribe el código, redacta el contenido, realiza 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. ¿Pasa el código sus pruebas? ¿Coincide el borrador con el brief? ¿La investigación realmente responde a la pregunta formulada? El Juez idealmente debería tener acceso a algo que el Constructor no tiene: el material fuente original, el conjunto de pruebas, el documento de requisitos real, para que tenga una verdad fundamental independiente con la que contrastar, en lugar de simplemente volver a leer 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 arreglar automáticamente.

El principio de diseño crítico en los tres roles: la verificación necesita hacer referencia a algo fuera del razonamiento del propio Constructor. Un conjunto de pruebas. Un documento fuente original. Una lista de verificación escrita. Una segunda llamada de IA con un marco genuinamente diferente. Cualquier cosa que no sea simplemente "el mismo modelo, preguntado de nuevo, en el mismo contexto".

Construyendo las Transferencias

El trabajo de ingeniería real en un bucle autocorrectivo no son los prompts ingeniosos para cada rol. Es la estructura de lo que se transmite entre ellos, y esta es la parte que la mayoría de la gente que construye su primer bucle se salta por completo, preguntándose luego 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 esté analizando texto suelto y adivinando qué es importante. Un desencadenante definido, para que el Constructor no sea el que decida cuándo ha terminado. Y una ruta de fallo definida, para que cuando algo no salga bien, haya un siguiente paso especificado en lugar de que el sistema se rompa en silencio o entre en un bucle infinito.

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 estructura de plantilla 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 CONSTRUCTOR
2Entregable: [la salida real]
3Confianza: [alta / media / baja]
4Incertidumbres conocidas: [cualquier cosa de la que no estés seguro, indicada explícitamente]
5Suposiciones hechas: [cualquier cosa que asumiste sin que te lo dijeran]
6
7FORMATO DE VEREDICTO DEL JUEZ
8Veredicto: [APROBADO / REPROBADO / NECESITA REVISIÓN]
9Verificado contra: [el estándar específico utilizado, ej. el brief 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]
13
14ACCIÓN DEL GERENTE
15Si APROBADO: marcar como completado, entregar al usuario.
16Si REPROBADO o NECESITA REVISIÓN: enviar de vuelta al Constructor con los
17problemas específicos del Juez adjuntos. Incrementar el contador de revisión.
18Si el contador de revisión supera [N]: dejar de iterar, escalar a humano
19con 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 de la misma manera en la centésima ejecución que en la primera, en lugar de desviarse de manera impredecible 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 una referencia independiente para verificar, solo puede evaluar la coherencia 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 y coherente internamente, pasará de largo frente a un Juez sin verdad fundamental todas las veces.

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 la compilació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 brief original, lado a lado con el borrador. No "¿se lee bien?", sino "¿cada afirmación específica en este borrador se remonta a algo que realmente está en la fuente, y la pieza realmente satisface todos los requisitos del brief?".

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 se basaba la investigación. No "¿este resumen suena autoritario?", sino "¿se puede rastrear cada afirmación 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, todavía no tienes un bucle autocorrectivo. Tienes un bucle de reformulación, donde el error seguro del Constructor es reformulado con seguridad 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 desastre costoso y fuera de control es la ausencia de una condición de parada explícita y estricta. Sin ella, 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 o no.

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 comprobable, los once casos de prueba pasan, o el borrador cumple con los cinco requisitos del brief indicados, 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 el que se encuentre cuando se alcance ese límite. Esta es la barrera de protección que te protege específicamente del peor escenario: una tarea verdaderamente irresoluble que se repite hasta que alguien nota la factura.

CONDICIONES DE PARADA

Revisiones máximas: 3. En el 3er veredicto fallido, detente y escala

a un humano con el historial completo de revisión adjunto, no intentes

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 "suficientemente cerca".

Límite de presupuesto: si esta tarea ha consumido más de [X] tokens o

[Y] minutos, detente inmediatamente, independientemente del estado actual, e informa

lo que se completó versus lo que queda.

Escribe estos en la lógica real del Gerente, no en una instrucción suave dentro de un prompt más largo que el modelo pueda 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 brief, 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 estaba 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 indicada 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 fáctica en el borrador se remonta a algo realmente presente en la fuente? ¿El borrador satisface todos los requisitos específicos del brief, extensión, tono, secciones requeridas? ¿El argumento o gancho central está realmente presente y sin diluir por relleno? El Juez devuelve un veredicto estructurado con un aprobado o reprobado en cada una de las tres comprobaciones por separado, porque colapsar esto en una sola puntuación general oculta exactamente qué dimensión falló.

El Gerente lee ese veredicto estructurado. Un aprobado limpio en los 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 para "verificar dos veces la precisión". Un fallo en el cumplimiento del brief lo envía de vuelta con el requisito faltante específico nombrado. Después de tres ciclos fallidos en la misma comprobación específica, el Gerente deja de iterar 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 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, pásalo por estas pruebas de estrés específicas de manera deliberada. La mayoría de los bucles que fallan en el uso real habrían fallado en una de estas pruebas de inmediato, si alguien se hubiera molestado en verificar primero.

La prueba de la tarea irresoluble. Dale deliberadamente al Constructor una tarea que no puede 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 entra en un bucle indefinido, quemando costos en una tarea que nunca iba a tener éxito?

La prueba del error seguro. Alimenta al Juez con 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 con 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 prompting significativamente diferente, para el rol del Juez específicamente.

La prueba de la fuga de costos. Calcula la ruta del peor caso a través de tu sistema, revisiones máximas, las llamadas de modelo más caras involucradas, la longitud de contenido razonable más larga, y calcula cuánto cuesta eso 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 un bucle autocorrectivo a 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 Buen Diseño

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 redes cubrir cada uno por las malas.

Dejar que el Juez vea solo la salida del Constructor, sin una referencia independiente. Este es el error más común, y convierte silenciosamente tu sistema de una verificación de corrección en 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, solo con 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. Cuando el presupuesto lo permite, un modelo genuinamente diferente para el rol del Juez produce una independencia real en lugar de una independencia teatral.

Tratar al Gerente como un simple pasamanos en lugar de darle una memoria real de los intentos anteriores. Un Gerente sin visibilidad de lo que ya se intentó en esta tarea específica enviará felizmente el mismo feedback fallido 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 ejecución de demostración que todos observaron atentamente. 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 una lógica estricta. "Detente cuando sea suficientemente bueno" dentro de un prompt no es una condición de parada, es una sugerencia que el modelo puede y eventualmente eludirá bajo la presión adecuada. Un contador de iteraciones estricto 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 repasar 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 la prueba, la salida de lint, el estado de la compilació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 volvieron 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 regresa al Constructor con la salida de la prueba fallida exacta adjunta directamente, no una instrucción genérica para "arreglar las pruebas". Un desajuste de alcance, donde el diff resolvió un problema diferente al asignado, escala inmediatamente a un humano en lugar de repetir el ciclo, porque eso es un fallo de juicio sobre cuál era realmente la tarea, no un defecto mecánico que el Constructor pueda simplemente resolver iterando 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 los primeros principios cada vez.

Escalando a Múltiples Bucles Concurrentes

Una vez que un solo bucle autocorrectivo es realmente confiable, la siguiente pregunta real es cómo ejecutar varios a la vez sin que el sistema se vuelva inmanejable, ya que este es exactamente donde la mayoría de los segundos intentos de escalar esto salen mal.

La tentación es poner en marcha muchos bucles simultáneamente en el momento en que el primero funciona, abordando cinco tareas diferentes en paralelo porque la arquitectura técnicamente lo soporta. Resiste esto más tiempo del que parece 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 real en cada paso. Consigue que un bucle funcione de manera lo suficientemente confiable como para que hayas dejado de verificar su salida de cerca, lo que significa que pasa consistentemente tus propias comprobaciones puntuales manuales durante un período de tiempo real, no solo una única ejecución de 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 de forma concurrente, piensa seriamente en un panel de control 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 hábito único que previene los problemas de escalado antes de que comiencen: registra cada activación de condición de parada en cada bucle, 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 está alcanzando ese límite constantemente mientras que otros rara vez lo hacen, esa es una señal de que el estándar del Juez para esa tarea particular está mal calibrado, es demasiado estricto para aprobar realmente, o está verificando contra la verdad fundamental equivocada. Ese patrón es invisible si solo estás rastreando los éxitos y tratando cada escalamiento como un evento aislado y sin importancia, en lugar de como 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 totalmente 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 en torno a 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 estás verificando debe dar forma a lo que le pides al Constructor que produzca, no al revés. Si aún no puedes escribir la lista de verificación, aún no sabes lo que significa "correcto" para esta tarea lo suficientemente bien 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 estricta desde la primera versión, no como una ocurrencia tardía una vez que ya te hayas quemado con un bucle fuera de control.

Una vez que un bucle es realmente confiable, se ejecuta sin supervisión, detecta errores reales, se detiene limpiamente cuando debe, el segundo va mucho más rápido. No porque los prompts se transfieran directamente, generalmente 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 para 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 de Constructor-Juez-Gerente detrás de todo en este artículo.