Il y a une vingtaine d'année, un pote, excellent programmeur par ailleurs, a voulu se débarrasser du problème que je lui posait en lui demandant régulièrement des "petits programmes", en créant un langage quasi naturel comme abstraction. Je n'avais plus qu'à dire ce que je voulais en langue française et hop, ça écrivait le script ! On n'est pas allé très loin, parce... ben, le problème principal, c'est qu'il y a une grande différence entre "ce qu'on croit vouloir" et "tous les problèmes qui se présentent sur le chemin auquel on n'a pas pensé". Et que même en français, j'avais bien du mal à suivre le cheminement logique menant du problème à la solution. Il me fallait son aide non pas pour trouver le bon mot-clé (les pages de man répondent à ça) mais bien pour déterminer ce qui était une variable et ce qui était une fonction.
Et c'est pour ça que les décideurs et les programmeurs sont souvent deux populations différentes. J'ai toujours autant d'idées à la con de "petit truc vite fait pour simplifier tel problème". Et quand on passe à l'implémentation (que ce soit avec des potes devs trop gentils, ou avec une IA), on retombe toujours sur le premier souci qui est de savoir construire des algorithmes. Je ne parle même pas de faire du code propre, qui ne plante pas dès qu'on change un vague truc. Bref, le truc qui fait que ce que je vois comme "vite fait" et "petit" devient en réalité un monstre hydrocéphale qui fera fuir toute personne un tant soit peu compétente à l'énoncé de mon problème.
À mon échelle, les LLM, sur le papier, devraient être parfaits : mes besoins sont généralement du niveau du petit script, c'est basique, c'est court. Et oui, ça m'a dépanné, je ne vais pas cracher dans la soupe (et ça aura épargné à mes potes mes éternels questions de noob). Mais j'en vois aussi très vite les limites dès que je commence à passer à un problème avec plusieurs paramètres, parce que même si à force j'ai pris des levels en programmation, je continue à avoir un esprit profondément "illogique" et que je rame sur les arbres de décisions. Je sais à présent faire (un peu) un cahier des charges, mais ce dernier ne prendra jamais en compte plein de cas pratiques qu'un dev (même pas très doué) verra rapidement (et comblera).
Il me semble évident que c'est le retour de bâton qui attends le monde pro. Oui, actuellement, il y a plein de gens qui se croient très malins parce qu'ils ont demandé à un LLM de coder un truc, et que "ça marche". Mais en fait, sans un expert dans la boucle, ça marche tant que le vent souffle dans le bon sens, que les conditions initiales ne varient pas d'un iota, et que personne ne pousse "là", pour voir. Au moindre problème, ça va s'écrouler et sans doute, au passage, ruiner l'entreprise (voir faire des dégâts très concrets), parce qu'il y aura un monstre tentaculaire mort au milieu du bâtiment, sur lequel personne n'a la moindre idée de comment intervenir dessus.
Ça n'empêche pas que l'usage des LLM amène des changements dans le métier, entre autre en complexifiant l'embauche des juniors et donc la formation des experts de demain, mais aussi en poussant des devs expérimentés à tout lâcher pour élever des chèvres, lassés de devoir relire le code foireux des LLM en question sans que leur hiérarchie entende à quel point c'est pénible. Ça n'empêche pas non plus que ça fait évoluer la façon de pratiquer ce métier de gré ou de force (d'une façon similaire au fait qu'on ne développe pas toujours dans son langage favori ; là, le langage, parfois, c'est "l'IA"). Et rien que pour ça, je ne pense pas qu'on puisse juste évacuer le fait que certains "traversent une forme de crise de santé mentale", comme si ce n'était rien.
[^] # Re: Rien de nouveau sous le soleil
Posté par Zatalyz (site web personnel) . En réponse au journal Eric S. Raymond sur la peur (des développeurs) de l'IA. Évalué à 10.
Il y a une vingtaine d'année, un pote, excellent programmeur par ailleurs, a voulu se débarrasser du problème que je lui posait en lui demandant régulièrement des "petits programmes", en créant un langage quasi naturel comme abstraction. Je n'avais plus qu'à dire ce que je voulais en langue française et hop, ça écrivait le script ! On n'est pas allé très loin, parce... ben, le problème principal, c'est qu'il y a une grande différence entre "ce qu'on croit vouloir" et "tous les problèmes qui se présentent sur le chemin auquel on n'a pas pensé". Et que même en français, j'avais bien du mal à suivre le cheminement logique menant du problème à la solution. Il me fallait son aide non pas pour trouver le bon mot-clé (les pages de man répondent à ça) mais bien pour déterminer ce qui était une variable et ce qui était une fonction.
Et c'est pour ça que les décideurs et les programmeurs sont souvent deux populations différentes. J'ai toujours autant d'idées à la con de "petit truc vite fait pour simplifier tel problème". Et quand on passe à l'implémentation (que ce soit avec des potes devs trop gentils, ou avec une IA), on retombe toujours sur le premier souci qui est de savoir construire des algorithmes. Je ne parle même pas de faire du code propre, qui ne plante pas dès qu'on change un vague truc. Bref, le truc qui fait que ce que je vois comme "vite fait" et "petit" devient en réalité un monstre hydrocéphale qui fera fuir toute personne un tant soit peu compétente à l'énoncé de mon problème.
À mon échelle, les LLM, sur le papier, devraient être parfaits : mes besoins sont généralement du niveau du petit script, c'est basique, c'est court. Et oui, ça m'a dépanné, je ne vais pas cracher dans la soupe (et ça aura épargné à mes potes mes éternels questions de noob). Mais j'en vois aussi très vite les limites dès que je commence à passer à un problème avec plusieurs paramètres, parce que même si à force j'ai pris des levels en programmation, je continue à avoir un esprit profondément "illogique" et que je rame sur les arbres de décisions. Je sais à présent faire (un peu) un cahier des charges, mais ce dernier ne prendra jamais en compte plein de cas pratiques qu'un dev (même pas très doué) verra rapidement (et comblera).
Il me semble évident que c'est le retour de bâton qui attends le monde pro. Oui, actuellement, il y a plein de gens qui se croient très malins parce qu'ils ont demandé à un LLM de coder un truc, et que "ça marche". Mais en fait, sans un expert dans la boucle, ça marche tant que le vent souffle dans le bon sens, que les conditions initiales ne varient pas d'un iota, et que personne ne pousse "là", pour voir. Au moindre problème, ça va s'écrouler et sans doute, au passage, ruiner l'entreprise (voir faire des dégâts très concrets), parce qu'il y aura un monstre tentaculaire mort au milieu du bâtiment, sur lequel personne n'a la moindre idée de comment intervenir dessus.
Ça n'empêche pas que l'usage des LLM amène des changements dans le métier, entre autre en complexifiant l'embauche des juniors et donc la formation des experts de demain, mais aussi en poussant des devs expérimentés à tout lâcher pour élever des chèvres, lassés de devoir relire le code foireux des LLM en question sans que leur hiérarchie entende à quel point c'est pénible. Ça n'empêche pas non plus que ça fait évoluer la façon de pratiquer ce métier de gré ou de force (d'une façon similaire au fait qu'on ne développe pas toujours dans son langage favori ; là, le langage, parfois, c'est "l'IA"). Et rien que pour ça, je ne pense pas qu'on puisse juste évacuer le fait que certains "traversent une forme de crise de santé mentale", comme si ce n'était rien.