Coder avec un LLM

Mon employeur incite ses développeurs à utiliser les LLMs, je suppose à des fins de productivité et réduction du nombre d’employés in fine.

Au début j’étais sceptique, mais récemment sur un projet en C++/Fortran, il m’a pas mal aidé.

Il y a une nette évolution en 3 ans de la qualité de compréhension de l’entrée et de la sortie. Intégré aux éditeurs de code source, le LLM a accès à un contexte précis.

Le LLM se perd toujours si la tache est trop ambiguë. Donc je pense que la question de bonnes spécifications reste. Et bizarrement c’est aussi le problème avec les humains. Si les spécifications ne sont pas bonnes (pas assez précises ou faites de mauvais choix techniques ou de direction produit), le résultat n’est pas bon.

La casse est peut être moins visible pour le décideur si il peut « refaire » encore moins qu’avant, qui était déjà moins cher que déplacer un mur en béton ! on a pas vraiment les meilleurs PM dans le monde logiciel… J’ai bien peur d’une fuite en avant où aucune décision du « management » ne saurait avoir de conséquence puisqu’il serait attendu de son équipe de pouvoir virer de bord encore plus vite à tout moment.

En tant qu’humain, on dépense beaucoup d’énergie à rendre le code compact et lisible. C’est ce qui nous permet d’appréhender la complexité et réduire le coût de modification et maintenance. J’ai l’impression que les LLMs sont disruptifs sur ce point. Or un code non lisible autrement que par un LLM est il encore maintenable par des humains ?

Factoriser le code, c’est complexe. C’est faire des arbitrages entre ce qui sera générique dans le futur et ce qui ne le sera pas. Les LLMs peuvent sans effort écrire une implémentation pour chaque problème. Et c’est justement quand on veut factoriser qu’on met en évidence les incohérences de la demande ou de l’implémentation. D’un autre coté pour les gens qui ne « conceptualisent pas », il leur suffit de rajouter exception sur exception au comportement… (ça va finir en livre de grammaire française ce code :D)

Au niveau plaisir du travail, j’ai perdu ce qui faisait le sel de débloquer une situation en ayant compris le problème. Laisser itérer le LLMs sur ses intuitions va assez souvent amener à la solution. Mais du coup, on n’a rien appris en chemin. On peut se donner comme discipline de relire chaque solution du LLM et la comprendre en profondeur mais est ce que l’employeur nous laissera ce luxe longtemps?

La manière de travailler est toujours basée sur de la revue de code par les pairs (aussi appelée « code review »). Les problèmes sont traité dans des tickets où chaque problème parcourt le même fil de conducteur : observation, compréhension, résolution. Hors chacune de ces étapes reçoit maintenant des contributions par LLM. Un code torché par un LLM sans compréhension de l’employé est soumis à la revue collective, faisant perdre beaucoup de temps (mais peut-être moins que si la personne l’avait écrite encore moins bien elle même) mais qui paie? Les bugs & analyses proviennent de LLMs avec des « indications trompeuses » car dénuées de vraie réflexion.

Chacun utilise le LLM pour délivrer plus & plus vite. Cela crée rapidement une concurrence entre les employés, et donc pousse à son usage par tous sans exception.

Un junior peut rapidement délivrer une fonctionnalité de senior. Par exemple, j’avais un bout de code à porter en Fortran, je n’ai même pas eu à ouvrir un bouquin sur la syntaxe Fortran ou à savoir écrire un « hello world », le LLM m’a tout porté, en prenant en compte les différences de support de types (pas de double signé). Du coup, quelle est la valeur de l’humain senior qui lui a bossé la syntaxe Fortran? Bon je vois des bugs dans l’implémentation du LLM, mais pour le décideur, le code est livré fonctionnel et passe le cas test en une journée…

De l’autre coté, tout le travail alloué aux juniors, comme les petits problèmes qui permettent de prendre pied dans du code complexe ou la recherche en amont sur des techniques peu communes, est remplacée par le LLM. Celui ci va identifier et corriger les petits problèmes facilement et sur le prototypage, on peut lui demander plusieurs implémentations prototypes très rapidement. Comment un junior ou un stagiaire peut se faire valoir auprès de l’employeur?

Je me pose aussi la question de l’interface homme-machine. On a depuis 40 ans un interface homme-machine plutôt basée sur une interface graphique avec des boutons qui font penser à des contacteurs électroniques et des fonctions qui font penser à des circuits électroniques fixes. C’est le paradigme. Mais n’est ce pas un peu désuet ? Est ce que l’arrivée des LLMs ne permettrait pas remplacer tout ça par du prompt libre et du code machine généré à la volée?

Bref, je ne sais pas ce qui va rester de l’activité de développeur, est ce qu’on sera « maître de stage » d’un bataillon de LLMs et qu’on n’écrira plus que des spécifications sans toucher une ligne de code? Est qu’on sera relégué à faire de la revue de code comme des surveillants? ou de fournir un apprentissage aux LLMs de la société en dépossédant les employés de la valeur de leur savoir faire (« know how ») pour une bouchée de pain et en laissant la société en multiplier les fruits ?