Claude écrit, Gemini révise, ChatGPT sert de faire-valoir

L'IA mono-fournisseur paraît plus simple sur le papier et livre de la fragilité en pratique. RakuAI est construit par une boucle d'agents multi-fournisseurs - et construit pour que le modèle de n'importe quel fournisseur puisse le piloter. Le processus de développement reflète la thèse produit.

Samedi matin, café, et le flux de travail avant qu’il ne change encore. Quand je dis aux gens que je construis un moteur aux côtés d’agents de codage autonomes, la première question est « lequel ». La réponse honnête est « plusieurs, dans des rôles différents, et les répartitions du travail comptent ». Ce billet est la réponse plus longue.

En ce moment, le flux de travail de développement implique au moins trois fournisseurs IA distincts jouant des parties distinctes de la boucle. La raison n’est ni la loyauté ni le caprice. C’est que chaque modèle est authentiquement meilleur pour un type différent de travail, et essayer de faire faire tout par un seul modèle produit un code mesurablement pire.

Les rôles, aujourd’hui

Claude écrit la majeure partie du code runtime. Raisonnement à long contexte à travers une grande base de code, planification avant édition, garder beaucoup d’état dans une seule tête. C’est le modèle que je fais tourner sur la file d’issues pour le travail de sous-système substantiel. Quand une issue dit « implémenter un gestionnaire de couches de composition OpenXR et des espaces d’action », Claude est celui qui fait atterrir la PR.

Gemini révise la majeure partie des PR. Entraînement différent, angles morts différents. Quand Claude fait atterrir une PR, Gemini lit le diff et pousse en retour. Les types de commentaires que fait surface Gemini sont différents de ceux que je ferais surface manuellement. Certains sont du bruit. Certains sont utiles. Le rapport signal-bruit est assez bon pour que je fasse confiance à Gemini comme premier passage de revue sur chaque diff.

ChatGPT est là où je fais du rubber-ducking. Quand je suis coincé sur une décision architecturale et que je ne sais pas encore quelle direction elle devrait prendre, je réfléchis à voix haute avec ChatGPT. Le modèle n’écrit pas de code dans ce rôle. Il me pousse sur mes hypothèses, suggère trois cadrages alternatifs, et me laisse argumenter avec lui. C’est le rôle qu’un pair senior jouerait si j’en avais un. Je n’en ai pas actuellement. ChatGPT est la simulation.

Copilot est dans l’éditeur. C’est le rôle d’autocomplétion. Quand j’écris du code à la main (ce qui est moins fréquent que les gens ne le pensent, mais ça arrive), Copilot est le modèle dont je vois les suggestions dans l’IDE. Il est bon pour le travail de contexte local, les quatre prochaines lignes.

C’est le flux de travail. Quatre modèles, quatre rôles. Chacun est meilleur dans son rôle que les autres ne le seraient.

Pourquoi le multi-fournisseurs compte

Trois raisons.

Le plafond de capacité est différent par fournisseur. Si je faisais tourner un seul modèle pour chaque rôle, chaque faiblesse de ce modèle se manifesterait comme une faiblesse dans le processus de développement. Claude est excellent pour écrire. Moins excellent pour trouver des bugs dans sa propre écriture. Gemini est excellent pour trouver des bugs mais ce n’est pas le modèle que je laisserais planifier une refactorisation sans supervision. ChatGPT réfléchit bien aux questions architecturales ouvertes mais son code dans de vrais sous-systèmes n’est pas ce que je veux livrer. Chacun est le meilleur outil pour un créneau.

L’indépendance dans la revue est structurelle. La règle la plus importante sur laquelle je me suis arrêté est que le modèle qui écrit une PR ne peut pas être le modèle qui la révise. L’auto-révision n’est pas une révision. Faire faire le premier passage de revue par le modèle d’un fournisseur différent produit une indépendance d’architecture, de données d’entraînement, de modes de défaillance. Les bugs que Gemini attrape dans le code de Claude sont de vrais bugs qui auraient atterri autrement.

Aucun verrouillage sur un seul fournisseur. Le moteur est construit pour recevoir des directives de n’importe quel LLM cloud (couvert le mois dernier dans le travail sur le XRAssistantService). Le flux de travail de développement qui construit le moteur devrait correspondre à cette posture. Je ne veux pas que l’ingénierie de ce runtime dépende d’un fournisseur restant compétitif pour les cinq prochaines années. Aucun d’entre eux ne le restera. Ceux qui sont bons maintenant seront bons de façons différentes plus tard. Faire tourner un flux de travail multi-fournisseurs à la couche développement garde l’ingénierie portable.

Les coûts honnêtes

Quelques-uns.

La surcharge de coordination est réelle. Basculer entre fournisseurs en milieu de tâche porte une surcharge cognitive. La solution est de garder chaque tâche dans la voie d’un seul fournisseur et de laisser la transmission se produire entre les tâches, pas à l’intérieur d’elles.

Les factures s’additionnent. Faire tourner quatre abonnements de modèle n’est pas gratuit. Le coût est significatif, et je le paie personnellement pour l’instant. Le retour est mesurable en sous-systèmes livrés, donc les mathématiques fonctionnent à ce stade. Ce ne sera pas toujours le cas.

La dérive de qualité entre fournisseurs est un vrai problème. Quand Gemini devient meilleur pour un type de tâche que Claude a fait, la bonne réponse est de déplacer cette tâche vers Gemini. La mauvaise réponse est de continuer à la faire à l’ancienne façon parce que c’est ce que dit le document de flux de travail. Le document de flux de travail doit être révisé toutes les quelques semaines parce que le paysage des modèles bouge sous le flux de travail.

Les fournisseurs ne se connaissent pas entre eux. Quand Claude écrit un morceau de code qui va être révisé par Gemini, Claude ne le sait pas. Quand ChatGPT argumente une décision architecturale avec moi, l’implémentation éventuelle par Claude ne voit pas cet argument. L’intégration entre les fournisseurs est dans ma tête. C’est un endroit fragile pour que vive l’intégration, et c’est l’une des choses que je voudrais corriger si je construisais une infrastructure pour aider d’autres à faire tourner ce flux de travail.

Qu’en est-il du côté runtime ?

C’est la partie où l’histoire du flux de travail de développement et l’histoire du moteur convergent.

Le XRAssistantService qui a atterri il y a deux semaines dans le runtime est agnostique au modèle par conception. La raison est exactement la même que la raison pour laquelle ce flux de travail de développement est multi-fournisseurs. L’interface est construite pour que n’importe quel modèle de ces laboratoires puisse piloter une expérience AR à travers le runtime. Le laboratoire dont le modèle est le meilleur pour une tâche donnée obtient de fournir l’intention de cette tâche dans une expérience donnée.

C’est le pari plus large : l’ère du « ce produit est construit sur ce modèle de ce fournisseur » est courte. L’ère dans laquelle nous entrons est « ce produit est construit autour de capacités façonnées par des modèles, et quel modèle spécifique remplit quel créneau de capacité à un moment donné est un choix de configuration ». Le moteur doit être prêt pour cela. Le flux de travail de développement qui construit le moteur devrait le refléter.

Ce que je veux que les bâtisseurs et laboratoires retiennent de ceci

Si vous êtes un fournisseur d’agent de codage et que vous lisez ceci, la métrique que j’optimiserais est « à quelle fréquence la PR de cet agent survit-elle à une revue par un agent d’un fournisseur concurrent ». L’auto-cohérence n’est pas la barre. La survie à la revue inter-fournisseurs est la barre. Les agents qui font bien sur cette métrique seront ceux qui seront utilisés pour du travail sérieux.

Si vous êtes un développeur qui réfléchit à adopter un flux de travail assisté par IA pour une base de code sérieuse, ne choisissez pas un seul modèle et ne vous arrêtez pas là. Choisissez-en un pour écrire. Choisissez-en un différent pour réviser. Utilisez-en un troisième pour faire du rubber-ducking sur les décisions architecturales ouvertes. La prime de coût est réelle et la différence de qualité est plus grande.

Si vous êtes un dirigeant d’entreprise qui réfléchit à l’IA dans votre organisation de développement, le schéma multi-fournisseurs est celui qui passera à l’échelle. L’adoption mono-fournisseur paraît plus simple sur le papier. En pratique, elle produit de la fragilité, à la fois technique et stratégique.

Samedi tranquille. Le moteur a eu un week-end à trente-cinq commits. La plupart de ces commits seront invisibles dans six mois. Le flux de travail qui les a produits ne le sera pas.