Les uns et les autres clament que Claude produit du code meilleur que ce qu'ils auraient produit et moi je me demande, si le résultat est effectivement mieux que ce qu'ils auraient fait, c'est donc au delà de leurs capacités. Dès lors, sont-ils aptes à juger du résultat ? Par exemple, je ne sais pas jongler. N'importe qui pouvant attraper deux fois deux balles fait déjà mieux que ce que j'aurais fait. À quoi ça rime si je l'impose à tous les cirques du monde parce qu'il fait mieux que ce que j'aurais fait ? Faut-il laisser les décisions aux plus incompétents ?
En fait tu touches là le cœur du problème. Une bonne majorité des gens sont incompétents, ou plutôt, pas très compétents (c'est à dire qu'ils sont suffisamment compétents pour faire quelque chose de médiocre, mais qui marche, par contre ça va pas beaucoup plus loin). Et le problème est qu'il est très dur de bien vivre en société si on doit se retrouver à expliquer cela. Ce qui fait que cela ne rentre jamais vraiment en argument dans ce genre de discussion (même si c'est en fait un argument très fort). Enfin je suppose que tu vas pas te mettre à expliquer à tes collègues qu'ils sont incompétents et c'est donc pour cela qu'ils voient pas le problème... enfin du moins en supposant que tu veuilles continuer en bonne entente dans cette entreprise. 😅
Le problème des gens peu compétents pour ce genre d'évaluation est double: le premier est évident, c'est qu'ils ne voient pas le problème (parce qu'évidemment, ils ne savent pas faire mieux); le second est encore plus pervers et encore plus dur à sortir en argument. Quand on est peu compétent, le travail est laborieux et pénible et on saute sur toute bonne occasion de pouvoir éteindre son cerveau. On veut passer une journée pépère au boulot, rentrer chez soi et oublier.
Cela fait donc beaucoup écho à ce que tu dis ensuite:
Jamais une revue de code ne nous donnera une connaissance autre que superficielle et je suis convaincu que ce qui a été écrit par Claude sera maintenu par Claude. Qu'il sera responsable des corrections de bugs et sans doute aussi des revues.
En effet, l'un des arguments que les fanatiques de l'IA sortent souvent, c'est que comme ils sont compétents (🤣), ben ils reliront le code, le comprendront, le "own" (ahah elle est bonne celle-là, ce genre d'anglicisme me rappelle l'époque où je bossais en entreprise), comme tu dis... Mais qu'ils auront gagné énormément de temps, car ils n'auront que la revue de code à faire. Et là on sent bien que ces gens ne comprennent rien à la revue de code, ne la comprennent pas, et ne l'ont sûrement jamais bien faite de leur vie.
Une bonne partie des revues de code prennent plus de temps que si on avait tout écrit de zéro soi-même! Une bonne revue, c'est chiant, c'est pénible, c'est parfois plus éreintant à comprendre que si on écrit le code, car dans le second cas, on doit juste essayer de comprendre le code originel et son intention, alors que dans le premier cas, on doit comprendre également le nouveau code, aussi son intention, et pourquoi le développeur a choisi de corriger le bug à cet endroit précis du code (spoiler: l'endroit de la correction est souvent faux pour les débutants qui adorent corriger les symptômes plutôt que les causes d'un bug! Ce qui ne fait que rendre le code moins bons et le bug réapparaîtrait plus tard; une bonne partie de mes revues de code ont pour conclusion: "là tu es en train de prendre en compte un cas qui est censé être impossible, c'est à dire que si vraiment ta condition retourne TRUE, ça veut dire que le processus est dans un état invalide; s'il te plaît recherche comment en est-on arrivé là, et corrige la source du problème pour que ça ne puisse plus arriver").
Pourquoi on fait des revues de code, alors? D'une, c'est pour former les "nouvelles recrues" (dans le logiciel libre, la variante, ce serait pour espérer que le contributeur reste dans le coin et fasse plus de patchs; donc on le forme dans cet espoir), pour que justement la personne devienne compétente et qu'on n'ait plus trop à passer de temps en revue de code dans le futur. Également cela peut être pour avoir une seconde vision sur un problème complexe (avec l'IA, parler donc de revue de code est une aberration, puisqu'il n'y a au final qu'une seule vision! Celle du développeur qui fait la revue!). Et bien sûr, éviter des problèmes passés inaperçus au premier développeur. Mais en réalité, à un moment donné, on veut tous essayer de s'alléger la tâche, donc à un moment donné, on fait moins gaffe à la revue, et on devient paresseux le jour où on considère que le développeur dont on fait la revue de code est devenu meilleur, et qu'il peut donc gagner un brin d'indépendance. Notons qu'on ne considère pas forcément qu'il est vraiment au top niveau, mais au moins qu'il fera moins d'erreurs de débutants. Dans ces conditions, on va toujours faire une revue de code pour voir s'il n'y a quand même pas de grosses erreurs flagrantes, mais la revue sera plus superficielle, et peut-être même qu'on verra quelques petites imperfections mineures mais qu'on les laissera passer (si elles sont globalement inconséquentes) ou bien qu'on se dira que le patch n'est pas idéal mais pas non plus complètement faux, et on laissera passer encore, en se disant que cette personne doit aussi apprendre. On se permet soi-même un petit peu de paresse dans notre tâche de revue. Et c'est seulement là où la revue est rapide. Mais parce qu'on a sciemment laissé passer du code non-idéal (ou qu'on l'a fait, mais pas sciemment, dans le cas des moins compétents).
Le truc, c'est aussi qu'on veut pas passer tout son temps à faire des revues de code. C'est chiant, c'est long, c'est compliqué (autant, voire plus, que l'écriture du code, car contrairement à ce que semblent penser les mauvais développeurs, il faut aussi comprendre le code pour en faire la revue! On refait donc tout le même travail qu'est censé avoir fait le développeur initial!), et ça ne nous laisse pas de temps pour écrire notre code à nous!
Donc à chaque fois que je lis les fans de l'IA sortir que comme on fait juste la revue de code, ben au final, on peut se l'approprier et on gagne beaucoup de temps, ben la chose que ça me fait comprendre, c'est que ces gens étaient effectivement des développeurs incompétents s'ils pensent ainsi. Parce que ça veut dire qu'ils ne comprennent pas ce qu'est une bonne revue de code et n'en ont jamais fait une (bonne) eux-même de leur vie. Ce sont des gens qui sont probablement directement passé à l'étape "revue paresseuse" sans jamais avoir fait l'étape "revue en profondeur et avec compréhension complète du code" qu'ils auraient dû faire d'abord (et que je fais personnellement pour tout nouveau contributeur, et pas juste pour une ou 2 revues mais en général pour au moins une dizaine de revues pendant quelques mois, voire quelques dizaines de revues — cela dépend du contributeur et de sa capacité d'apprentissage —; et ce qui prend un temps fou).
Maintenant, c'est d'autant plus chiant car il est bien connu que ces développeurs incompétents, ce seront ceux qui finiront aux postes à responsabilité en contexte d'entreprise, ceux qui feront donc des décisions du genre "on va tous utiliser de l'IA, et c'est maintenant un outil obligatoire de l'entreprise".
J'ai bien vécu cela aussi en entreprise, par exemple avec le jeune dont la principale compétence est "sort de polytechnique", propulsé directement à un rôle managérial, ce qui signifie en vrai que le gars est incompétent et est juste là pour "changer les choses" (on sait pas quoi, ni pourquoi, mais faut changer). J'ai une histoire comme cela où on parle de changer notre outil de suivi de bug, ce qui est une bonne idée. C'est l'outil qu'on va utiliser tous les jours, alors je demande à mon boss de présenter quelque chose, je monte un bugzilla (à l'époque, c'était le top, bien avant tous les forges modernes à la Gitlab) sur un serveur, avec des modifs pour s'adapter à l'entreprise, pour faire une démo live. Le gars de son côté a préparé ses "slides" pour présenter Jira. Il ne faisait que copier-coller des points marketing de l'entreprise qui fait Jira (Atlassian). Il n'a pas montré une seule fois le logiciel, qui s'est avéré être une usine à gaz sans nom. Mais bon "il vient de Polytechnique", il n'y a même pas eu de discussion, sa proposition a gagné avant même de la présenter (c'est à peine si les "décideurs" ont regardé ma démo). Vous comprenez, "il vient de Polytechnique".
Dans une autre entreprise, une startup cette fois, on était peu, mais ils ont réussi à choisir le pire des développeurs de l'équipe (mais le plus blabla-teur) pour en faire un manager. Celui qui faisait du mauvais code, qui arrêtait pas en plus de dire du mal des patrons lorsqu'on prenait une bière, mais qui une fois manager est devenu le pire des managers, toxique au possible.
Et le problème, c'est que ce sont ces personnes qui prendront les décisions. Personnellement je suis heureux de ne plus être en entreprise, et ce que je dis souvent, c'est que dans le contexte actuel, je doute d'autant plus que je veuille y retourner un jour.
Donc oui, l'IA, c'est un nouvel apogée de la médiocrité (mais je fais confiance aux humains qui ont su prouver dans leur histoire exceller en la matière et en repousser les limites encore et encore).
Et c'est le cas dans tous les contextes d'usage de l'IA d'ailleurs. Les mêmes problèmes de faible qualité, paresse, etc. s'appliquent. Par exemple, un bon traducteur a besoin de laisser libre cours à son imagination. S'il part d'une traduction médiocre pré-mâchée par un LLM, c'est comme un carcan dans lequel on nous demande de travailler et dont il faut se dépêtrer. Au mieux, cela fera une traduction tout juste "OK", avec énormément plus de travail que si la personne avait tout traduit de zéro. Au pire, le traducteur va devenir paresseux et va faire le minimum syndical (comme dans le cas de la revue de code paresseuse) et on se retrouvera avec une trad médiocre, voire carrément mauvaise.
Ce sera aussi le cas pour l'écriture de texte, ou bien la création d'images, voire multimédia de manière générale.
Et c'est aussi pourquoi il est important que les gens qui comprennent le problème pour leur champ d'activité ne le laisse pas passer là où ils sont moins compétents. On lit encore bien trop souvent des "L'IA, c'est horrible pour le code, mais ça marche super bien pour créer des illustrations" (signé: un développeur qui n'a jamais dessiné depuis la maternelle), ou encore "L'IA tue l'industrie du dessin, mais c'est cool pour faire des programmes pour quelqu'un pas développeur pour un sou!" (signé: un illustrateur quelconque qui veut s'essayer aux jeux vidéos) ou encore "L'IA ne remplacera jamais les acteurs, mais on comprend tout à fait l'usage pour les métiers techniques!" (je reçois des emails d'appel au secours d'organismes de gestion de droits ces derniers mois à ce sujet — ils s'égosillent sur le remplacement des acteurs par des "acteurs IA" —, parce que j'ai un gros passif dans le monde du cinéma/télé), etc. On peut le faire avec toutes les variantes et combinaisons.
Quand ils sont venus simuler la création graphique, je n'ai rien dit, je ne savais pas peindre;
Quand ils sont venus simuler la création littéraire, je n'ai rien dit, j'écris vraiment mal;
Quand ils sont venus simuler la création de code, je n'ai rien dit, je ne développe pas;
Quand le monde fut rempli de merde générée, on s'était déjà tous tirés dans les pattes et plus personne ne travaillait ensemble.
La médiocrité a gagné.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pendant ce temps
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 10 (+31/-1).
En fait tu touches là le cœur du problème. Une bonne majorité des gens sont incompétents, ou plutôt, pas très compétents (c'est à dire qu'ils sont suffisamment compétents pour faire quelque chose de médiocre, mais qui marche, par contre ça va pas beaucoup plus loin). Et le problème est qu'il est très dur de bien vivre en société si on doit se retrouver à expliquer cela. Ce qui fait que cela ne rentre jamais vraiment en argument dans ce genre de discussion (même si c'est en fait un argument très fort). Enfin je suppose que tu vas pas te mettre à expliquer à tes collègues qu'ils sont incompétents et c'est donc pour cela qu'ils voient pas le problème... enfin du moins en supposant que tu veuilles continuer en bonne entente dans cette entreprise. 😅
Le problème des gens peu compétents pour ce genre d'évaluation est double: le premier est évident, c'est qu'ils ne voient pas le problème (parce qu'évidemment, ils ne savent pas faire mieux); le second est encore plus pervers et encore plus dur à sortir en argument. Quand on est peu compétent, le travail est laborieux et pénible et on saute sur toute bonne occasion de pouvoir éteindre son cerveau. On veut passer une journée pépère au boulot, rentrer chez soi et oublier.
Cela fait donc beaucoup écho à ce que tu dis ensuite:
En effet, l'un des arguments que les fanatiques de l'IA sortent souvent, c'est que comme ils sont compétents (🤣), ben ils reliront le code, le comprendront, le "own" (ahah elle est bonne celle-là, ce genre d'anglicisme me rappelle l'époque où je bossais en entreprise), comme tu dis... Mais qu'ils auront gagné énormément de temps, car ils n'auront que la revue de code à faire. Et là on sent bien que ces gens ne comprennent rien à la revue de code, ne la comprennent pas, et ne l'ont sûrement jamais bien faite de leur vie.
Une bonne partie des revues de code prennent plus de temps que si on avait tout écrit de zéro soi-même! Une bonne revue, c'est chiant, c'est pénible, c'est parfois plus éreintant à comprendre que si on écrit le code, car dans le second cas, on doit juste essayer de comprendre le code originel et son intention, alors que dans le premier cas, on doit comprendre également le nouveau code, aussi son intention, et pourquoi le développeur a choisi de corriger le bug à cet endroit précis du code (spoiler: l'endroit de la correction est souvent faux pour les débutants qui adorent corriger les symptômes plutôt que les causes d'un bug! Ce qui ne fait que rendre le code moins bons et le bug réapparaîtrait plus tard; une bonne partie de mes revues de code ont pour conclusion: "là tu es en train de prendre en compte un cas qui est censé être impossible, c'est à dire que si vraiment ta condition retourne
TRUE, ça veut dire que le processus est dans un état invalide; s'il te plaît recherche comment en est-on arrivé là, et corrige la source du problème pour que ça ne puisse plus arriver").Pourquoi on fait des revues de code, alors? D'une, c'est pour former les "nouvelles recrues" (dans le logiciel libre, la variante, ce serait pour espérer que le contributeur reste dans le coin et fasse plus de patchs; donc on le forme dans cet espoir), pour que justement la personne devienne compétente et qu'on n'ait plus trop à passer de temps en revue de code dans le futur. Également cela peut être pour avoir une seconde vision sur un problème complexe (avec l'IA, parler donc de revue de code est une aberration, puisqu'il n'y a au final qu'une seule vision! Celle du développeur qui fait la revue!). Et bien sûr, éviter des problèmes passés inaperçus au premier développeur. Mais en réalité, à un moment donné, on veut tous essayer de s'alléger la tâche, donc à un moment donné, on fait moins gaffe à la revue, et on devient paresseux le jour où on considère que le développeur dont on fait la revue de code est devenu meilleur, et qu'il peut donc gagner un brin d'indépendance. Notons qu'on ne considère pas forcément qu'il est vraiment au top niveau, mais au moins qu'il fera moins d'erreurs de débutants. Dans ces conditions, on va toujours faire une revue de code pour voir s'il n'y a quand même pas de grosses erreurs flagrantes, mais la revue sera plus superficielle, et peut-être même qu'on verra quelques petites imperfections mineures mais qu'on les laissera passer (si elles sont globalement inconséquentes) ou bien qu'on se dira que le patch n'est pas idéal mais pas non plus complètement faux, et on laissera passer encore, en se disant que cette personne doit aussi apprendre. On se permet soi-même un petit peu de paresse dans notre tâche de revue. Et c'est seulement là où la revue est rapide. Mais parce qu'on a sciemment laissé passer du code non-idéal (ou qu'on l'a fait, mais pas sciemment, dans le cas des moins compétents).
Le truc, c'est aussi qu'on veut pas passer tout son temps à faire des revues de code. C'est chiant, c'est long, c'est compliqué (autant, voire plus, que l'écriture du code, car contrairement à ce que semblent penser les mauvais développeurs, il faut aussi comprendre le code pour en faire la revue! On refait donc tout le même travail qu'est censé avoir fait le développeur initial!), et ça ne nous laisse pas de temps pour écrire notre code à nous!
Donc à chaque fois que je lis les fans de l'IA sortir que comme on fait juste la revue de code, ben au final, on peut se l'approprier et on gagne beaucoup de temps, ben la chose que ça me fait comprendre, c'est que ces gens étaient effectivement des développeurs incompétents s'ils pensent ainsi. Parce que ça veut dire qu'ils ne comprennent pas ce qu'est une bonne revue de code et n'en ont jamais fait une (bonne) eux-même de leur vie. Ce sont des gens qui sont probablement directement passé à l'étape "revue paresseuse" sans jamais avoir fait l'étape "revue en profondeur et avec compréhension complète du code" qu'ils auraient dû faire d'abord (et que je fais personnellement pour tout nouveau contributeur, et pas juste pour une ou 2 revues mais en général pour au moins une dizaine de revues pendant quelques mois, voire quelques dizaines de revues — cela dépend du contributeur et de sa capacité d'apprentissage —; et ce qui prend un temps fou).
Maintenant, c'est d'autant plus chiant car il est bien connu que ces développeurs incompétents, ce seront ceux qui finiront aux postes à responsabilité en contexte d'entreprise, ceux qui feront donc des décisions du genre "on va tous utiliser de l'IA, et c'est maintenant un outil obligatoire de l'entreprise".
J'ai bien vécu cela aussi en entreprise, par exemple avec le jeune dont la principale compétence est "sort de polytechnique", propulsé directement à un rôle managérial, ce qui signifie en vrai que le gars est incompétent et est juste là pour "changer les choses" (on sait pas quoi, ni pourquoi, mais faut changer). J'ai une histoire comme cela où on parle de changer notre outil de suivi de bug, ce qui est une bonne idée. C'est l'outil qu'on va utiliser tous les jours, alors je demande à mon boss de présenter quelque chose, je monte un bugzilla (à l'époque, c'était le top, bien avant tous les forges modernes à la Gitlab) sur un serveur, avec des modifs pour s'adapter à l'entreprise, pour faire une démo live. Le gars de son côté a préparé ses "slides" pour présenter Jira. Il ne faisait que copier-coller des points marketing de l'entreprise qui fait Jira (Atlassian). Il n'a pas montré une seule fois le logiciel, qui s'est avéré être une usine à gaz sans nom. Mais bon "il vient de Polytechnique", il n'y a même pas eu de discussion, sa proposition a gagné avant même de la présenter (c'est à peine si les "décideurs" ont regardé ma démo). Vous comprenez, "il vient de Polytechnique".
Dans une autre entreprise, une startup cette fois, on était peu, mais ils ont réussi à choisir le pire des développeurs de l'équipe (mais le plus blabla-teur) pour en faire un manager. Celui qui faisait du mauvais code, qui arrêtait pas en plus de dire du mal des patrons lorsqu'on prenait une bière, mais qui une fois manager est devenu le pire des managers, toxique au possible.
Et le problème, c'est que ce sont ces personnes qui prendront les décisions. Personnellement je suis heureux de ne plus être en entreprise, et ce que je dis souvent, c'est que dans le contexte actuel, je doute d'autant plus que je veuille y retourner un jour.
Donc oui, l'IA, c'est un nouvel apogée de la médiocrité (mais je fais confiance aux humains qui ont su prouver dans leur histoire exceller en la matière et en repousser les limites encore et encore).
Et c'est le cas dans tous les contextes d'usage de l'IA d'ailleurs. Les mêmes problèmes de faible qualité, paresse, etc. s'appliquent. Par exemple, un bon traducteur a besoin de laisser libre cours à son imagination. S'il part d'une traduction médiocre pré-mâchée par un LLM, c'est comme un carcan dans lequel on nous demande de travailler et dont il faut se dépêtrer. Au mieux, cela fera une traduction tout juste "OK", avec énormément plus de travail que si la personne avait tout traduit de zéro. Au pire, le traducteur va devenir paresseux et va faire le minimum syndical (comme dans le cas de la revue de code paresseuse) et on se retrouvera avec une trad médiocre, voire carrément mauvaise.
Ce sera aussi le cas pour l'écriture de texte, ou bien la création d'images, voire multimédia de manière générale.
Et c'est aussi pourquoi il est important que les gens qui comprennent le problème pour leur champ d'activité ne le laisse pas passer là où ils sont moins compétents. On lit encore bien trop souvent des "L'IA, c'est horrible pour le code, mais ça marche super bien pour créer des illustrations" (signé: un développeur qui n'a jamais dessiné depuis la maternelle), ou encore "L'IA tue l'industrie du dessin, mais c'est cool pour faire des programmes pour quelqu'un pas développeur pour un sou!" (signé: un illustrateur quelconque qui veut s'essayer aux jeux vidéos) ou encore "L'IA ne remplacera jamais les acteurs, mais on comprend tout à fait l'usage pour les métiers techniques!" (je reçois des emails d'appel au secours d'organismes de gestion de droits ces derniers mois à ce sujet — ils s'égosillent sur le remplacement des acteurs par des "acteurs IA" —, parce que j'ai un gros passif dans le monde du cinéma/télé), etc. On peut le faire avec toutes les variantes et combinaisons.
J'avais fait un commentaire à ce sujet sur un article qui se plaignait des livres écrits par IA et l'illustrait... par une image générée: https://linuxfr.org/users/vendrediouletrollsauvage/liens/ces-livres-ecrits-par-ia-vendus-sur-amazon-recit-alarmiste-d-une-mere#comment-2003847
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]