Loop engineering y razas de modelos: la jerga que define la operacion de agentes en 2026

GitHub publica una guia para navegar la terminologia que ha invadido los equipos de desarrollo con la adopcion masiva de agentes de IA. El objetivo del articulo, basado en un episodio reciente de su podcast, es distinguir entre conceptos que representan patrones arquitectonicos reales y otros que son simplemente renombres de practicas existentes o marketing vacio. Para un ingeniero de sistemas o un CTO, entender estas distinciones es critico para decidir como integrar estas herramientas en la infraestructura sin caer en la ineficiencia.

El concepto central es el 'loop engineering'. Se trata de dejar de lado el modelo de interaccion puntual (un prompt, una respuesta) para disenar sistemas repetibles y automatizados alrededor de los agentes. Un ejemplo practico seria sustituir la revision manual de incidencias por un proceso programado que obtenga issues, los pase a un agente, valide la salida y escalo lo que falle. GitHub lo describe con franqueza: es esencialmente un cron job nativo para IA, pero con la complejidad adicional de gestionar el estado y la validacion de la salida del modelo.

Dentro de este ambito, se menciona el 'Ralph loop' como una implementacion especifica y, a menudo, brutal. Consiste en dar a un agente una tarea compleja y obligarlo a iterar (planificar, actuar, verificar) hasta completarla. Aunque puede ser util para descomponer trabajos grandes, conlleva un coste elevado en computo y tokens. La recomendacion tecnica es evitar depender de este enfoque de fuerza bruta y, en su lugar, disenar loops estructurados que incluyan primitives como habilidades especificas, observabilidad, enrutamiento y puntos de control para reducir el consumo de recursos y aumentar la fiabilidad.

Multiplicidad y contencion

La orquestacion de multiples agentes se clasifica en 'squads' y 'fleets'. Un squad agrupa agentes con roles diferenciados que reflejan un equipo humano: uno planifica, otro implementa, otro prueba. Un fleet, por su parte, se refiere a la ejecucion paralela de agentes. La ventaja operativa aqui es la especializacion y la paralelizacion; en lugar de cargar a un unico LLM con todo el contexto, se distribuye la carga segun la capacidad de cada nodo del sistema.

El termino 'harness' (o arnes) describe la capa de software que rodea al modelo para hacerlo util: herramientas, permisos, memoria y contexto. GitHub usa la analogia del caballo para explicarlo: el modelo es la fuerza bruta que puede salirse de control, y el harness es lo que dirige esa energia de forma segura. Herramientas como GitHub Copilot son ejemplos de harnesses que conectan modelos a repositorios, terminales y pull requests. El 'harness engineering' es, pues, el trabajo de integrar y afinar esta capa intermedia.

Por ultimo, el articulo aclara la distincion entre tipos de modelos, crucial para las decisiones de licenciamiento y despliegue. Los modelos cerrados solo se acceden via API. Los 'open weights' permiten descargar y ejecutar los pesos del modelo localmente, aunque el dataset y el metodo de entrenamiento puedan seguir siendo propietarios. Los verdaderos modelos 'open source' exponen codigo, datos, pesos y proceso de entrenamiento, permitiendo una auditoria completa y mayor confianza en la seguridad y el cumplimiento normativo. La jerga sigue evolucionando, pero estos terminos marcan ya la linea entre la experimentacion casual y la ingenieria de produccion.