Habr AI: Cómo Pipeline Triad Arma un Pipeline de Agentes IA en Lugar de un Equipo de Desarrollo

La idea de un único desarrollador IA universal está cediendo gradualmente a un esquema más práctico: en lugar de un "superagente," se propone un pipeline de tríos especializados, donde un agente crea el resultado, el segundo busca errores y el tercero toma una decisión. Exactamente así funciona el Pipeline Triad Pattern — un modelo de desarrollo diseñado no para demostraciones, sino para tareas enterprise típicas donde los requisitos, estándares y reglas ya están descritos, y el humano permanece en control en varios de los puntos más costosos del proceso. El esquema se construye sobre tres funciones: Creador, Crítico y Árbitro.

La primera genera un artefacto, la segunda verifica lógica, calidad y riesgos, y la tercera decide si pasar el resultado adelante o devolverlo para revisión. Este enfoque se basa en una idea simple: los modelos de lenguaje son malos corrigiendo sus propios errores sin verificación externa, por lo que es más confiable no fortalecer un agente infinitamente, sino construir un trío independiente con funciones diferentes. El autor del patrón transfiere al desarrollo con agentes el familiar principio enterprise de maker-checker-approver y lo extiende por todo el SDLC.

Al mismo tiempo, Pipeline Triad no se propone como reemplazo de CI/CD. Los pipelines automáticos siguen construyendo, probando e implementando código, pero sobre ellos aparece otra capa — una capa de delegación de agentes, donde las decisiones se toman no por script rígido, sino teniendo en cuenta contexto, regulaciones y reglas de negocio. El esquema completo consta de 14 pasos desde la declaración de la tarea hasta producción.

Siete de ellos ejecutan etapas de agente: análisis, desarrollo, revisión de código, pruebas, regresión, seguridad y preparación de artefactos de lanzamiento. Otros cuatro puntos permanecen con el humano: validación de requisitos, aprobación de disponibilidad, confirmación de implementación y verificación final previa a producción. En cada etapa, el trío debe entregar no solo una respuesta textual, sino un paquete formalizado: el artefacto en sí, criterios PASS o FAIL, un registro de observaciones del Crítico, así como la decisión del Árbitro — pasar, devolver o realizar parcialmente.

Debido a esto, el pipeline se transforma de un conjunto de prompts en un proceso reproducible con trazabilidad de decisiones. La siguiente etapa no inicia hasta recibir entrada válida, lo que significa que puede construir auditoría, medir calidad y analizar errores retrospectivamente. El valor práctico del patrón se ve mejor en una tarea típica.

Por ejemplo, el autor toma un endpoint bancario para congelación de cuenta: primero, el trío aclara requisitos y casos extremos, luego tríos separados escriben código, verifican derechos de acceso, añaden pruebas para condiciones de carrera, ejecutan verificaciones de regresión y seguridad, después de lo cual una persona solo confirma algunas decisiones clave. En tal escenario, la participación humana se estima en aproximadamente una hora de tiempo total versus dos a tres semanas en un proceso enterprise clásico. En términos de costo, el autor estima una ejecución completa a través de la API en aproximadamente 42–84 llamadas de modelo, 1–2 millones de tokens de entrada y 200–400 mil tokens de salida, lo que da una estimación de orden de magnitud de $6–12 por tarea.

Para pilotos y configuraciones personales, una suscripción puede ser más barata, pero para un flujo de producción estable, aún necesitará contar límites, presupuesto y consumo real de tokens. Al mismo tiempo, el modelo tiene límites duros. Funciona bien para solicitudes de cambio, correcciones de bugs, tareas CRUD y API, integraciones y cambios de infraestructura, donde el dominio está formalizado y el resultado puede verificarse mediante pruebas y artefactos.

Pipeline Triad funciona peor donde hay mucha incertidumbre: en descubrimiento, arquitectura greenfield sin estándares maduros, I+D y grandes refactorizaciones entre equipos. Los riesgos también son bastante terrenales: un agente puede inventar una regla de negocio inexistente, un Crítico mal configurado dejará pasar errores o rechazará todo de seguido, y el trabajo paralelo en múltiples tareas rápidamente encontrará conflictos de contexto, migraciones y ramas. Una sección separada es la seguridad del propio pipeline.

Si se da a los agentes acceso al repositorio, secretos e implementación sin restricciones estrictas, el nuevo proceso se convierte en una superficie de ataque adicional. Por lo tanto, el autor insiste en el principio de menor privilegio, acceso separado basado en roles, registro de auditoría completo, un motor de política para uso de herramientas y filtrado de datos sensibles antes de que entren en el contexto del modelo. ¿Qué significa esto en la práctica?

: la idea de un "equipo de agentes" se convierte no en una fantasía sobre un empleado IA universal, sino en un modelo de ingeniería más fundamentado, donde la aceleración se logra mediante especialización, entradas formalizadas y control en etapas costosas. Pero el material honestamente muestra los límites del enfoque: no elimina la alineación organizacional, no resuelve el problema de especificación pobre de requisitos y no elimina la responsabilidad de personas fuertes que deben validar el resultado. Si tales pipelines se convierten en un estándar de trabajo, será primero en dominios enterprise predecibles donde el costo del error es alto y las reglas ya pueden convertirse en un proceso verificable.