Contexte et objectifs

Sur une période de cinq mois, Cockroach Labs a expérimenté un pipeline d’agents de codage structuré autour de la métaphore d’un hôpital universitaire. L’enjeu était de garantir que les agents, capables de générer du code rapidement, produisent un résultat comparable à du code révisé par des humains, notamment pour les migrations de bases de données critiques. L’objectif principal était de réduire les régressions tout en conservant la capacité d’automatiser des tâches complexes comme le support de nouveaux dialectes SQL.

Architecture du pipeline hospitalier

Le flux s’appuie entièrement sur GitHub Actions. Chaque « patient » correspond à une issue GitHub ; son état est stocké dans les labels et des fichiers temporaires. Les rôles sont définis comme suit : Triage Nurses évaluent la taille du problème, Fellows décomposent les tâches en sous‑issues, Review Attendings valident les PR, et Discharge Nurses finalisent le merge. Autour de ce noyau, un Charge Nurse surveille les blocages toutes les trente minutes, un Infection Control peut verrouiller le workflow en cas d’échec, le Safety Department rédige des revues de processus hebdomadaires, et le Research Department propose de nouvelles améliorations. Cette hiérarchie impose des hand‑offs obligatoires et des revues multiples avant chaque intégration.

Performances et métriques

Durant l’expérimentation, plus d’un million de lignes de code ont été traitées avec seulement sept reverts. Le support du dialecte IBM Db2 a été ajouté en moins de deux jours, sans intervention humaine directe. Le coût d’exécution s’est élevé à 4 172 $ de tokens, soit 164 fois plus rapide et 38 fois moins cher que le support Oracle réalisé en 2024 (9 mois, 160 k$). Le processus a généré 32 sous‑issues, 27 pull requests fusionnées, 55 retours de revue et 9 escalades, dont 2

Analyse des limites et perspectives

Le modèle hospitalier introduit une bureaucratie notable : les temps d’attente entre les étapes et le coût opérationnel des multiples agents. Bien que le nombre de réverts soit faible, chaque escalade humaine représente un point de friction potentiel. De plus, la dépendance exclusive à GitHub Actions peut limiter la portabilité vers d’autres environnements CI/CD. Enfin, l’absence de métriques détaées sur la latence individuelle des agents empêche d’évaluer précisément le compromis entre throughput et latence. Malgré ces contraintes, l’expérience montre que des workflows fortement orchestrés peuvent concilier automatisation à grande échelle et exigences de fiabilité propres aux bases de données d’entreprise.