Loop Engineering: tres formas de aprobar tus propios fallos

Tesis Automatizar un ciclo no convierte sus controles en fiables. Si quien produce integra su propia corrección, el encargo limita lo que el auditor puede encontrar o la prueba nunca se ejecutó con el defecto delante, el bucle solo fabrica falsos verdes más deprisa.

El 26 de julio monté un proceso editorial con dieciséis puertas: búsqueda, estructura, redacción, semántica, castellano, SEO, visuales, fuentes, lectores, verificación, integración, regresión y un tribunal final, entre otras. La idea era sencilla: dejar de pedir cada revisión a mano y construir el sistema que decidiera qué revisión tocaba, conservara el estado y no permitiera publicar hasta tener evidencia.

El proceso dio luz verde a un artículo con una afirmación falsa sobre una herramienta real, y no porque faltara una puerta. A pesar de los auditores, las actas, el registro de decisiones y la comprobación automática, tres controles aparentaban hacer algo distinto de lo que hacían.

Los fallos sobrevivieron durante siete rondas, y esa persistencia da valor a esta nota de construcción. Describe tres formas concretas de aprobar tus propios defectos y las pruebas que tuve que añadir para dejar de hacerlo; no propone una arquitectura desde una pizarra.

Qué es Loop Engineering y qué no lo es

Addy Osmani formuló Loop Engineering en junio de 2026 como el paso de dar instrucciones directamente a un agente a diseñar el sistema que se las entrega. Ese sistema descubre trabajo, lo reparte, comprueba el resultado, guarda lo que ha ocurrido y decide el siguiente movimiento. La automatización recurrente, el aislamiento, las instrucciones reutilizables, los conectores, la separación entre quien produce y quien revisa y un estado externo forman su caja de herramientas.

La lista ayuda, pero no resuelve el problema central: decidir cuándo el ciclo ha terminado bien. Un agente puede modificar un fichero, otro puede revisarlo y un tercero puede resumir el informe; si la señal de salida no distingue un resultado correcto de una declaración de corrección, hay actividad, no ingeniería.

También conviene separar un bucle de una cadena. Una cadena ejecuta pasos fijados: redactar, revisar y publicar. Un bucle utiliza lo aprendido en una vuelta para volver atrás, cambiar una decisión o detenerse cuando se cumple una condición. Si los informes regresan siempre a la misma persona y esa persona decide qué entra, el nodo decisivo sigue siendo humano. Yo había automatizado una cadena de revisiones y la llamaba bucle. El bucle empieza cuando el estado de los hallazgos, la nueva ejecución y una condición de parada verificable deciden si hay que corregir, repetir o detenerse.

El cambio de nombre puede parecer menor, pero importa. En una cadena, una persona ve cada vuelta y puede desconfiar. En cambio, dentro de un ciclo desatendido la condición de parada forma parte del producto y el verde tiene que significar algo comprobable.

Primer falso verde: quien corrige también integra

Mi proceso sí separaba redacción y auditoría. Los revisores recibían el texto sin el historial de escritura y devolvían hallazgos. Después, esos informes volvían a mí. Yo aceptaba o rechazaba cada punto, escribía el parche y decidía si el conjunto quedaba resuelto.

La separación terminaba justo antes de la decisión importante.

Una auditoría detectó una imprecisión sobre el comportamiento de una herramienta. Al corregirla introduje una afirmación directamente falsa. El cambio sobrevivió a una revisión posterior porque quien acababa de escribirlo también interpretaba si el hallazgo estaba cerrado. No hacía falta mala fe ni un modelo complaciente. El conflicto estaba en el papel: quien produce una corrección conoce lo que quería conseguir y tiende a leer el resultado como si ese propósito estuviera ya en el texto.

Añadir un revisor solo resuelve el conflicto si su decisión condiciona el cierre. Como mínimo deben separarse dos responsabilidades: el productor propone y un revisor independiente verifica y aprueba. La integración es una ejecución posterior y nunca puede saltarse esa aprobación:

El integrador no tiene que ser siempre otro agente: puede ser una persona, una prueba determinista o una combinación. En cualquier caso, debe conservar una entrada distinta y autoridad real para rechazar. Si el informe solo aconseja y el productor firma, el circuito sigue abierto en el mismo punto.

Segundo falso verde: el encargo decide cuánto puede ver el auditor

Mis primeros encargos de revisión tenían entre quince y treinta líneas y pedían informes breves. Parecía una medida de higiene: menos coste, menos texto, más fácil integrar. El límite se convirtió en un techo invisible.

Sobre el mismo artículo, los encargos recortados produjeron informes cortos. Al usar instrucciones completas y retirar el cupo, la siguiente ronda encontró un hallazgo crítico, catorce altos y alrededor de veinte medios. No es un experimento controlado: cambiaron varias partes del encargo y no puedo atribuir la diferencia a una sola frase. Sí demuestra algo más modesto y suficiente: había defectos reales que el proceso anterior no exponía.

Pedir «los tres problemas principales» o limitar el informe a quince líneas no demuestra que solo existan tres defectos ni que la pieza esté casi lista. Solo demuestra que el auditor sabe priorizar dentro del espacio disponible. Yo estaba usando una restricción de salida como señal de calidad del objeto revisado.

La solución consiste en separar el descubrimiento de la síntesis, no en aceptar informes interminables. El auditor registra todos los hallazgos con severidad, fragmento, evidencia y propuesta; después, otra vista los agrupa, prioriza y resume para decidir. Resumir antes de conservar el inventario destruye justo la evidencia que el ciclo necesita en la vuelta siguiente.

Regla práctica El presupuesto de una auditoría puede limitar coste y tiempo; nunca debe convertirse en un límite silencioso sobre cuántos defectos existen.

Tercer falso verde: la comprobación se cree el registro

Después de detectar que un fichero de metadatos contradecía el texto, añadí una comprobación automática. El control leía una clave que no existía. Como recibía una cadena vacía, la condición nunca se activaba y el proceso seguía en verde con la contradicción delante.

El guardarraíl estaba escrito, tenía nombre y se ejecutaba. No observaba el dato que decía observar.

El mismo patrón apareció en otras formas. Una puerta ausente del registro contaba como pasada y un veredicto inventado escapaba por la rama positiva porque no coincidía con «falla». Además, una revisión respaldada por una herramienta podía sellarse a mano sin volver a ejecutarla. Todas las comprobaciones respondían correctamente a una representación ideal del sistema, pero ninguna había visto el defecto real.

La mejora decisiva fue probar cada control mediante inyección de fallos. La prueba parte de un bundle válido, introduce un solo defecto y exige que la salida se vuelva roja por ese motivo. Después se restaura la línea base y se inyecta el siguiente. Si el post ya estaba bloqueado por otra causa, una prueba nueva podía «pasar» aunque no detectara nada; por eso la línea base publicable es parte de la prueba.

El banco local de pruebas incluye valores de veredicto inventados, puertas ausentes o duplicadas, hashes que no corresponden, revisores inválidos y figuras sin especificar. También cubre fuentes sin verificar, actas de relleno, metadatos ausentes, enlaces inseguros y activos sin procedencia. Cada caso registra la mutación introducida, el rechazo esperado y el resultado observado; superarlos no demuestra una cobertura total.

El ciclo necesita un criterio externo de verdad

Los tres falsos verdes comparten una forma: el sistema pregunta a su propio estado si está bien.

• el productor dice que la corrección ya resuelve el informe;
• el encargo corto produce pocos hallazgos y eso se interpreta como pocos defectos;
• el registro dice que una puerta pasó y el publicador lo acepta sin repetir la comprobación.

Falta un criterio que no dependa de la declaración examinada. En las pruebas de software suele llamarse oráculo al mecanismo que permite saber qué resultado debería producir un caso. Aquí prefiero hablar de evidencia externa al paso: una ejecución, una fuente primaria, un hash, un esquema, una segunda lectura o un defecto inyectado que el propio paso no pueda fabricar escribiendo «pasa».

Abrir la imagen a tamaño completo

Una condición de parada defendible puede combinar varias pruebas:

Esta última fila conecta con una idea que desarrollo en cómo verificar el resultado de una automatización con IA: terminar el proceso no equivale a obtener el resultado.

Qué cambié en el sistema

Las lecciones solo valen si alteran el diseño, y en este caso dejaron cuatro garantías nuevas en el taller editorial.

La primera es un vocabulario cerrado de revisores por puerta. El sistema rechaza un firmante inválido en el momento de sellar, no minutos después al publicar. La segunda es que las actas bloqueantes deben citar el hash del texto, declarar veredicto y hallazgos y superar una comprobación contra relleno. Un informe excelente sobre una versión anterior no vale para la actual.

La tercera es que las puertas respaldadas por una herramienta se reejecutan. El linter no se considera aprobado porque post.json diga que pasó: el publicador lo ejecuta de nuevo. La cuarta es el conjunto de cuarenta pruebas adversarias, con una línea base válida y un defecto por prueba.

No todas las puertas necesitan independencia. Comprobar dimensiones o validar JSON puede ser determinista. Las que interpretan propósito, evidencia o riesgo sí necesitan separación o, cuando no es posible, deben declarar que la revisión fue secuencial. Ocultar esa limitación sería otro falso verde.

Por qué importa en plataformas de aprendizaje

Un ciclo editorial puede publicar una frase incorrecta. Un ciclo conectado a una plataforma educativa puede cambiar una matrícula, reescribir contenido, proponer retroalimentación, migrar cursos o abrir incidencias sobre alumnado. La misma arquitectura de falsos verdes adquiere una consecuencia mayor.

Pensemos en un ciclo que revisa cada noche cursos nuevos. Un agente detecta barreras de accesibilidad, otro propone cambios y un tercero publica. Si el revisor recibe solo los cinco hallazgos principales, el resumen oculta el resto. Si la corrección automática es aceptada por el mismo agente que la redactó, una alternativa textual peor puede cerrar la incidencia. Si la comprobación mira el estado «revisado» en vez de recorrer el curso, el ciclo termina produciendo verde sin producir accesibilidad.

La regla es la misma que para código generado por IA: la velocidad de producción no mide ingeniería. El artículo sobre por qué generar código no es ingeniar software explica la diferencia entre cambio producido y cambio validado. Loop Engineering lleva esa frontera al sistema que decide el siguiente cambio.

Cinco preguntas para saber si el verde significa algo

Estas son las preguntas que ahora uso para revisar un ciclo:

1. ¿Qué hecho observable detiene la vuelta? «El agente terminó» o «el registro está verde» no describen el artefacto correcto.
2. ¿Quién comprueba el cambio del productor? Si la respuesta vuelve al mismo papel, la independencia termina antes de la integración.
3. ¿Qué puede dejar fuera el encargo? Límites de hallazgos, brevedad y resúmenes prematuros reducen la superficie observada.
4. ¿Hemos ejecutado el control con el defecto delante? La prueba necesita línea base válida, fallo único y motivo específico de rechazo.
5. ¿Qué sabe la siguiente vuelta y de dónde sale? El estado debe conservar intentos, evidencia, decisiones y caducidad; copiar el resumen del propio agente solo acumula afirmaciones.

Las especificaciones ayudan a fijar el resultado, pero tampoco sustituyen la arquitectura ni la prueba. En Spec-Driven Development explico cómo hacer observable el resultado esperado antes de delegarlo.

El resultado después de recorrer el ciclo completo

El primer borrador de esta nota terminaba con una fotografía incómoda: dieciocho bundles dentro del taller, una sola pieza con las dieciséis puertas y cero publicaciones. Aquella imagen, cierta el 26 de julio, demostraba que automatizar la revisión no había automatizado la producción.

Dos días después, antes de publicar esta nota, el sitio tenía catorce artículos exportados y el banco de pruebas adversarias pasaba. Entre ambas fechas terminé piezas completas, retiré borradores sin propósito propio y vinculé cada verde al artefacto actual. La comparación no permite aislar qué parte del cambio corresponde a cada intervención.

Ese avance solo demuestra que el bucle ya no aprueba en silencio los errores que lo obligaron a cambiar, no que sea correcto frente a fallos que aún no ha visto.

Loop Engineering me permite ejecutar el criterio de forma repetible cuando ya está escrito, tiene una evidencia distinta de la declaración y ha fallado en rojo al menos una vez, pero no me lo ahorra. Lo demás sigue siendo actividad automatizada con una luz verde bonita.

Última revisión: 28 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de software, inteligencia artificial aplicada y plataformas de aprendizaje. Publica notas de construcción cuando el sistema ha fallado lo suficiente como para dejar una prueba, no solo una opinión.