Vous courez après les outils. La compétence est en dessous.

La plupart des jours, j'écris du code avec deux modèles différents, et je passe de l'un à l'autre sans grande cérémonie. L'un est rapide, et je le prends quand le travail est mécanique et que je veux que la boucle donne l'impression d'un prolongement de mes propres mains. L'autre est plus lent et porte plus loin, et je le fais entrer quand le problème demande vraiment du raisonnement. Voici la partie que j'ai mis du temps à admettre. Le changement ne modifie presque rien au travail. La spécification que j'écris est la même. Ma façon de découper le problème est la même. La revue à la fin est la même. Je change le moteur et je garde tout ce que j'ai construit autour.

La question est un sondage

La question qu'on me pose, et celle que je vois partout, c'est quel outil est le meilleur. Quel modèle, quel agent, quel éditeur. Cela sonne technique. C'est en réalité un sondage. Le meilleur pour quoi, pour qui, sous quelles contraintes, sur quelle base de code ? Retirez tout cela et il ne reste aucune réponse, seulement du goût, et le goût n'est pas un savoir. Et la réponse sur laquelle vous auriez fini par vous fixer serait périmée dès la version suivante. Vous auriez dépensé un effort réel pour produire un fait dont la durée de vie se compte en semaines.

Vous optimisez la partie du système qui change le plus et qui compte le moins. Trois couches sont en jeu. Le modèle, celui sur lequel portent les débats, et que vous pouvez remplacer en un jour. Le harness autour de lui, le produit que vous achetez réellement : la façon dont il tient le contexte, sa capacité à lire votre base de code, à lancer vos tests et à se rétablir quand il casse. Et la boucle que vous faites tourner à travers lui, les specs et la revue, qui est à vous et vous suit partout. Pour le travail de tous les jours, les modèles de pointe sont assez proches pour que choisir entre eux revienne à tirer à pile ou face ; ce qui reste, c'est rapide contre profond, et ce choix se fait tâche par tâche, ce n'est pas un classement. La question de l'outil fait une fixation sur la première couche et mentionne à peine les deux autres, alors que les deux autres décident du résultat.

Même outil, deux mains

Mettez le même outil entre les mains de deux développeurs et vous obtenez deux résultats différents. L'un spécifie le problème, lit la sortie, repère l'endroit où elle a déraillé et corrige. L'autre accepte tout ce qui sort. À outil constant, les résultats divergent. À personne constante, j'en fais l'expérience chaque fois que je change de modèle, presque rien ne bouge. Cette asymétrie vous dit où placer votre attention.

Il y a aussi un coût à sauter d'outil en outil, et il se paie précisément dans cette attention. Chaque changement remet quelque chose à zéro. Vous réapprenez les manies, vous réécrivez vos instructions, et le gain est petit et ne dure pas. Pendant ce temps, la seule chose qui capitalise n'est pas touchée, parce que vous étiez occupé à faire du shopping. Le développeur qui choisit un outil suffisant et va au fond de la boucle dépasse celui qui migre en permanence.

Là où l'outil compte vraiment

Rien de tout cela ne signifie que l'outil ne vaut rien, et la version paresseuse de cet argument prétend le contraire. La catégorie compte énormément. Une autocomplétion qui termine votre ligne, un agent en terminal qui modifie un repo entier et ouvre une pull request, et un runner que vous pointez vers une tâche avant de vous éloigner sont des instruments différents, et c'est en les traitant comme des substituts que les gens finissent déçus.

Sur les problèmes les plus durs, ceux qui ne tiennent pas proprement dans un benchmark, la différence entre un setup solide et un setup faible, c'est de livrer ou de ne pas livrer du tout, et l'essentiel de cette différence vient du harness et de la boucle, pas du nom sur le modèle. Si votre travail vit sur une seule plateforme, l'outil natif de cette plateforme peut gagner sur la seule intégration. Même la vitesse dont je parlais est une différence réelle, pas une affaire de goût ; une partie du métier consiste à savoir quand une tâche demande le modèle rapide et quand elle demande le lent.

« Apprenez d'abord les fondamentaux » est une réponse creuse à sa manière quand elle veut dire : ignorez les outils. Les outils amplifient les fondamentaux. C'est pour cela que les fondamentaux paient, et ce n'est pas une permission d'ignorer ce avec quoi vous amplifiez.

Et puis il y a la facture

L'endroit où l'outil compte le plus n'a rien à voir avec le modèle le plus intelligent. C'est la tarification. J'ai longtemps vécu sur un outil qui facturait un prix fixe, et je m'appuyais dessus sans retenue, toute la journée, tous les jours, et la facture ne bougeait pas. Je savais exactement ce que coûtait un mois. Puis la tarification a changé sous mes pieds, du forfait au compteur, et le même travail que j'avais toujours fait s'est mis à coûter plus de mille euros en une seule semaine. Rien dans ma compétence ni dans ma boucle n'avait changé, seulement le compteur.

Un changement de prix est une vraie raison de changer d'outil, et c'est l'opposé de la course à la nouveauté. Je suis passé à un outil avec un plafond prévisible, qui fait tourner les mêmes modèles que je préférais déjà, et ma facture est redevenue un chiffre autour duquel je pouvais planifier. Je touche une limite de temps en temps. Les semaines à mille euros ne me manquent pas. Les outils que j'ai quittés facturent toujours une prime pour exactement les modèles que je veux, ce qui est un bon business pour eux et une mauvaise affaire pour moi.

Quiconque a fait tourner des choses dans le cloud a déjà vu les deux moitiés de cette histoire. La facture qui passe au compteur puis vous surprend. La capacité sur laquelle on ne peut pas entièrement compter : l'instance qui refuse de démarrer dans votre région, la limite que vous touchez exactement à la mauvaise heure. Le cloud a passé une décennie à apprendre aux ingénieurs à surveiller le compteur, à plafonner ce qui peut l'être, et à ne jamais se lier si étroitement à un fournisseur que partir signifie tout réécrire. Les outils d'IA en sont au début de la même histoire, et la leçon se transpose telle quelle.

Alors quand quelqu'un vous dit que l'outil ne compte pas, voici la partie qu'il oublie. L'intelligence converge et le harness compte, mais les termes du contrat peuvent compter plus que les deux. Pas seulement le prix et la capacité, mais la licence qui change sous vos pieds, et la politique de confidentialité qui se met à verser votre code dans l'entraînement du prochain modèle. Ce sont des leviers qu'un fournisseur peut actionner du jour au lendemain sans toucher une ligne de chez vous, et chacun d'eux a été actionné sur quelqu'un ces dernières années. Voilà le vrai argument pour garder votre boucle portable. Pas pour courir après un leaderboard, mais pour que le jour où le contrat change, vous puissiez partir.

La bonne version de la question

La bonne version de la question de l'outil a une réponse, parce qu'elle nomme ses contraintes. Le meilleur pour les gros refactorings qui doivent tenir dans un seul contexte. Le meilleur sous un budget mensuel fixe. Le meilleur pour du code qui ne peut pas quitter nos machines. Le meilleur dans le langage dans lequel nous travaillons vraiment. Celles-là ont des réponses. « Quel est le meilleur outil d'IA pour coder » n'en a pas, parce qu'elle ne dit jamais meilleur pour quoi. Décomposez-la donc, et changez d'outil à dessein plutôt que sur une impulsion : quand vous avez nommé une capacité qui vous manque et mené une comparaison équitable. Gardez aussi un peu de temps pour la veille, en regardant ce que les gens de confiance adoptent réellement, parce que le changement qui compte le plus est parfois vers une catégorie dont vous ignoriez l'existence.

J'ai choisi mon setup de cette façon, puis j'ai à peu près cessé d'y penser. Les instructions de projet, les specs et les habitudes de revue se transportent toutes ; seul le modèle en dessous change selon la tâche. Les outils que j'ai construits penchent du même côté : un pipeline qui transforme une phrase en plan et ouvre ses propres pull requests, un plan de contrôle qui gouverne des flottes d'agents. Aucun ne se soucie du modèle qui siège derrière. Ce sont des échafaudages autour de la même boucle.

Et cela dépasse mon propre outillage, parce que l'essentiel de ce qui ressemble à un nouveau produit d'IA est construit sur des modèles de pointe que n'importe qui peut louer. J'ai contribué à des produits qui font un travail sérieux en droit, en santé, en recherche scientifique et en audit, et aucun ne tourne sur un moteur secret. À l'intérieur, il y a un pipeline : plusieurs étapes avec leurs propres dépendances, souvent des modèles différents à des étapes différentes pour des raisons différentes, un rapide là où la latence est la contrainte, un profond là où c'est le raisonnement, la même répartition que je fais à mon propre bureau. Mais chaque modèle de la chaîne vient du même menu court où les concurrents commandent aussi. Ce qui rend ces produits dignes d'être payés, c'est tout ce qui entoure les modèles : la recherche dans les sources qui comptent vraiment, l'ancrage qui garde une réponse arrimée à ces sources, le workflow façonné sur la manière dont la profession travaille réellement. Les modèles ne sont le rempart de personne. La valeur se dépose autour d'eux, pas dedans, et c'est la même leçon à une autre altitude.

Ce que vous gardez vraiment

Alors courez après un outil pendant une semaine si vous voulez, puis devenez bon. Le modèle que vous utilisez sera remplacé par un modèle véritablement meilleur selon un calendrier que vous ne contrôlez pas, et cela ne sauvera toujours pas le développeur qui n'a jamais appris à spécifier ni à lire. La façon dont vous pensez un problème et l'œil qui repère la mauvaise ligne restent à vous à travers tous les changements. L'un des deux mérite d'être construit. L'autre mérite une semaine de votre attention, et une porte de sortie que vous gardez ouverte.