Peut-être pas une technologie ennuyeuse après tout

Peut-être pas une technologie ennuyeuse après tout

Une préoccupation récurrente que j'ai observée concernant les LLM (modèles de langage de grande taille) pour la programmation est qu'ils pourraient orienter nos choix technologiques vers les outils qui sont le mieux représentés dans leurs données d'entraînement, rendant ainsi plus difficile la percée de nouveaux outils meilleurs.

Cela a certainement été le cas il y a quelques années, lorsque demander de l'aide à des modèles pour Python ou JavaScript semblait donner de bien meilleurs résultats que des questions sur des langages moins utilisés.

Avec les derniers modèles fonctionnant dans de bons environnements d'agents de codage, je ne suis pas sûr que cela soit toujours vrai.

J'obtiens d'excellents résultats avec mes tout nouveaux outils où je commence par demander “use uvx showboat --help / rodney --help / chartroom --help pour en savoir plus sur ces outils” — la longueur de contexte de ces nouveaux modèles est suffisamment longue pour qu'ils puissent consommer une grande quantité de documentation avant de commencer à travailler sur un problème.

Intégrez un agent de codage dans n'importe quelle base de code existante utilisant des bibliothèques et des outils qui sont trop privés ou trop récents pour figurer dans les données d'entraînement, et mon expérience montre que cela fonctionne très bien — l'agent consultera suffisamment d'exemples existants pour comprendre les motifs, puis itérera et testera sa propre sortie pour combler les lacunes.

C'est un résultat surprenant. Je pensais que les agents de codage seraient l'incarnation ultime de l'approche Choose Boring Technology, mais en pratique, ils ne semblent pas affecter mes choix technologiques de cette manière.

Mise à jour : Quelques réflexions complémentaires

La question de la technologie recommandée par les LLM est distincte. L'étude récente “What Claude Code Actually Chooses” est intéressante, où Edwin Ong et Alex Vikati ont testé Claude Code plus de 2 000 fois et ont trouvé un fort biais vers le principe build-over-buy, tout en identifiant une pile technique préférée, avec GitHub Actions, Stripe, et shadcn/ui voyant un “quasi-monopole” dans leurs catégories respectives. Pour les besoins de ce post, je m'intéresse à ce qui se passe lorsque l'humain fait un choix technologique qui diffère de ceux préférés par le modèle.

Le mécanisme des Skills qui est rapidement adopté par la plupart des outils d'agents de codage est très pertinent ici. Nous voyons déjà des projets publier des compétences officielles pour aider les agents à les utiliser — voici des exemples de Remotion, Supabase, Vercel, et Prisma.