Très intéressé par ce à quoi pourrait ressembler l'ère à venir de logiciels hautement sur mesure. Exemple de ce matin - je suis devenu un peu laxiste avec mon cardio récemment, donc j'ai décidé de faire une expérience plus sérieuse et régimentée pour essayer de réduire ma fréquence cardiaque au repos de 50 -> 45, sur une durée d'expérimentation de 8 semaines. Le moyen principal d'y parvenir est d'aspirer à un certain objectif total de minutes en cardio Zone 2 et 1 HIIT/semaine. 1 heure plus tard, j'ai codé ce tableau de bord super personnalisé pour cette expérience très spécifique qui me montre comment je progresse. Claude a dû rétroconcevoir l'API cloud du tapis de course Woodway pour extraire des données brutes, les traiter, les filtrer, les déboguer et créer une interface web pour suivre l'expérience. Ce n'était pas une expérience entièrement fluide et j'ai dû remarquer et demander à corriger des bugs, par exemple, il a mal géré les unités du système métrique par rapport au système impérial et il a mal associé les jours aux dates dans le calendrier, etc. Mais je sens toujours que la direction générale est claire : 1) Il n'y aura jamais (et ne devrait pas y avoir) d'application spécifique sur l'App Store pour ce genre de chose. Je ne devrais pas avoir à chercher, télécharger et utiliser une sorte de "suivi d'expérience cardio", quand ce truc fait ~300 lignes de code qu'un agent LLM vous donnera en quelques secondes. L'idée d'un "App Store" d'un long éventail d'applications discrètes parmi lesquelles vous choisissez semble d'une certaine manière erronée et dépassée lorsque les agents LLM peuvent improviser l'application sur le champ et juste pour vous. 2) Deuxièmement, l'industrie doit se reconfigurer en un ensemble de services de capteurs et d'actionneurs avec une ergonomie native d'agent. Mon tapis de course Woodway est un capteur - il transforme l'état physique en connaissance numérique. Il ne devrait pas maintenir une interface lisible par l'homme et mon agent LLM ne devrait pas avoir à le rétroconcevoir, cela devrait être une API/CLI facilement utilisable par mon agent. Je suis un peu déçu (et mes délais sont en conséquence plus lents) de la lenteur de cette progression dans l'industrie en général. 99 % des produits/services n'ont toujours pas de CLI native à l'IA. 99 % des produits/services maintiennent des docs .html/.css comme si je ne cherchais pas immédiatement comment copier-coller le tout à mon agent pour faire quelque chose. Ils vous donnent une liste d'instructions sur une page web pour ouvrir telle ou telle URL et cliquer ici ou là pour faire une chose. En 2026. Qu'est-ce que je suis, un ordinateur ? Vous le faites. Ou faites-le faire par mon agent. Donc, aujourd'hui, je suis impressionné que ce truc aléatoire ait pris 1 heure (cela aurait pris ~10 heures il y a 2 ans). Mais ce qui m'excite encore plus, c'est de réfléchir à la façon dont cela aurait vraiment dû prendre 1 minute au maximum. Que doit-il y avoir en place pour que cela prenne 1 minute ? Pour que je puisse simplement dire "Salut, peux-tu m'aider à suivre mon cardio au cours des 8 prochaines semaines", et après une très brève séance de questions-réponses, l'application serait opérationnelle. L'IA aurait déjà beaucoup de contexte personnel, elle rassemblerait les données supplémentaires nécessaires, elle ferait référence et rechercherait des bibliothèques de compétences connexes, et maintiendrait toutes mes petites applications/automatisations. TLDR le "App Store" d'un ensemble d'applications discrètes parmi lesquelles vous choisissez est un concept de plus en plus dépassé en soi. L'avenir, ce sont des services de capteurs et d'actionneurs natifs à l'IA orchestrés via de la colle LLM en applications hautement personnalisées et éphémères. Ce n'est tout simplement pas encore là.

Je pense que c'est un moment très intéressant pour être dans les langages de programmation et les méthodes formelles, car les LLM changent complètement le paysage des contraintes du logiciel. Des indices de cela peuvent déjà être observés, par exemple dans l'élan croissant derrière le portage de C vers Rust ou l'intérêt grandissant pour la mise à niveau des bases de code héritées en COBOL, etc. En particulier, les LLM sont *particulièrement* bons en traduction par rapport à la génération de novo, car 1) la base de code originale agit comme une sorte de prompt très détaillé, et 2) comme référence pour écrire des tests concrets. Cela dit, même Rust n'est pas du tout optimal pour les LLM en tant que langage cible. Quel type de langage est optimal ? Quelles concessions (le cas échéant) sont encore faites pour les humains ? De nouvelles questions et opportunités incroyablement intéressantes. Il semble probable que nous finirons par réécrire de grandes fractions de tout le logiciel jamais écrit plusieurs fois.

Félicitations pour le lancement @simile_ai ! (et je suis ravi d'être impliqué en tant que petit investisseur.) Simile travaille sur une dimension vraiment intéressante, à mon avis sous-explorée, des LLMs. En général, les LLMs avec lesquels vous interagissez ont une personnalité unique, spécifique et soigneusement élaborée. Mais en principe, la forme native et primordiale d'un LLM pré-entraîné est qu'il s'agit d'un moteur de simulation entraîné sur le texte d'une population de personnes très diverse sur Internet. Pourquoi ne pas tirer parti de ce pouvoir statistique : pourquoi simuler une "personne" alors que vous pourriez essayer de simuler une population ? Comment construisez-vous un tel simulateur ? Comment gérez-vous son entropie ? À quel point est-il fidèle ? Comment peut-il être utile ? Quelles propriétés émergentes pourraient découler de similes en boucle ? À mon avis, ce sont des sujets très intéressants, prometteurs et sous-explorés, et l'équipe ici est formidable. Tous mes vœux de réussite !