Habr AI: cómo Pipeline Triad monta un pipeline de agentes de IA en lugar de un equipo de desarrollo

La idea de un único desarrollador de IA universal cede poco a poco ante un esquema más práctico: en lugar de un «superagente», un pipeline de tríos especializados, donde un agente genera el resultado, otro busca errores y un tercero decide. Así funciona el Pipeline Triad Pattern, un modelo de desarrollo pensado no para demos sino para tareas empresariales típicas, en las que los requisitos, estándares y reglas ya están descritos y la persona conserva el control en unos pocos puntos del proceso, los más costosos.

El esquema se apoya en tres roles: Creador, Crítico y Árbitro. El primero genera un artefacto, el segundo revisa la lógica, la calidad y los riesgos, y el tercero decide si el resultado avanza o vuelve a revisión. El enfoque parte de una idea simple: los modelos de lenguaje corrigen mal sus propios errores sin una verificación externa, así que es más fiable no reforzar indefinidamente a un solo agente, sino montar un trío independiente con funciones distintas. El autor del patrón traslada al desarrollo con agentes el conocido principio empresarial maker-checker-approver y lo extiende a todo el SDLC.

Pipeline Triad no se plantea como sustituto de CI/CD. Los pipelines automáticos siguen compilando, probando y desplegando el código, pero por encima aparece otra capa: la de delegación a agentes, donde las decisiones no se toman con un script rígido, sino teniendo en cuenta el contexto, los reglamentos y las reglas de negocio.

El esquema completo consta de 14 pasos, desde el planteamiento de la tarea hasta producción. Siete son etapas de agentes: análisis, desarrollo, code review, pruebas, regresión, seguridad y preparación de los artefactos de la versión. Otros cuatro puntos quedan en manos humanas: validación de requisitos, aprobación de la preparación, confirmación del despliegue y verificación final antes de producción.

En cada etapa el trío debe entregar no solo una respuesta de texto, sino un paquete formalizado: el propio artefacto, criterios PASS o FAIL, el registro de observaciones del Crítico y la decisión del Árbitro: aprobar, devolver o aprobar parcialmente. Así, el pipeline pasa de ser un conjunto de prompts a un proceso reproducible con trazabilidad de decisiones. La siguiente etapa no arranca hasta recibir una entrada válida, de modo que se pueden montar auditorías, medir la calidad y analizar los errores a posteriori.

El valor práctico del patrón se ve mejor en una tarea típica. Como ejemplo, el autor toma un endpoint bancario para congelar una cuenta. Primero el trío aclara los requisitos y los casos límite. Después, tríos distintos escriben el código, comprueban los permisos de acceso, añaden pruebas de condiciones de carrera y ejecutan regresión y seguridad. Tras ello, la persona solo confirma unas pocas decisiones clave. En este escenario, la participación humana se estima en aproximadamente una hora en total, frente a dos o tres semanas en un proceso empresarial clásico.

En cuanto al coste, el autor calcula que una ejecución completa vía API supone unas 42–84 llamadas al modelo, 1–2 millones de tokens de entrada y 200–400 mil de salida, lo que da una referencia de unos 6–12 dólares por tarea. Para pilotos y entornos personales una suscripción puede salir más barata, pero para un flujo de producción estable habrá que seguir calculando límites, presupuesto y consumo real de tokens.

El modelo, con todo, tiene límites claros. Encaja bien con change requests, bugfixes, tareas CRUD y de API, integraciones y cambios de infraestructura, donde el dominio está formalizado y el resultado se puede verificar con pruebas y artefactos. Pipeline Triad funciona peor donde hay mucha incertidumbre: discovery, arquitectura greenfield sin estándares maduros, I+D y grandes refactorizaciones entre equipos.

Los riesgos también son bastante terrenales: un agente puede inventarse una regla de negocio inexistente, un Crítico mal configurado dejará pasar errores o rechazará todo, y el trabajo en paralelo de varias tareas chocará rápido con conflictos de contexto, migraciones y ramas.

La seguridad del propio pipeline es un capítulo aparte. Si se da a los agentes acceso al repositorio, a los secretos y al despliegue sin restricciones estrictas, el nuevo proceso se convierte en una superficie de ataque adicional. Por eso el autor insiste en el principio de mínimo privilegio, permisos separados por rol, un audit log completo, un policy engine para el uso de herramientas y el filtrado de datos sensibles antes de que lleguen al contexto del modelo.

Qué significa esto en la práctica: la idea de un «equipo de agentes» deja de ser una fantasía sobre un empleado de IA universal y pasa a ser un modelo de ingeniería más aterrizado, donde la aceleración se logra con especialización, entradas formalizadas y control en los pasos costosos. Pero el material también muestra con honestidad los límites del enfoque: no elimina las aprobaciones organizativas, no resuelve el problema de un planteamiento deficiente y no libera de responsabilidad a las personas con experiencia que deben validar el resultado. Si estos pipelines llegan a ser un estándar de trabajo, lo serán primero en dominios empresariales predecibles, donde el coste del error es alto y las reglas ya se pueden convertir en un proceso verificable.