Transcription : Pourquoi les grands modèles de langage ne peuvent-ils pas vraiment construire des logiciels ? Auteur : Conrad Irwin J'ai passé beaucoup de temps à interviewer des ingénieurs logiciels. C'est évidemment une tâche ardue, et je ne dirais pas que j'ai une méthode infaillible ; mais cette expérience m'a vraiment donné le temps de réfléchir à ce qu'un ingénieur logiciel efficace fait réellement. Le cycle central de l'ingénierie logicielle Lorsque vous observez un véritable expert, vous constaterez qu'il exécute toujours les étapes suivantes en boucle : * Construire un modèle mental des besoins. * Écrire (on l'espère ?!) du code capable de répondre aux besoins. * Construire un modèle mental du comportement réel du code. * Identifier les différences entre les deux, puis mettre à jour le code (ou les besoins). Il existe de nombreuses façons d'accomplir ces étapes, mais la force des ingénieurs efficaces réside dans leur capacité à construire et à maintenir des modèles mentaux clairs. Comment se comportent les grands modèles de langage ? Pour être juste, les grands modèles de langage excellent dans l'écriture de code. Lorsqu'on leur indique où se situe le problème, ils s'en sortent également assez bien pour mettre à jour le code. Ils peuvent faire tout ce qu'un ingénieur humain ferait : lire du code, écrire et exécuter des tests, ajouter des journaux, et (probablement) utiliser un débogueur. Mais ce qu'ils ne peuvent pas faire, c'est maintenir un modèle mental clair. Les grands modèles de langage tombent dans une confusion sans fin : ils supposent que le code qu'ils ont écrit fonctionne réellement ; lorsque les tests échouent, ils ne peuvent que deviner s'il faut corriger le code ou le test ; lorsqu'ils se sentent frustrés, ils suppriment tout et recommencent. Cela va à l'encontre des caractéristiques que j'attends d'un ingénieur. Les ingénieurs logiciels testent en travaillant. Lorsque les tests échouent, ils peuvent se référer à leur modèle mental pour décider s'il faut corriger le code ou le test, ou s'ils doivent d'abord recueillir plus d'informations avant de prendre une décision. Lorsqu'ils se sentent frustrés, ils peuvent chercher de l'aide en communiquant avec d'autres. Bien qu'ils puissent parfois tout supprimer et recommencer, cela se fait après avoir acquis une compréhension plus claire du problème. Mais ça ira vite, n'est-ce pas ? Avec l'augmentation des capacités des modèles, cette situation va-t-elle changer ? Peut-être ? Mais je pense que cela nécessiterait un changement fondamental dans la manière dont les modèles sont construits et optimisés. Le modèle dont l'ingénierie logicielle a besoin n'est pas simplement capable de générer du code. Lorsqu'une personne rencontre un problème, elle peut temporairement mettre de côté tout le contexte, se concentrer sur la résolution du problème immédiat, puis revenir à ses pensées précédentes et au grand problème en cours. Elle peut également passer facilement entre la vue d'ensemble et les détails, en ignorant temporairement les détails pour se concentrer sur l'ensemble, puis en approfondissant les parties lorsque cela est nécessaire. Nous ne devenons pas plus efficaces simplement parce que nous ajoutons plus de mots dans notre "fenêtre de contexte" ; cela ne ferait que nous rendre fous. Même si nous pouvons gérer une grande quantité de contexte, nous savons que ces modèles génératifs actuels présentent plusieurs problèmes graves qui affectent directement leur capacité à maintenir des modèles mentaux clairs : * Omission de contexte : les modèles ne sont pas doués pour détecter les informations contextuelles négligées. * Biais de proximité : ils sont gravement affectés par un biais de proximité lorsqu'ils traitent la fenêtre de contexte. * Hallucinations : ils ont souvent tendance à "imaginer" des détails qui ne devraient pas exister. Ces problèmes ne sont peut-être pas insurmontables, et les chercheurs s'efforcent d'ajouter de la mémoire aux modèles pour qu'ils puissent exercer des techniques de pensée similaires aux nôtres. Mais malheureusement, pour l'instant, ils ne peuvent pas réellement comprendre ce qui se passe (au-delà d'un certain niveau de complexité). Ils ne peuvent pas construire de logiciels parce qu'ils ne peuvent pas maintenir simultanément deux "modèles mentaux" similaires, identifier les différences et décider s'il faut mettre à jour le code ou les besoins. Alors, que faire maintenant ? Il est évident que les grands modèles de langage sont utiles pour les ingénieurs logiciels. Ils peuvent générer du code rapidement et excellent dans l'intégration des besoins et de la documentation. Pour certaines tâches, cela suffit : les besoins sont suffisamment clairs, le problème est suffisamment simple, et ils peuvent tout faire d'un coup. Cela dit, pour toute tâche ayant un peu de complexité, ils ne peuvent pas maintenir suffisamment de contexte de manière suffisamment précise pour produire finalement une solution viable par itération. Vous, en tant qu'ingénieur logiciel, devez toujours vous assurer que les besoins sont clairs et que le code réalise réellement ce qu'il prétend faire. Chez Zed, nous croyons que l'avenir des humains et des intelligences artificielles peut être de construire des logiciels ensemble. Cependant, nous sommes convaincus (du moins pour l'instant) que vous êtes le conducteur qui tient le volant, et que les grands modèles de langage ne sont qu'un autre outil à votre portée.