- Un ingénieur logiciel efficace construit et maintient un modèle mental clair des exigences et du code, puis effectue en boucle des comparaisons et des mises à jour répétées
- Les LLM peuvent écrire et modifier du code, rédiger des tests et déboguer, mais ils manquent de capacité à maintenir un modèle mental précis, ce qui les amène à se perdre dans les tâches complexes
- Aujourd’hui, les LLM ont des limites pour identifier avec précision les écarts entre le code et les exigences puis les corriger de manière appropriée, en raison de problèmes d’omission de contexte, de biais de récence et d’hallucinations
- Les humains peuvent changer de mode de pensée avec souplesse selon la situation, par exemple en stockant temporairement le contexte global ou en masquant momentanément les détails pour voir la situation d’ensemble, mais les LLM ne savent pas le faire
- Les LLM sont utiles pour les tâches aux exigences simples, mais dans le développement logiciel complexe, c’est au final l’ingénieur logiciel de prendre directement la responsabilité de la clarté des exigences et du comportement du code, les LLM jouant un rôle d’outil d’assistance
La boucle de l’ingénierie logicielle
- Un ingénieur expérimenté travaille en répétant les étapes suivantes
1. Construire un modèle mental des exigences
2. Écrire le code en fonction de ce modèle
3. Comprendre ce que fait réellement le code produit
4. Identifier les écarts et corriger le code ou les exigences
- Le cœur de cette boucle est la capacité à disposer d’un modèle mental exact et maintenable
Les limites des LLM
- Les LLM peuvent écrire du code, repérer un problème puis le corriger, rédiger et exécuter des tests, ajouter des logs et utiliser un débogueur
- Mais comme ils ne parviennent pas à maintenir un modèle mental, les problèmes suivants apparaissent
- Ils supposent que le code qu’ils ont écrit fonctionne bien
- Quand un test échoue, ils s’appuient sur des suppositions pour décider s’il faut corriger le code ou le test
- Lorsqu’ils sont perdus, ils suppriment tout le code et recommencent depuis zéro
- Contrairement à un humain, ils manquent de souplesse pour examiner leur modèle quand un test échoue et décider de la direction de correction, ou pour dénouer le problème par l’échange lorsqu’ils sont bloqués
- Un ingénieur logiciel exécute des tests en cours de travail et peut déterminer clairement quelle partie doit être corrigée lorsqu’un problème survient
- Parfois, même lorsqu’il faut recommencer l’ensemble du travail, cela conduit à une compréhension plus profonde du problème
Possibilités futures
- Les choses pourraient changer à mesure que les modèles progresseront, mais l’ingénierie logicielle exige plus que la simple génération de code
- Lorsqu’un humain résout un problème important, il peut extraire temporairement le contexte global de sa mémoire pour le manipuler, se concentrer sur un point précis ou prendre du recul sur l’ensemble
- L’important n’est pas d’empiler toujours plus d’informations de contexte, mais d’adopter une manière de penser qui traite sélectivement les informations nécessaires
- Les LLM ne disposent pas de cette capacité, propre aux humains, à stocker et restaurer temporairement le contexte, ni à naviguer entre la vue d’ensemble et les détails
- Principales limites actuelles des LLM
- Omission de contexte (Context omission) : difficulté à repérer les parties où des informations nécessaires manquent
- Biais de récence (Recency bias) : tendance excessive à privilégier les informations les plus récentes dans la fenêtre de contexte
- Hallucination (Hallucination) : invention de détails qui n’existent pas
- L’ajout de fonctions de mémoire pourrait améliorer certains points, mais au-delà d’un certain niveau de complexité, ils échouent encore à comprendre le contexte et à maintenir un modèle
- Ils peinent à conserver deux modèles mentaux similaires, à analyser leurs différences et à décider où modifier les exigences ou le code
Rôle actuel et usages
- Les LLM excellent dans la génération rapide de code et l’intégration des exigences et de la documentation, ce qui les rend tout à fait exploitables pour des tâches simples et bien définies
- Mais pour les problèmes non triviaux, il leur est difficile de conserver un contexte suffisant et de procéder à des améliorations itératives
- En conséquence, la clarification des exigences et la vérification du code restent de la responsabilité de l’ingénieur logiciel
- On vise un environnement où humains et agents (LLM) construisent des logiciels ensemble, mais à l’heure actuelle, l’ingénieur doit garder la main et le LLM doit être utilisé comme un outil
Aucun commentaire pour le moment.