L'article est très bien, avec une argumentation solide, mais à mon avis trop orienté perfs. Cette tendance à associer le « vrai » programmeur, qui fait les choses bien avec attention et talent, avec le fait de ce soucier des perfs, de s'inquiéter des accès mémoire, du cache L1, du layout des structures de données, c'est néfaste. C'est tout à fait OK pour des devs de ne pas passer des nuits à optimiser chaque cycle et chaque accès mémoire. C'est même très bien. Ça ne fais pas d'eux des gros fainéants qui livrent des bouses sans s'inquiéter. D'ailleurs je pense que ça lui a été remonté puisqu'il semble avoir ajouté un paragraphe plus modéré par la suite :
Maybe you’ll never write the code that keeps a plane in the sky. Maybe you’ll never push bits that hold a human life in the balance. Fine. Most don’t. But even if you're just slapping together another CRUD app for some bloated enterprise, you still owe your users respect. You owe them dignity.
Si on enlève ce discours il reste l'essentiel que je résumerais au fait qu'on n'arrivera à rien de positif en codant sans comprendre ni même essayer de comprendre.
À mon avis cette promesse d'augmenter la productivité en livrant vite et mal ne sert qu'aux vendeurs d'IA. Pour les clients, les boîtes qui achètent ça, ça se paiera sur la durée, quand il faudra déboguer, corriger, ou optimiser ce code que personne n'a écrit ni même analysé. Mais bon, peut-être que d'ici là la boîte aura été revendue et ça ne sera plus leur problème.
J'ai lu ce matin un article de Sarah Mei qui compare les assistants de code à l'arrivée de Java, qui a remis en question les développeurs dont le travail principal était de gérer correctement la mémoire avec malloc et free (ou new et delete).
L'arrivée de Java a permis de faire des choses qui n'auraient pas été possibles avant, ou au moins a permis de les rendre économiquement viables.
C'est possible que les assistants de code trouvent une place similaire. La question est donc, que vont-ils remplacer? Probablement pas les personnes qui écrivent du code pour faire voler des avions. Mais par contre ça peut trouver son usage dans d'autre cas, je dirais quelque part entre le gros tableur Excel et le script Python pour traiter des données automatiquement. Des choses où, de toutes façons, il n'y avait déjà pas le budget pour embaucher un développeur de logiciels. Peut-être que ça ira plus loin que ça.
Il reste la question de la rentabilité par rapport à un humain efficace (pour l'instant, ça fonctionne en brûlant le capital des investisseurs, mais on commence à voir des offres d'abonnement et les prix sont relativement élevés), la question du droit d'auteur pour l'entraînement des modèles, et la question du bilan énergétique et écologique.
# lecture savoureuse
Posté par steph1978 . Évalué à 10 (+8/-0).
J'ai beaucoup aimé :
Il décrit bien pourquoi ce n'est pas un "copilote" mais aussi en quoi cela peut être utile à un développeur expérimenté.
[^] # Re: lecture savoureuse
Posté par Thomas (site web personnel) . Évalué à 5 (+4/-0).
Oui.
Avec un sens certain de la formule.
[^] # Re: lecture savoureuse
Posté par Julien Jorge (site web personnel) . Évalué à 4 (+2/-0).
L'article est très bien, avec une argumentation solide, mais à mon avis trop orienté perfs. Cette tendance à associer le « vrai » programmeur, qui fait les choses bien avec attention et talent, avec le fait de ce soucier des perfs, de s'inquiéter des accès mémoire, du cache L1, du layout des structures de données, c'est néfaste. C'est tout à fait OK pour des devs de ne pas passer des nuits à optimiser chaque cycle et chaque accès mémoire. C'est même très bien. Ça ne fais pas d'eux des gros fainéants qui livrent des bouses sans s'inquiéter. D'ailleurs je pense que ça lui a été remonté puisqu'il semble avoir ajouté un paragraphe plus modéré par la suite :
Si on enlève ce discours il reste l'essentiel que je résumerais au fait qu'on n'arrivera à rien de positif en codant sans comprendre ni même essayer de comprendre.
À mon avis cette promesse d'augmenter la productivité en livrant vite et mal ne sert qu'aux vendeurs d'IA. Pour les clients, les boîtes qui achètent ça, ça se paiera sur la durée, quand il faudra déboguer, corriger, ou optimiser ce code que personne n'a écrit ni même analysé. Mais bon, peut-être que d'ici là la boîte aura été revendue et ça ne sera plus leur problème.
[^] # Re: lecture savoureuse
Posté par Thomas (site web personnel) . Évalué à 1 (+0/-0).
Je plussois des deux mains.
[^] # Re: lecture savoureuse
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-1).
J'ai lu ce matin un article de Sarah Mei qui compare les assistants de code à l'arrivée de Java, qui a remis en question les développeurs dont le travail principal était de gérer correctement la mémoire avec malloc et free (ou new et delete).
L'arrivée de Java a permis de faire des choses qui n'auraient pas été possibles avant, ou au moins a permis de les rendre économiquement viables.
C'est possible que les assistants de code trouvent une place similaire. La question est donc, que vont-ils remplacer? Probablement pas les personnes qui écrivent du code pour faire voler des avions. Mais par contre ça peut trouver son usage dans d'autre cas, je dirais quelque part entre le gros tableur Excel et le script Python pour traiter des données automatiquement. Des choses où, de toutes façons, il n'y avait déjà pas le budget pour embaucher un développeur de logiciels. Peut-être que ça ira plus loin que ça.
Il reste la question de la rentabilité par rapport à un humain efficace (pour l'instant, ça fonctionne en brûlant le capital des investisseurs, mais on commence à voir des offres d'abonnement et les prix sont relativement élevés), la question du droit d'auteur pour l'entraînement des modèles, et la question du bilan énergétique et écologique.
[^] # Re: lecture savoureuse
Posté par Misc (site web personnel) . Évalué à 10 (+7/-0).
Du coup, si on veut garder nos tafs, il faut encourager tout le monde à faire du copilot (rationnellement).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.