Cockroach Labs : cinq mois à traiter les bogues comme des patients et les agents de code comme une équipe médicale

Un mercredi soir d'avril, MOLT, l'outil que Cockroach Labs fournit pour migrer des bases de données vers CockroachDB, ne savait pas encore lire IBM Db2. Le vendredi après-midi, il le savait. Db2 est l'une des premières bases relationnelles commerciales. Son dialecte SQL est riche, son système de types est complexe et il possède un protocole natif. Le prendre en charge exigeait un nouveau convertisseur de schéma, un nouveau chemin Fetch pour extraire les lignes et les charger dans CockroachDB, un nouveau chemin Verify pour les comparer après chargement, une grammaire ANTLR intégrée, une image Docker pour la CI et plus de dix mille lignes de jeux de test. Lorsque l'équipe a ajouté la prise en charge d'Oracle à MOLT en 2024, le travail équivalent avait duré neuf mois et coûté environ 160 000 dollars de temps d'ingénierie. Le travail sur Db2 a pris moins de deux jours, et aucun humain n'a écrit une ligne de code. La facture de tokens s'élève à 4 172 dollars, soit 164 fois plus vite et 38 fois moins cher.

Tout est parti d'une seule issue GitHub décrivant la demande. Un agent de planification l'a lue, a jugé qu'elle était trop vaste pour être traitée d'un bloc et l'a découpée en quinze sous-issues, avec un graphe de dépendances explicite : d'abord les fondations, puis le système de types, l'itérateur de lignes, Fetch, Verify et Convert, enfin la CI et les données de test. Deux sous-issues ont été jugées trop grosses dans leur propre analyse et ont été redécoupées. En cours de route, les agents ont ouvert une douzaine d'issues supplémentaires sur leur propre travail : des lacunes dans les jeux de test, un bogue de correspondance de types et un correctif de niveau d'isolation. Personne n'a détecté ces problèmes à la main. Le pipeline les a trouvés, consignés et mis en file. Découper le travail et rendre les dépendances explicites est la première raison pour laquelle une tâche de cette taille a pu aboutir en deux jours. La deuxième raison tient à l'organisation du pipeline. Cockroach Labs a choisi comme métaphore directrice l'hôpital universitaire. Chaque bogue est un patient, et chaque agent de code joue un rôle dans une équipe médicale. Les infirmiers de tri reçoivent et filtrent les demandes : ils déterminent la nature du problème, son ampleur et la personne qui doit s'en charger. Les fellows assurent le traitement concret, c'est-à-dire l'écriture du correctif. Les médecins référents de relecture mènent une revue rigoureuse et gardent la qualité. Les infirmiers de sortie clôturent le dossier et vérifient que tous les contrôles et tous les enregistrements sont en place avant la fusion. Cette métaphore n'est pas un ornement. Elle prend une répartition des tâches et un système de contrôles que les équipes logicielles savent nécessaires, et elle les fige dans un processus que chacun comprend. Un hôpital ne laisse pas celui qui a soigné le patient valider seul son propre traitement. Un pipeline d'agents ne respectera cette règle que si quelqu'un la conçoit expressément.

La troisième raison est une courte liste de disciplines strictes. Les agents doivent planifier avant d'écrire du code, et le plan lui-même est relu, afin qu'une mauvaise direction soit arrêtée avant que des tokens soient dépensés sur des milliers de lignes. Une couverture de tests rigoureuse est une condition de la fusion, et non un ajout après coup. Une tenue de dossier méticuleuse garantit que chaque décision et chaque modification laissent une trace, comme dans un dossier médical, et cette trace est le seul moyen de comprendre plus tard pourquoi une modification a été annulée. Des garde-fous de sécurité précèdent la fusion. Ces règles paraissent simples, mais elles visent précisément les endroits où les agents échouent le plus souvent : un objectif mal compris, une confiance imméritée et une production dont personne n'est responsable. La mesure la plus convaincante de la fiabilité d'un tel système est le nombre d'annulations. En cinq mois, le pipeline a traité plus d'un million de lignes de code et n'a provoqué que sept annulations (reverts). Ce chiffre suggère que production autonome et fiabilité de niveau entreprise ne sont pas forcément en conflit, à condition d'inscrire la fiabilité dans la structure du système plutôt que d'espérer qu'un seul modèle soit assez intelligent. Les mêmes mécanismes soutiennent des fonctions comme le Migration Assistant. Lorsque des migrations de bases de données complexes sont construites et maintenues par des agents, la revue de planification, la couverture de tests et la tenue complète des enregistrements sont les principales défenses contre des régressions coûteuses. Une lecture honnête demande aussi de la prudence : les chiffres proviennent de Cockroach Labs lui-même, et la comparaison avec le projet Oracle, neuf mois et environ 160 000 dollars, est une estimation de l'entreprise. C'est une étude de cas solide, pas une référence universelle.

Pour l'ensemble du secteur, l'article change la question. Pendant longtemps, on demandait quel modèle écrit le meilleur code. Ce cas en suggère une plus utile : comment organiser un groupe d'agents pour qu'ils se répartissent le travail, se relisent mutuellement, laissent une trace et conservent une chaîne de responsabilité claire en cas d'erreur ? Quand le coût passe de neuf mois à deux jours, et de 160 000 dollars à un peu plus de 4 000, le goulot d'étranglement quitte l'acte de coder. Il se déplace vers la description du besoin, le découpage des tâches et la recette. Les équipes qui visent des résultats comparables devraient d'abord investir dans le découpage, le processus de revue et l'infrastructure de test, et ensuite seulement chercher un modèle plus puissant. La métaphore hospitalière marque les esprits, mais la leçon est de l'ingénierie ordinaire : donner un responsable à chaque étape, tout consigner, et ne rien fusionner avant que les contrôles passent.