L'instinct dit que plus de modèles signifie de meilleures réponses. Un onglet de plus, une perspective de plus, trianguler votre chemin vers la vérité. Ça fonctionne jusqu'à environ trois modèles, puis ça s'inverse brutalement. Au-delà, chaque modèle que vous ajoutez vous coûte plus en réconciliation qu'il ne vous rapporte en insight, et la première chose à se dégrader n'est pas votre vitesse. C'est votre jugement sur quelle réponse était correcte.
Point clé : un seul modèle force une pensée claire. Deux ou trois vous offrent un véritable deuxième avis. Au-delà, vous n'orchestrez plus les modèles, vous présidez un comité qui ne se souvient pas de ce sur quoi il s'était mis d'accord il y a dix minutes.
J'ai tracé cette courbe après un mois où j'avais six modèles ouverts plus ou moins en permanence, où je me sentais extrêmement productif, et où j'ai livré un travail notablement plus faible.
Six modèles ouverts m'ont coûté une journée sur une seule carte de redirection
À mon pire, j'avais Opus 5 sur un problème d'architecture, Codex à mi-chemin dans l'implémentation, Composer actif dans l'éditeur, Grok ouvert pour une deuxième lecture, et Qwen et Kimi garés dans deux autres onglets parce que quelqu'un sur X avait dit qu'ils étaient bons pour ça. Ça ressemblait à un cockpit. C'était un groupe de discussion où personne n'avait lu le brief.
Le coût s'est retrouvé dans une carte de redirections. Je consolidais quelques centaines d'anciennes URLs sur un gros site programmatique, le type de travail où 95 pour cent correct est une catastrophe parce que les 5 pour cent font silencieusement 301er le revenu vers un mur. J'ai interrogé trois modèles et obtenu trois réponses défendables sur la chaîne de barres obliques finales. Au lieu d'en choisir une et de la valider, je les ai fusionnées. Le mélange était pire que n'importe lequel des trois seul, parce que chacun était cohérent en lui-même et la fusion ne l'était pas. Une journée à démêler, entièrement auto-infligée.
Un modèle vous force à penser clairement
La propriété sous-estimée d'un seul modèle, c'est qu'il vous remet la spécification entre les mains. Avec exactement une seule chose à demander, vous devez rédiger un vrai cahier des charges : l'entrée, ce que la sortie doit satisfaire, ce qui est hors limites, ce que « fait » signifie. Cet acte d'écriture est la majeure partie de l'ingénierie. J'ai attrapé plus d'erreurs de conception en rédigeant une requête qu'en aucune revue de code.
Avec six modèles ouverts, cette discipline s'évapore tranquillement. Vous arrêtez de rédiger des cahiers des charges et commencez à faire des sondages, et une question vague posée à six modèles vous retourne six réponses confiantes. La confiance n'est pas une preuve, c'est juste ce que ces systèmes semblent être. Presque toute la valeur de mon flux de travail Claude Code se situe en amont du modèle.
Deux ou trois modèles est le véritable point optimal
La raison pour laquelle trois fonctionne, c'est que les modèles font des travaux différents plutôt que le même travail en parallèle. La division du travail s'additionne. La duplication ne s'additionne pas. Un modèle tient le plan, un écrit le code, un vous le relit à froid. Personne ne vote.
Au moment où deux modèles font le même travail, vous n'avez pas acheté de redondance. Vous avez acheté un bris d'égalité que seul vous pouvez résoudre, et vous êtes le participant le moins reposé de la conversation.
Quand un modèle spécialisé gagne vraiment un onglet
Les spécialistes valent la peine quand ils sont structurellement différents, pas seulement différemment commercialisés. Mon test est simple : est-ce qu'il n'est pas d'accord avec les autres d'une manière dont je peux apprendre quelque chose ? Un modèle qui est d'accord avec tout est un homme de oui très cher.
Codex gagne son onglet sur l'implémentation, particulièrement les changements longs et mécaniques sur plusieurs fichiers où je veux un diff plutôt qu'une conversation. Composer 2.5 le gagne à l'intérieur de l'éditeur, où la valeur est la latence, pas la profondeur. Grok le gagne sur les questions de produit et de positionnement, parce qu'il me dira volontiers que l'idée est ennuyeuse. Qwen et Kimi le gagnent quand je veux une distribution d'entraînement différente plutôt qu'un autre vote du même quartier. J'ai Kimi câblé dans un script d'audit UI précisément parce qu'il remarque ce que les autres ont appris à ignorer poliment.
Cette dernière distinction est le jeu en entier. La plupart du temps, quand les gens ajoutent un cinquième modèle, ils ne cherchent pas un autre avis, ils cherchent une autre confirmation. Ces deux choses semblent identiques sur le moment et elles sont opposées.
Le coût caché, c'est la réconciliation, pas le changement
Le context switching est le coût que tout le monde mentionne, et il est réel : tu relis le même fichier pour la quatrième fois parce que tu ne te souviens pas dans quel onglet tu as parlé de la contrainte. Mais ce n'est pas le coûteux.
Le coûteux, c'est que tu deviens le conflit de fusion. Deux modèles te donnent un désaccord à trancher. Trois t'en donnent trois. Six t'en donnent quinze par paires, et chacun d'eux veut une décision du même humain épuisé. Rien dans ta stack ne fait cette réconciliation pour toi. Tu es la couche d'intégration, qui tourne à la fin de la journée, sur un problème dont tu as maintenant lu six formulations légèrement différentes.
Et les modèles ne peuvent pas t'aider ici, parce qu'aucun d'eux ne sait ce que les autres ont dit. Tu es le seul à tenir le contexte complet, ce qui est exactement la position dont tu essayais de te décharger.
L'orchestration de l'IA est généralement un problème humain
Quand les gens disent qu'ils ont besoin d'une meilleure orchestration, ils veulent généralement dire qu'ils ont besoin d'un brief plus clair. Si trois modèles te donnent trois réponses genuinely différentes, c'est rarement une lacune de capacité. C'est presque toujours une ambiguïté dans la question, et aucune logique de routage ne résout un problème sous-spécifié. Ça le distribue juste.
Le diagnostic que j'utilise maintenant : si je ne peux pas écrire, en deux phrases, ce qu'une réponse correcte devrait satisfaire, ouvrir un autre modèle est de la procrastination avec une barre de progression. Écris les deux phrases en premier. Parfois les deux phrases sont la réponse et je ferme tous les onglets.
Le workflow que j'exécute réellement aujourd'hui
Opus 5 pour la réflexion. Architecture, tradeoffs, la question maladroite de savoir si la chose devrait être construite du tout. C'est là où je dépense l'effort du prompt, parce qu'une mauvaise décision ici n'est pas récupérable par un meilleur code plus tard.
Code de mise en œuvre. Une fois la forme décidée, transmettez-lui le cahier des charges et laissez-le travailler. Je passe en revue le diff, pas le raisonnement.
Composer 2.5 pour l'assistance à la programmation. En éditeur, rapide, périmètre réduit. C'est une meilleure autocomplétion, pas un collègue, et le traiter comme un collègue, c'est comment vous finissez avec 400 lignes que vous n'aviez pas demandées.
Grok pour les perspectives alternatives. Délibérément pas sur le chemin critique. J'y vais quand je soupçonne que je me suis parlé moi-même dans un coin.
Qwen ou Kimi quand je veux un autre avis au lieu d'une autre confirmation. Rarement. Exprès.
Ce qui compte n'est pas la liste. C'est que ces outils ne sont presque jamais ouverts en même temps. Une séquence, pas un cockpit : réflexion, puis mise en œuvre, puis révision, un modèle qui tient le crayon à chaque étape. Le graphique plafonne à trois parce que trois, c'est combien d'étapes sont vraiment actives les bons jours. J'en ai comparé deux dans Claude Code contre Cursor.
Les meilleures invites battent plus d'onglets
Un problème bien spécifié donné à un bon modèle bat un problème vague donné à six, et ce n'est pas près. Plus de modèles semble mieux parce qu'ouvrir un onglet est instantané et écrire un cahier des charges, c'est du travail. La peur de manquer du AI est la conviction que le prochain modèle fera la réflexion que vous avez évitée. Il ne le fera pas. Il sera plus éloquent sur le mauvais problème.
La discipline est sans glamour et elle s'accumule. Les gens que je connais qui livrent le meilleur travail avec ces outils ne fonctionnent pas avec le plus de modèles. Ils en utilisent deux ou trois, exprès, avec une division du travail claire et un cahier des charges écrit, et ils s'ennuient du débat sur le modèle de la semaine.
Une seule chose à faire aujourd'hui
Fermez tous les onglets AI sauf un. Prenez la tâche sur laquelle vous êtes réellement et écrivez deux phrases : ce qu'est l'entrée et ce qu'une sortie correcte devrait satisfaire. Donnez ces deux phrases au seul modèle que vous avez laissé ouvert. Si la réponse est bonne, votre goulot n'a jamais été la capacité du modèle. Si elle est mauvaise, vous savez maintenant laquelle des deux phrases était fausse, ce que six modèles n'auraient pas pu vous dire.
FAQ
Combien de modèles IA dois-je utiliser à la fois ?
Deux ou trois, faisant des travaux différents : un pour analyser le problème, un pour l'implémenter, et optionnellement un pour relire ou offrir une perspective contraire. Au-delà de trois, le coût de réconcilier les réponses conflictuelles croît plus vite que la valeur de la perspective supplémentaire, parce que vous êtes le seul participant qui sait ce que tous ont dit.
Est-ce mauvais d'utiliser plusieurs modèles IA pour la même tâche ?
Exécuter deux modèles sur la tâche identique est généralement du gaspillage. Cela n'achète pas de redondance, cela achète un départage que seul vous pouvez résoudre. Plusieurs modèles aident quand ils ont des rôles différents, comme la planification par rapport à l'implémentation, et nuisent quand ils se dupliquent l'un l'autre.
Quel est le vrai coût du passage d'un modèle IA à un autre ?
Le coût évident est de rétablir le contexte et de relire les mêmes fichiers. Le plus grand est la réconciliation : avec six modèles vous avez quinze désaccords par paire à arbitrer, et rien dans votre pile ne le fait pour vous. Vous devenez la couche d'intégration.
Les modèles spécialisés comme Codex, Grok, Qwen ou Kimi aident-ils vraiment ?
Oui, quand ils sont structurellement différents plutôt que simplement différemment marqués, et quand ils ont une tâche définie. Le test est si le modèle est en désaccord avec les vôtres d'une façon dont vous pouvez apprendre. S'il est d'accord la plupart du temps, vous payez pour une confirmation, pas pour une perspicacité.
En relation : mon flux de travail Claude Code pour la discipline du modèle unique que ceci argue, et embaucher un développeur Claude Code si vous préféreriez que ce soit le problème de quelqu'un d'autre.