Habr AI : Comment Pipeline Triad Construit un Pipeline d'Agents IA Plutôt qu'une Équipe de Développement

L'idée d'un unique développeur IA universel cède graduellement la place à un schéma plus pratique : au lieu d'un « superagent », un pipeline de trios spécialisés est proposé, où un agent crée le résultat, le deuxième recherche les erreurs et le troisième prend une décision. C'est exactement ainsi que fonctionne le Pipeline Triad Pattern — un modèle de développement conçu non pour les démonstrations, mais pour les tâches enterprise typiques où les exigences, normes et règles sont déjà décrites, et l'humain reste en contrôle aux plusieurs points les plus coûteux du processus. Le schéma repose sur trois rôles : Créateur, Critique et Arbitre.

Le premier génère un artefact, le deuxième vérifie la logique, la qualité et les risques, et le troisième décide s'il faut laisser passer le résultat ou le renvoyer pour révision. Cette approche s'appuie sur une idée simple : les modèles de langage sont mauvais pour corriger leurs propres erreurs sans vérification externe, il est donc plus fiable de ne pas renforcer un agent indéfiniment, mais de construire un trio indépendant avec des fonctions différentes. L'auteur du pattern transfère au développement d'agents le principe enterprise familier de maker-checker-approver et l'étend sur tout le SDLC.

En même temps, Pipeline Triad n'est pas proposé comme remplacement de CI/CD. Les pipelines automatiques continuent de construire, tester et déployer du code, mais au-dessus d'eux apparaît une autre couche — une couche de délégation d'agents, où les décisions sont prises non par un script rigide, mais en tenant compte du contexte, des régulations et des règles métier. Le schéma complet comprend 14 étapes de la déclaration de la tâche à la production.

Sept d'entre elles exécutent des étapes d'agents : analyse, développement, révision de code, tests, régression, sécurité et préparation des artefacts de version. Quatre autres points restent à l'homme : validation des exigences, approbation de disponibilité, confirmation du déploiement et vérification finale avant production. À chaque étape, le trio doit livrer non seulement une réponse textuelle, mais un package formalisé : l'artefact lui-même, des critères PASS ou FAIL, un journal des remarques du Critique, ainsi que la décision de l'Arbitre — accepter, rejeter ou exécuter partiellement.

Grâce à cela, le pipeline se transforme d'un ensemble de prompts en un processus reproductible avec traçabilité des décisions. L'étape suivante ne démarre que lorsqu'elle reçoit une entrée valide, ce qui signifie que vous pouvez construire un audit, mesurer la qualité et analyser les erreurs rétrospectivement. La valeur pratique du pattern est mieux vue sur une tâche typique.

Par exemple, l'auteur prend un endpoint bancaire pour le gel de compte : d'abord, le trio clarifie les exigences et les cas limites, puis des trios séparés écrivent du code, vérifient les droits d'accès, ajoutent des tests pour les conditions de course, exécutent des vérifications de régression et de sécurité, après quoi une personne confirme seulement quelques décisions clés. Dans un tel scénario, la participation humaine est estimée à environ une heure de temps total contre deux à trois semaines dans un processus enterprise classique. En termes de coût, l'auteur estime une exécution complète via l'API à environ 42–84 appels de modèle, 1–2 millions de tokens d'entrée et 200–400 mille tokens de sortie, ce qui donne une estimée d'ordre de grandeur de $6–12 par tâche.

Pour les pilotes et les configurations personnelles, un abonnement peut être moins cher, mais pour un flux de production stable, vous aurez toujours besoin de compter les limites, le budget et la consommation réelle de tokens. En même temps, le modèle a des limites strictes. Il fonctionne bien pour les demandes de changement, les corrections de bugs, les tâches CRUD et API, les intégrations et les changements d'infrastructure, où le domaine est formalisé et le résultat peut être vérifié par des tests et des artefacts.

Pipeline Triad fonctionne le pire où il y a beaucoup d'incertitude : en découverte, architecture greenfield sans normes matures, R&D et grands refactorisations entre équipes. Les risques sont aussi bien terrestres : un agent peut inventer une règle métier inexistante, un Critique mal configuré laissera passer les erreurs ou rejettera tout d'affilée, et le travail parallèle sur plusieurs tâches se heurtera rapidement à des conflits de contexte, des migrations et des branches. Une section distincte est la sécurité du pipeline lui-même.

Si les agents reçoivent un accès au référentiel, aux secrets et au déploiement sans restrictions strictes, le nouveau processus devient une surface d'attaque supplémentaire. Par conséquent, l'auteur insiste sur le principe du moindre privilège, un accès basé sur les rôles séparé, un journal d'audit complet, un moteur de politique pour l'utilisation d'outils et un filtrage des données sensibles avant qu'elles n'entrent dans le contexte du modèle. Que signifie cela en pratique : l'idée d'une « équipe d'agents » devient non pas une fantaisie sur un employé IA universel, mais un modèle d'ingénierie plus ancré dans la réalité, où l'accélération est réalisée par la spécialisation, les entrées formalisées et le contrôle aux étapes coûteuses.

Mais le matériel montre honnêtement les limites de l'approche : elle n'élimine pas l'alignement organisationnel, ne résout pas le problème de la mauvaise spécification des exigences et n'enlève pas la responsabilité des personnes fortes qui doivent valider le résultat. Si de tels pipelines deviennent un standard de travail, ce sera d'abord dans les domaines enterprise prévisibles où le coût d'une erreur est élevé et les règles peuvent déjà être converties en un processus vérifiable.