El verificador es el docente
Durante el último año aprendimos a pedirle cosas a la inteligencia artificial. Surgieron técnicas, acrónimos y plantillas para redactar mejores instrucciones. Ahora una nueva idea empieza a circular con fuerza y un nombre propio: loop engineering, o ingeniería de bucles. La promesa es contar con un asistente automatizado; para no tener que escribir un prompt tras otro, uno diseña un ciclo donde la IA hace un trabajo, verifica su propio resultado con algún criterio y repite los pasos anteriores hasta cumplirla. Uno define la meta y se va a tomar un café para que el sistema trabaje solo hasta terminar.
Este tema está circulando fuerte en las redes sociales y, aunque la idea es real, vale la pena entenderla. ¿Sirve para cualquier tarea? ¿Puedo utilizarla para mi labor docente? ¿Cómo sabe el sistema que la tarea está, efectivamente, terminada?
Spoiler: la respuesta es quizás, probablemente no.
Límites y alcances de este mecanismo
El loop nació y brilla en el desarrollo de software, y conviene preguntarse por qué. La respuesta no es que el código sea "más fácil" para la IA. Es que el código viene con un juez incorporado que existía mucho antes de que llegara la inteligencia artificial: la prueba automatizada.
Cuando un programador escribe código, puede acompañarlo de pequeños tests que se ejecutan solos y devuelven un veredicto sin matices: pasa o falla. No hay opinión, no hay interpretación. El loop simplemente toma ese veredicto que ya existía y lo pone a trabajar: la IA escribe código, corre los tests, lee los que fallaron, corrige, vuelve a correr, y así hasta que todos den en verde. Cuando eso ocurre, se detiene. La máquina no necesita "creer" que terminó: una verificación externa, automática y binaria se lo confirma.
Todo el truco está ahí, en ese verificador externo. Y eso nos lleva a la verdadera lección, que tiene poco que ver con la programación.
El que trabaja no puede ser el que aprueba
Quienes diseñaron estas herramientas tomaron una precaución ingeniosa. En las versiones más robustas, quien decide si la tarea está terminada no es el mismo modelo que hizo el trabajo, sino un segundo modelo, independiente, cuyo único oficio es leer lo producido y responder una pregunta: ¿se cumplió la condición, sí o no?
¿Por qué tanto cuidado? Porque si se deja que el mismo sistema que hace el trabajo decida si está bien hecho, aparece una tentación conocida: encontrar un atajo que cumpla la consigna al pie de la letra, pero traicione su intención. Qué ironía que la IA funcione igual que los humanos. El modelo puede declarar victoria sin haberla logrado de verdad. Cualquiera que haya corregido trabajos prácticos reconoce el fenómeno: no es buena idea pedirle al estudiante que se autocalifique sin ninguna referencia externa.
Aquí conviene una advertencia técnica. Ese verificador independiente tiene un límite estricto y es que solo puede juzgar lo que el sistema ya dejó escrito en la conversación. No navega por internet, no abre archivos, no consulta bases de datos por su cuenta. Esto importa porque circulan ejemplos llamativos, como un agente que supuestamente escribe un apunte de cátedra, detecta que citó un paper inexistente, lo reemplaza por uno real y verifica que cada enlace funcione. Sin embargo, prometen más de lo que la herramienta entrega. El verificador puede comprobar que un enlace no esté roto, si esa comprobación se vuelca al texto; jamás puede garantizar que la cita sea la correcta para lo que uno afirma. Esa segunda tarea, la de verdad importante, sigue requiriendo un lector humano.
¿Qué tareas docentes admiten un bucle?
Vamos al grano: ¿sirve esto para la docencia y la investigación, o es solo cosa de programadores? La respuesta depende de una sola frontera, y no es la que uno imaginaría. No se trata de "tareas técnicas frente a tareas analógicas", sino de tareas con un criterio de cierre comprobable frente a tareas que dependen del juicio experto.
Del lado donde el bucle sí ayuda caen tareas más cotidianas de lo que parece, siempre que el "terminado" sea inspeccionable sin opinión. Validar un banco de preguntas de un campus virtual; por ejemplo, la condición podría ser que cada pregunta tenga una sola respuesta correcta marcada, retroalimentación en todas las opciones y ninguna que supere cierto número de caracteres. Eso se revisa mecánicamente, pregunta por pregunta, sin discutir.
Así podemos agregar: comprobar que un conjunto de planillas de inscripción no tenga legajos duplicados ni campos obligatorios vacíos. Confirmar que cada resultado de aprendizaje de un plan de estudios aparezca evaluado en al menos una asignatura. Todas estas son tareas de presencia o ausencia, de cumple o no cumple. Tienen un juez que no somos nosotros.
Del otro lado queda, casi intacto, el corazón intelectual del oficio. Que un apunte esté bien explicado. Que una calificación sea justa. Que una secuencia didáctica respete el espíritu de un modelo pedagógico y no apenas una lista de requisitos. Que los objetivos de una tesis sean sólidos. Ninguna de estas cualidades admite un verificador que no sea un experto leyendo con atención. No es que el bucle las haga mal: es que, para ellas, el único juez posible es un humano. Y un bucle sin juez externo no es automatización; es, otra vez, un modelo corrigiendo su propia tarea.
Un espejo, no un atajo
Aquí aparece lo más interesante, y es una pequeña paradoja. El loop engineering no le quita el juicio al docente: lo obliga a explicitarlo.
Escribir una condición de parada que una máquina pueda verificar es, mirado de cerca, el mismo acto intelectual que redactar un objetivo de aprendizaje observable o construir una rúbrica con descriptores claros. La pregunta "¿Cómo sabría un sistema externo que esto está terminado?" es una versión sin piedad de la pregunta que define nuestro trabajo: "¿Cómo sé yo que un estudiante realmente aprendió?". Quien no logra responder la primera quizás descubra que tampoco tenía del todo resuelta la segunda. El problema, entonces, tiene que ver con criterios de evaluación difusos.
Por eso el verdadero valor de esta tendencia, para quienes enseñamos e investigamos, tal vez no esté en delegar tareas, sino en lo que nos revela al intentar definirlas. Leído así, el bucle es menos una promesa de tiempo libre y más un espejo: devuelve, con incómoda nitidez, cuán claros son nuestros propios criterios.
A modo de cierre
La ingeniería de bucles tiene muchos usos en su terreno natural: la programación asistida por IA. Pero su lección más valiosa para la educación es indirecta. Antes de preguntarnos qué tareas podemos automatizar, nos conviene preguntarnos cuáles de ellas sabríamos definir con la precisión que una máquina exige. En esa lista podríamos encontrarnos con un diagnóstico honesto de nuestra propia manera de evaluar. La próxima vez que diseñe una consigna, pruebe este ejercicio: escriba la condición exacta que le permitiría afirmar, sin lugar a dudas, que un estudiante la cumplió. Si puede escribir dicha rúbrica, entonces ya domina lo esencial del loop engineering. Si le cuesta, acaba de encontrar algo más importante para reflexionar.
Atribución
Artículo elaborado con asistencia de Claude (investigación, síntesis y redacción). Mejoras de ortografía, gramática y estilo con LanguageTool. Imágenes con ChatGPT. Información sobre las funciones técnicas verificada mediante búsqueda web en la documentación oficial de Claude Code y fuentes especializadas.