Bucles en vez de peticiones: qué es la ingeniería de bucles para agentes

La ingeniería de instrucciones consiste en redactar una petición inicial lo más perfecta posible, enviarla a un gran modelo de lenguaje, esperar la respuesta y luego escribir a mano la siguiente petición. La ingeniería de bucles cambia la lógica: diseña un sistema que redacta por sí mismo esas peticiones sucesivas. El sistema envía una consigna a un agente, revisa el resultado y vuelve a solicitarle trabajo, una y otra vez, hasta alcanzar el fin previsto, con una intervención humana mínima.

El vídeo ilustra el bucle con un servicio de pago cuyas pruebas unitarias están fallando. El ciclo tiene cuatro tiempos: definir un objetivo, actuar, observar el resultado y ajustar la conducta. El agente abre un archivo, modifica el código, ejecuta la batería de pruebas y lee los resultados: si una prueba pasa a verde, avanza a la siguiente; si sigue en rojo, intenta otra corrección. Después vuelve a la pregunta central, hemos terminado ya, y repite el giro.

Un objetivo difuso arruina el bucle, porque se evalúa en cada vuelta y decide si el proceso continúa o se detiene. Pedir un pago de mayor velocidad no ofrece ninguna prueba verificable, igual que un vago propósito de enero: el agente puede girar sin fin o proclamar la victoria tras una sola pasada. En cambio, exigir que todas las pruebas del servicio de pago terminen en verde aporta una condición de parada nítida y concreta, que el agente puede constatar sin ambigüedad.

Alrededor de este bucle sencillo se organiza toda una disciplina, que empieza por un disparador que pone en marcha el ciclo. Una programación calendarizada ejecuta el trabajo cada noche, a menudo mediante una tarea planificada clásica, mientras un gancho activado por eventos reacciona ante un hecho concreto, como un cambio en un archivo o la apertura de una solicitud de integración. Los equipos de desarrollo emplean estos ganchos para la seguridad y la calidad, con el fin de aplicar las normas antes de cada fusión.

Cada vuelta genera contexto: salidas de pruebas, contenidos de archivos y registros de ejecución, que se acumulan y dispersan la atención del agente. La ingeniería de contexto elige lo que el bucle debe ver realmente. Puede condensar los volúmenes, filtrar lo esencial o recurrir a la divulgación progresiva: una habilidad especializada aporta entonces el modo operativo de unas tareas repetidas, revelado solo en el momento útil, para mantener el campo de acción legible.

En el centro del bucle hay lo que el vídeo llama la columna vertebral, es decir, un estado persistente donde el agente anota lo que hizo y lo que funcionó. Bastan unos archivos de marcado ligero: guardan el rastro de los intentos, las correcciones eficaces y las vías sin salida. Releída en cada iteración, esta memoria orienta las decisiones siguientes, evita repetir los mismos errores y da al conjunto una continuidad que el mero contexto inmediato no permite. Mantenerla al día exige capacitación del equipo en hábitos de escritura claros.

Para actuar, el agente debe salir de su perímetro y tocar recursos externos: ejecutar código, recorrer el sistema de archivos, lanzar comandos en la terminal o consultar bases de datos. El acceso se realiza mediante herramientas, bien por llamada directa a una interfaz documentada, bien mediante un protocolo estándar que expone esas herramientas de modo uniforme. Bien delimitadas, convierten una intención expresada en lenguaje natural en operaciones concretas, controlables y registradas, ya se ejecuten en un servidor o en un portátil, con datos trazables y con el procesador justo para cada carga.

En la etapa de observación, dejar la verificación en manos del mismo agente que escribió el código crea un punto ciego. Una buena ingeniería recurre entonces a un segundo agente, un subagente verificador con sus propias instrucciones, su propio contexto y, a veces, un modelo distinto. Ese colega revisa el trabajo, señala fragilidades, asume comprobaciones delegadas y devuelve sus conclusiones. El bucle gana así una mirada independiente antes de decidir el paso siguiente.

Queda la pregunta del lugar del ser humano, porque un verificador automatizado sigue siendo un programa como cualquier otro: la responsabilidad del código entregado pertenece a las personas desarrolladoras. Cuando los agentes producen volúmenes enormes que nadie revisa a fondo, crece la brecha entre el código existente y lo que el equipo comprende de verdad. Esa deuda de comprensión sale cara ante un fallo urgente en producción o una migración estructurante, cuando hay que intervenir con velocidad sobre un conjunto vuelto opaco.

Otra deuda acecha: la deuda de intención. El agente ve lo que el sistema hace, pero capta peor por qué lo hace, salvo que los motivos estén escritos con claridad, por ejemplo en un archivo dirigido a los agentes. Sin ello, un arreglo técnicamente válido puede traicionar los objetivos, como relajar el control de un cupón de descuento para que pase una prueba, a costa de los ingresos del negocio. De ahí el papel humano: escribir el objetivo con su condición de parada, mantener visible la intención y revisar los resultados sin convertir al agente en un apoyo psicológico que todo lo valida.