En Corée aussi, à cause du problème des retraites, il faudra sans doute au final prolonger progressivement (...) l’âge de départ à la retraite...
À force de l’augmenter encore et encore, le point de bascule sera probablement le moment où il dépassera l’espérance de vie moyenne.
(Il me semble que la Russie en est déjà arrivée là...)
Le message de l’auteur a certes une tonalité assez forte, mais si l’on lit bien le texte, il ne dit pas « n’utilisez pas l’IA ». Il propose plutôt une manière de l’utiliser, avec comme idée centrale que les développeurs ne doivent pas eux-mêmes manquer de compétences.
Si le message de l’auteur paraît si appuyé, c’est parce qu’il a été formulé en réaction à une vision selon laquelle il deviendrait possible de développer avec Copilot (avec une nuance de forte dépendance au développement via Copilot). Dans cette perspective, il a orienté son propos de façon à dire aux développeurs de ne pas adopter une posture qui porte atteinte à leur propre valeur d’existence.
Comme l’auteur ne dit pas non plus « n’utilisez pas l’IA », au final, si l’on parle d’exploiter l’IA, cela se situera forcément quelque part dans un compromis ; en ce sens, le fond de son message rejoint assez largement ce que vous venez de répondre.
En revanche, dans ce que vous aviez écrit au départ, j’ai eu du mal à être d’accord avec la partie sur la « vision biaisée », d’où ma réponse en premier lieu.
Créer n’est qu’un début, et quand on exploite un service pendant une dizaine d’années, toutes sortes de problèmes finissent par surgir en cours de route ; pour tenir le coup à ce moment-là, il faut des bases solides... il faut apprendre.
D’abord, dans ce que je disais sur « l’utilisation de l’IA dans un domaine », il va de soi que la conception et la coordination sont assurées par des humains...
En réalité, si cela a pu se discuter autrefois, maintenant que tout le monde connaît les limites des LLM, c’est devenu tellement évident qu’il n’est même plus nécessaire de le préciser.
Ensuite, concernant le cas où des personnes sans connaissances en développement utilisent des LLM,
je ne crois pas que ni l’article, ni Hacker News, ni moi n’ayons parlé de cela, mais quoi qu’il en soit, même dans ce cas, on en est arrivé à un niveau où les utilisateurs peuvent être satisfaits des résultats.
Sinon, Bolt.new, v0 et même Cursor n’auraient sans doute pas la réputation qu’ils ont aujourd’hui.
Il est difficile de décider jusqu’où réinventer, et jusqu’où s’appuyer sur des dépendances externes.
Dans tous les cas, choisir une dépendance pour gagner du temps alors qu’on pourrait la développer soi-même, et se retrouver lié à une dépendance sans laquelle on ne peut même pas construire le service, ce sont deux choses complètement différentes.
Ce ne sera pas possible pour tout le code (comme le système d’exploitation), mais faire l’effort d’aller autant que possible dans le premier sens aidera à mieux comprendre le système.
J’ai l’impression qu’il n’y a pas un léger malentendu sur le sens voulu par l’auteur.
L’auteur met l’accent sur les performances, la stabilité et une architecture facile à maintenir, ainsi que sur la cohérence du code, pour les projets qu’il gère lui-même, et justement l’architecture et la cohérence du code font partie des domaines où les LLM actuels sont vraiment mauvais.
Le web, en particulier, est un domaine où beaucoup de gens se mettent au développement et où la mentalité du « tant que ça tourne, ça va » est très forte, si bien qu’une énorme quantité de code de faible qualité est déployée. Comme les LLM ont été entraînés sur cette base, la qualité de leurs sorties en devient absurdement basse.
Demandez simplement à GPT : « c’est pour l’intégrer dans un front web, peux-tu implémenter un algorithme de tri rapide en JS ? » Si vous ne voyez pas de problème dans le résultat produit, je pense que cette discussion n’aura pas beaucoup de sens.
> Vu les anciens posts de l’auteur, on dirait qu’il est développeur de jeux.
> Comme les connaissances et ressources en développement de jeux ne peuvent pas être apprises en masse par les LLM, contrairement aux cas d’applications CRUD, j’ai l’impression que l’auteur du texte perçoit mieux les limites des LLM.
Je l’ai lu en entier, et au final je pense que c’est précisément pour cette raison que l’auteur a un point de vue un peu biaisé.
Bien sûr, ce que dit le texte est globalement juste, dans le sens où c’est presque un discours de manuel.
Mais je pense que l’IA est déjà suffisamment performante sur le CRUD et le front-end, où elle dispose de beaucoup de données d’entraînement.
Il faut sans doute l’exploiter au mieux dans son propre domaine.
Le point n°1 est vraiment cauchemardesque, un changement que je ne veux absolument pas accepter. En arriver à rendre inutile le suivi de l’historique du code source.
J’ai demandé au bot IA de GN+ d’extraire le script YouTube pour en faire un résumé, et les performances sont vraiment bonnes.
J’avais du mal parce qu’il y avait beaucoup trop de vidéos à regarder, donc ça me paraît être une bonne chose.
Les proverbes portent un sens, mais il y a de plus en plus de gens qui les interprètent uniquement mot à mot
Si ce genre d’argument devient à la mode, la salle de réunion redevient vite un joyeux chaos comme si de rien n’était
Les accros à la paperasse s’excitent, et on répète encore chaque année les mêmes échecs
C’est très lié au droit du travail du pays concerné… Dans beaucoup d’entreprises américaines, on fait simplement tourner l’astreinte entre les équipes, et quand une période ne convient pas, on échange l’ordre. C’est généralement comme ça que ça se passe. Comme c’est contraignant… certaines entreprises ont même une équipe dédiée à l’on-call.
En Europe, il y a presque toujours une compensation distincte, soit parce que les missions ont changé, soit parce qu’il s’agit d’heures supplémentaires.
En Corée, avec le système de salaire forfaitaire global, on fait souvent ça plus ou moins à la va-vite. L’on-call est clairement du travail, mais on le présente comme si l’indemnité correspondant à ce temps relevait d’un avantage, comme si c’était une forme de “bénéfice”.
En réalité, il sera déjà difficile d’utiliser tous ces services, donc le fait qu’il y ait le MCP est un gros avantage.
Si la maintenance de l’API continue d’être bien assurée à l’avenir, je pense que cela pourra être utile.
Le matériel d’Apple est excellent, mais son logiciel est truffé de mécanismes conçus pour tenir les utilisateurs en laisse.
Même si vous voulez simplement faire tourner sur votre propre appareil une app que vous avez vous-même créée et compilée, il vous faut un abonnement à 100 dollars.
Si vous êtes développeur, que vous utilisez de petites ou moyennes apps open source et que vous les compilez vous-même pour les utiliser,
il est plus simple de prendre un Android que de devoir exploiter des vulnérabilités et jailbreaker un appareil Apple pour faire du sideloading.
Chez nous, l’astreinte était rémunérée à la moitié du taux horaire, avec une prise en charge des frais de communication, et le temps d’intervention était payé 1,5 fois comme des heures supplémentaires.
En Corée aussi, à cause du problème des retraites, il faudra sans doute au final prolonger progressivement (...) l’âge de départ à la retraite...
À force de l’augmenter encore et encore, le point de bascule sera probablement le moment où il dépassera l’espérance de vie moyenne.
(Il me semble que la Russie en est déjà arrivée là...)
Résumé,
Auteur : les développeurs doivent eux-mêmes développer et préserver leurs compétences. De toute façon, même l’IA ne fonctionne pas si bien que ça.
crawler : Hein ? Chez moi, ça marche très bien pourtant ?
superscv : Il y a beaucoup de problèmes...
crawler : Il faut juste bien l’ajuster pour l’utiliser
superscv : On s’est éloignés bien trop du message que l’auteur voulait transmettre au départ..
Le message de l’auteur a certes une tonalité assez forte, mais si l’on lit bien le texte, il ne dit pas « n’utilisez pas l’IA ». Il propose plutôt une manière de l’utiliser, avec comme idée centrale que les développeurs ne doivent pas eux-mêmes manquer de compétences.
Si le message de l’auteur paraît si appuyé, c’est parce qu’il a été formulé en réaction à une vision selon laquelle il deviendrait possible de développer avec Copilot (avec une nuance de forte dépendance au développement via Copilot). Dans cette perspective, il a orienté son propos de façon à dire aux développeurs de ne pas adopter une posture qui porte atteinte à leur propre valeur d’existence.
Comme l’auteur ne dit pas non plus « n’utilisez pas l’IA », au final, si l’on parle d’exploiter l’IA, cela se situera forcément quelque part dans un compromis ; en ce sens, le fond de son message rejoint assez largement ce que vous venez de répondre.
En revanche, dans ce que vous aviez écrit au départ, j’ai eu du mal à être d’accord avec la partie sur la « vision biaisée », d’où ma réponse en premier lieu.
Créer n’est qu’un début, et quand on exploite un service pendant une dizaine d’années, toutes sortes de problèmes finissent par surgir en cours de route ; pour tenir le coup à ce moment-là, il faut des bases solides... il faut apprendre.
D’abord, dans ce que je disais sur « l’utilisation de l’IA dans un domaine », il va de soi que la conception et la coordination sont assurées par des humains...
En réalité, si cela a pu se discuter autrefois, maintenant que tout le monde connaît les limites des LLM, c’est devenu tellement évident qu’il n’est même plus nécessaire de le préciser.
Ensuite, concernant le cas où des personnes sans connaissances en développement utilisent des LLM,
je ne crois pas que ni l’article, ni Hacker News, ni moi n’ayons parlé de cela, mais quoi qu’il en soit, même dans ce cas, on en est arrivé à un niveau où les utilisateurs peuvent être satisfaits des résultats.
Sinon, Bolt.new, v0 et même Cursor n’auraient sans doute pas la réputation qu’ils ont aujourd’hui.
Il est difficile de décider jusqu’où réinventer, et jusqu’où s’appuyer sur des dépendances externes.
Dans tous les cas, choisir une dépendance pour gagner du temps alors qu’on pourrait la développer soi-même, et se retrouver lié à une dépendance sans laquelle on ne peut même pas construire le service, ce sont deux choses complètement différentes.
Ce ne sera pas possible pour tout le code (comme le système d’exploitation), mais faire l’effort d’aller autant que possible dans le premier sens aidera à mieux comprendre le système.
J’ai l’impression qu’il n’y a pas un léger malentendu sur le sens voulu par l’auteur.
L’auteur met l’accent sur les performances, la stabilité et une architecture facile à maintenir, ainsi que sur la cohérence du code, pour les projets qu’il gère lui-même, et justement l’architecture et la cohérence du code font partie des domaines où les LLM actuels sont vraiment mauvais.
Le web, en particulier, est un domaine où beaucoup de gens se mettent au développement et où la mentalité du « tant que ça tourne, ça va » est très forte, si bien qu’une énorme quantité de code de faible qualité est déployée. Comme les LLM ont été entraînés sur cette base, la qualité de leurs sorties en devient absurdement basse.
Demandez simplement à GPT : « c’est pour l’intégrer dans un front web, peux-tu implémenter un algorithme de tri rapide en JS ? » Si vous ne voyez pas de problème dans le résultat produit, je pense que cette discussion n’aura pas beaucoup de sens.
> Vu les anciens posts de l’auteur, on dirait qu’il est développeur de jeux.
> Comme les connaissances et ressources en développement de jeux ne peuvent pas être apprises en masse par les LLM, contrairement aux cas d’applications CRUD, j’ai l’impression que l’auteur du texte perçoit mieux les limites des LLM.
Je l’ai lu en entier, et au final je pense que c’est précisément pour cette raison que l’auteur a un point de vue un peu biaisé.
Bien sûr, ce que dit le texte est globalement juste, dans le sens où c’est presque un discours de manuel.
Mais je pense que l’IA est déjà suffisamment performante sur le CRUD et le front-end, où elle dispose de beaucoup de données d’entraînement.
Il faut sans doute l’exploiter au mieux dans son propre domaine.
Une entreprise est-elle un endroit où l’on vient pour apprendre ? Ou un lieu où l’on recrée de la valeur à partir de la roue inventée par d’autres ?
https://fr.news.hada.io/topic?id=21091
Après avoir lu cet article, je me demande si c'est vraiment pertinent.
Le point n°1 est vraiment cauchemardesque, un changement que je ne veux absolument pas accepter. En arriver à rendre inutile le suivi de l’historique du code source.
J’ai demandé au bot IA de GN+ d’extraire le script YouTube pour en faire un résumé, et les performances sont vraiment bonnes.
J’avais du mal parce qu’il y avait beaucoup trop de vidéos à regarder, donc ça me paraît être une bonne chose.
C’est juste que vous n’avez jamais vu une équipe qui maîtrise vraiment Electron ~
... c’est un peu ce que ça veut dire, non ? hahaha
Les proverbes portent un sens, mais il y a de plus en plus de gens qui les interprètent uniquement mot à mot
Si ce genre d’argument devient à la mode, la salle de réunion redevient vite un joyeux chaos comme si de rien n’était
Les accros à la paperasse s’excitent, et on répète encore chaque année les mêmes échecs
C’est très lié au droit du travail du pays concerné… Dans beaucoup d’entreprises américaines, on fait simplement tourner l’astreinte entre les équipes, et quand une période ne convient pas, on échange l’ordre. C’est généralement comme ça que ça se passe. Comme c’est contraignant… certaines entreprises ont même une équipe dédiée à l’on-call.
En Europe, il y a presque toujours une compensation distincte, soit parce que les missions ont changé, soit parce qu’il s’agit d’heures supplémentaires.
En Corée, avec le système de salaire forfaitaire global, on fait souvent ça plus ou moins à la va-vite. L’on-call est clairement du travail, mais on le présente comme si l’indemnité correspondant à ce temps relevait d’un avantage, comme si c’était une forme de “bénéfice”.
En réalité, il sera déjà difficile d’utiliser tous ces services, donc le fait qu’il y ait le MCP est un gros avantage.
Si la maintenance de l’API continue d’être bien assurée à l’avenir, je pense que cela pourra être utile.
Le matériel d’Apple est excellent, mais son logiciel est truffé de mécanismes conçus pour tenir les utilisateurs en laisse.
Même si vous voulez simplement faire tourner sur votre propre appareil une app que vous avez vous-même créée et compilée, il vous faut un abonnement à 100 dollars.
Si vous êtes développeur, que vous utilisez de petites ou moyennes apps open source et que vous les compilez vous-même pour les utiliser,
il est plus simple de prendre un Android que de devoir exploiter des vulnérabilités et jailbreaker un appareil Apple pour faire du sideloading.
Chez nous, l’astreinte était rémunérée à la moitié du taux horaire, avec une prise en charge des frais de communication, et le temps d’intervention était payé 1,5 fois comme des heures supplémentaires.
On dirait que le clan C# se cache au milieu.
> Franchement, même si vous développez en Java aujourd’hui, vous n’êtes pas forcément obligé d’utiliser un produit JetBrains
Sur ce point... j’ai un peu de mal à être d’accord, hélas...