Il me semble qu'il est assez clair sur l'expressivité, même si effectivement on peut inclure dans ce terme ce qui s'adresse au compilateur. Je pense que le projet était surtout de montrer que ce qui est fonctionnellement faisable en Rust l'est aussi en C++ pour un coût équivalent. Il ne cache pas cependant que les garanties offertes par le compilateur Rust sont toutes perdues en C++.
Le coup du compte des lignes de code avec et sans tests m'a surpris aussi ; la comparaison ne tient pas la route. J'aurais aussi voulu avoir des benchmarks. Après, tout cela a été vibe-codé et sans doute vibe-rédigé donc je ne m'attends pas à une rigueur exemplaire :)
Les résultats des dernières expériences, rien que pour toi :)
J'ai donc implémenté un algo en 4 heures hors pauses. Sur ces 4 heures j'ai passé 1 h 30 sur l'implémentation initiale qui comprend l'algo et l'ajout d'un paramètre pour activer l'algo. Le paramètre n'est pas une partie difficile mais ça avait un impact sur l'existant et demandait d'aller modifier un paquet de fichiers pour le prendre en compte. Les 2 h 30 restantes sont passées à chercher et corriger deux problèmes à côté desquels j'étais passé dans l'implémentation initiale, dont un problème bien compliqué qui m'a amené à faire intervenir un collègue (qui ne comprenais pas plus que moi mais qui a apporté le soutien dont j'avais besoin pour trouver la solution).
J'ai ensuite lancé une session avec Claude en partant du commit précédant mes modifs, dans un conteneur avec toutafon, IS_SANDBOX=1, et --dangerously-skip-permissions. Je lui ai donné un court document décrivant comment compiler le projet et comment le tester et après quelques étapes de chauffe (« lit le document. », « compile le projet », « lance tel test »), je lui ai demandé de trouver telle fonction à modifier et je lui ai décrit la tâche. Il était hyper motivé, il a sorti un très juste résumé des structures de données en jeu et comment elles étaient connectées.
Il m'a ensuite posé quelques questions pour éclaircissements. Les questions montraient que s'il avait compris les connections entre les structures au niveau code, il n'avait par contre pas compris la sémantique. Soit, je réponds sincèrement à ses questions.
Et hop il se met à patcher le code. Je n'ai même pas eu le temps de lui parler du paramètre de config ! En 35 minutes après le début de la session il avait implémenté l'algo d'une manière excellente. J'étais bluffé, son algo ressemblait comme deux gouttes d'eau au mien (comme quoi il a appris des meilleurs :)). Il est allé jusqu'à utiliser la même manière relativement particulière d'indexer conditionnellement une table dans une boucle (j'avais mis une indirection : à l'itération i je traitais data[index[i]] ce qui permettait de sortir un if de la boucle et me semblait plus clair). C'était même un poil mieux parce qu'il avait en plus factorisé 3 lignes que j'avais dupliquées (j'étais simplement passé à côté de la similarité).
Je me demande même s'il a pu avoir accès à mon code, mais je ne vois pas comment. Claude est dans un conteneur et travaille dans un dossier certes versionné sous Git mais sans l'historique ni l'URL de notre dépôt. Éventuellement il se peut que le code soit sur les serveurs d'Anthropic puisque des collègues travaillent avec Claude sur le dépôt, mais j'en doute à cause de la suite.
La suite est que son code qui ressemble énormément au mien est tellement semblable qu'il a les mêmes bugs. Les deux problèmes qui m'ont pris la tête sont aussi présents !
Il est donc parti dans la recherche de corrections pour ces problèmes, et là, c'est le drame. Il a été incapable de corriger. Je l'ai fait bosser 10 h en interaction, sans lui donner la solution évidemment (sinon ça n'aurait pas été juste). Ses analyses étaient très mauvaises, toutes ses pistes allaient dans la mauvaise direction. Il est passé d'un bug côté encodeur à un crash côté décodeur, puis il s'est retrouvé à crasher l'encodeur aussi avant de tout annuler. Plein d'aller-retours à essayer des trucs, rater, revenir en arrière, ré-essayer des trucs qui n'avaient pas marché.
Voilà le bilan. 35 minutes pour coder (un peu moins) que ce que j'ai codé en 1 h 30, puis 9 h 30 à ne pas réussir à corriger deux bugs que j'ai corrigé en 2 h 30.
tu précises pas si c'est à l'aide du compilateur, d'intrinsics ou directement via de l'assembleur (inlined ou lié)
On utilise les intrinsics, c'est quand même beaucoup plus clair que de l'assembleur :)
C'est clairement utile parce que même si c'est tendance de balayer l'idée d'un coup en clamant que les compilateurs d'aujourd'hui sont performants, en pratique on a des gains de plusieurs dizaines de pourcents sur un encodage vidéo en passant quelques fonctions clés en AVX2. En fait même si le compilateur est très bon et même si on lui donne des indications à coup de __restrict et d'unreachable, on arrive quand même à faire mieux. Et puis on n'est plus à espérer en croisant les doigts pour que le compilateur active les instructions vectorielles.
C'est un des côtés les plus intéressants de ce projet. On a besoin à la fois d'optims bas niveau et algorithmiques, mais aussi de stratégies d'exploration de plus haut niveau, et des compromis à faire sur la perf et la qualité de la sortie. Le tout en essayant d'être carré et solide sur les tests. C'est très vaste :)
La pression est forte au boulot pour que nous utilisions Claude. Bien sûr un tel outil doit être évalué rigoureusement avant d'être déployé, après tout on lui donnera quasiment les clés du dev. C'est pour cela que nous avons organisé diverses expérimentations afin que les collègues pré-acquis à la cause puissent expliquer comment l'utiliser. J'insiste, il ne s'agit pas de voir si c'est une bonne idée ni même de chercher les limites de l'outil, mais directement de trouver des Bonnes Pratiques™.
Intrigués par les retours, tout à fait identiques à ce qu'on lit partout (c'est mieux que ce que j'aurais fait ! Ça m'a fait gagner, heu… allez je vais dire 60% tiens, 60% du temps de dev !), j'ai aussi expérimenté dans ce que j'espère être une évaluation rigoureuse. Car si on me proposait un prestataire pas cher avec la promesse qu'il sache tout faire, aucun doute que ça activerait l'alarme charlatanisme.
J'ai donc pris notre dépôt de code et j'ai demandé à Claude d'écrire l'implémentation optimisée en AVX2 d'une fonction du logiciel. Pour le contexte on a dans le dépôt plein de fonctions du genre foo_avx2 pour la perf et leurs équivalentes en C++ foo_c pour référence. On a un micro-benchmark qui évalue les deux, et on a une suite de tests qui vérifie que les deux sortent les mêmes résultats pour les mêmes entrées. Ma démarche d'expérimentation est la suivante : je supprime le corps de foo_avx2 et je demande à Claude de l'implémenter avec comme consigne de la rendre aussi performante que possible en termes de temps d'exécution. Je lui mets à disposition le benchmark et la suite de test, comme ça il peut s'évaluer lui-même.
Et effectivement il s'est débrouillé pour sortir une fonction valide ! Elle n'est que 50% à 300% plus lente que notre implémentation. Après de nombreuses itérations, des heures à être sur son dos en le guidant pour améliorer tel ou tel cas, il a pu produire quelque chose d'équivalent en perf.
Alors évidemment on m'a dit que je n'y croyais pas assez fort et que j'aurais du utiliser Opus 4.6 en max reasoning. J'ai donc refais l'expérience sur une autre fonction en mettant tous les curseurs à 11. Effectivement il a réfléchit très fort et a produit encore plus vite une implémentation 50% plus lente que la nôtre. J'ai à nouveau itéré jusqu'à aligner les perfs avec notre implémentation sans jamais réussir à l'égaler.
Dans les deux cas j'ai ensuite fait une revue du code. Le première fonction est implémentée de manière acceptable sans plus, la seconde est dégueux. Du code dégueux et plus lent, c'est ce qu'a produit Claude.
Et là je me sens seul. Je vois mes confrères grisés par l'expérience, jurant que je devrais essayer c'est trop bon, aveuglés par l'amour tels des ados épris dans une relation interdite, mais chacun de mes essais est un flop. Aucune montée d'adrénaline, les niveaux d'endorphine au plus bas, je me retrouve face à un énorme étron dans le code tandis que derrière moi toute l'industrie, euphorique, s'égosille : « Mange ! Mange ! ».
On nous rabâche le fait que l'on doit own la sortie de Claude mais pour moi ça ne fait aucun doute que personne ne saura ce qu'il se passe dans nos logiciels. 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.
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 ?
Cette semaine je ferai un autre essai plus orienté fonctionnel en demandant à Claude d'implémenter un algo que j'ai moi-même précédemment implémenté. La démarche sera la même, il partira du commit précédant mes modifs, et je lui décrirai le besoin. Il n'aura plus qu'à l'implémenter. Moi il m'a fallu 4 heures de travail effectif (7 à l'horloge murale) pour aller de zéro à la validation complète de la suite de test. J'aimerais bien le voir faire mieux, genre plus rapide pour la même qualité de code. Ça m'aiderait à comprendre mes confrères.
La loi dit beaucoup de choses, tellement de choses qu'il y a des gens qui font leur métier d'interpréter ce qu'elle dit. Ils passent des mois voire des années à en débattre avec des confrères et des juges.
Alors que pourtant c'est simple, il suffit d'aller sur LinuxFr.org où des utilisateurs ont une capacité hors du commun à distinguer le légal de l'illégal. Capacité qu'ils utilisent non pas en citant des textes de loi ou des précédents juridiques, mais plutôt pour mépriser l'équipe de modération.
L'équipe de modération se passerait bien de tout cela, des appels à la haine tout comme des délateurs, des débats stériles, des bien-pensants prêts à en venir aux mains et aux mots, si critiques des autres qu'ils n'ont plus le temps de se critiquer eux-mêmes, des demandes d'intervention mais uniquement pour les messages des autres, parce que les autres ne comprennent pas que c'est eux qui se plantent, c'est pas faute d'insister depuis des jours et des jours dans le même fil de discussion. Incroyable, ils ne veulent pas comprendre, ces autres.
Venir poser un tel journal ici pour s'en prendre à la modération sans avoir auparavant fait la démarche de contacter l'équipe, sans discuter ni proposer de pistes d'amélioration, c'est juste agressif. C'est une démarche de destruction. Je ne vois pas l'intérêt de ce journal.
En tous cas je ne vois pas comment l'un de ces acteurs pourrait ressortir en récupérant ses billes.
La pub, comme d'hab. Déjà il faut faire la meilleure IA du marché. Ensuite avec les prompts des utilisateurs on créé des profils. Lorsque l'IA répond on passe le prompt et le profil aux annonceurs, et on injecte la pub direct dans la réponse comme si ça venait du LLM. Avec l'argent des annonceurs et investisseurs on maintient les prix bas jusqu'à tuer la compétition. Puis on fait ce qu'il faut pour augmenter le revenu.
C'est difficile pour un nouveau d'entrer dans une pièce où se retrouvent des milliers de personnes se côtoyant depuis 20 ans et où chaque intervention est vue et jugée par tous. Viens sur LinuxFr, tu vas te faire mépriser si t'as un unique logiciel proprio dans ta chaîne, tu vas te faire tacler si tu mets le -eur sans le -rice, tu vas te faire troller gratuitement.
Pour moi la question n'est pas tant de l'entre-soi. C'est quel bénéfice y-a-t-il à intervenir sur LinuxFr en tant que nouveau ? Ça ne sera pas pour la visibilité car ça ne me semble pas très relayé. Je n'ai pas souvenir d'avoir vu une référence vers LinuxFr depuis un autre site d'ailleurs. Ce ne sera pas pour l'ambiance non plus comme dit plus haut, même si j'ai l'impression que ça s'est grandement amélioré. Sans doute que le plus gros intérêt est de susciter les commentaires des experts de leurs domaines qui errent ici mais ce n'est pas évident et ça demande une certaine démarche d'humilité. Parfois on peut aider les lecteurs en quelque sorte, en parlant d'un truc qu'on connaît et qui va enrichir le lecteur, mais même là, pourquoi le faire ici plutôt qu'ailleurs.
Est-ce que Benoît peut nous sortir des stats telles que le délai median entre la création d'un compte et la publication d'un contenu (par type de contenu, pour ceux qui ont contribué), ainsi que le délai médian entre le premier et le dernier contenu ?
J'ai longtemps hésité parce que ce sont des paramètres d'outils et non pas du langage. D'un autre côté le fait qu'il y ait besoin d'autant d'assistance pour faire des programmes vaguement corrects en dit long sur le langage :) On pourrait mettre -fsanitize=address & co. aussi.
C'est aussi le code qui périme le plus. Impossible de faire tourner un code qui a 10 ans.
Je pense que ça vaut le coup de comparer au C++ alors, où chaque nouvelle version s'obstine à maintenir la compatibilité avec les précédentes au point que ça empêche de corriger les problèmes. Au final vaut-il mieux une rétrocompatibilité ou s'autoriser à tout casser ?
Comme je suis français je commence par le négatif : je trouve ça malsain de pointer les gens du doigt surtout quand il font preuve de faiblesse. Citer les commentaires sans nommer les auteurs aurait été mieux, et inviter l'audience à aller répondre auxdits auteurs relève du harcèlement.
Et je termine donc par le positif : excellente présentation. J'étais clairement dans le camp de ceux qui ne voient pas l'intérêt d'une réécriture d'outils qui juste marchent mais là je comprends mieux l'intention. L'approche du dev validé par les tests upstream et l'échange avec les développeurs des GNU coreutils est exemplaire, bravo :)
Développer avec une IA est quasi obligatoire (enfin c'est mon avis) si on ne veut pas être dépassé et garder du travail dans le futur.
Mais aussi :
Comment les juniors vont‑ils faire pour entrer sur le marché du travail ?
Comment vont‑ils monter en compétence s’ils se reposent trop sur l’IA ?
Va-t-on se retrouver avec une perte de connaissance du métier ?
Ainsi que :
Le bon côté, c’est que l’IA facilite la montée en compétence et rend le développement accessible à ceux qui n’ont pas la logique.
Et j'ai l'impression que tu nous dit que l'IA ruine l'avenir des juniors mais leur facilite la vie. Ça m'a pas l'air hyper clair.
Perso en lisant ton retour ça me semble une expérience très négative. La seule qualité si je puis dire est que c'était rapide, mais en fait c'est plutôt vite-fait-mal-fait. Tu as une app qui semble faire ce que tu veux et avec laquelle tu ne veux rien avoir à faire, tu ne veux pas mettre les mains dedans.
Cet argument qui revient tout le temps, qu'il faut développer avec une IA pour garder son métier à l'avenir, c'est à mon sens purement bidon. C'est l'argument des vendeurs d'IA, ça permet de vendre, et les clients attrapés auront du mal à s'en défaire. C'est un peu comme quand on disait qu'il fallait fumer, tout le monde le fait, ça rend cool, les médecins le recommandent. Bah non, perdu, c'est négatif et ça se paye sur la durée.
Alors certes on va générer très vite une grosse quantité de code qui passe des tests et sans doute que certains arriveront à être les premiers sur un marché grâce à ça, mais je ne vois pas à quel moment ça devient un critère de qualité pour les clients ou les devs. Pour les investisseurs, oui, mais pour le reste du monde ? Une app mal fichue reste une app mal fichue, qu'elle ait été codée en 5 minutes ou en 5 mois. Et si par malheur ton app trouve un public je pense que tu vas bien souffrir à la maintenir pour suivre les demandes des utilisateurs.
Bonne idée :) Je n'avais pas pensé a faire des assets sur trois cases, j'ai tendance à réfléchir case par case. Il faudrait sans doute faire des maillons plus gros mais ça pourrait le faire.
On est pas vraiment dans la frugalité avec ce genre de projet.
Oui là dessus je suis assez d'accord, mais je ne pense pas que ça se limite à la frugalité. CMake, Ninja et Rust sont des outils qui résolvent des problèmes. Ce ne sont pas juste de nouvelles versions plus jeunes et plus fraîches d'anciens outils. Et le domaine géré par WebKit est énorme. De plus CMake et WebKit sont tous les deux en C++, un langage qui ne manque pas d'opportunités pour faire les choses inefficacement même quand on a de l'expérience :)
Rust qui compile beaucoup plus vite que C++
Mmh t'es sûr de ça ? Jusqu'ici j'ai plutôt entendu l'inverse, ce qui est plutôt ce que j'imagine quand on voit Rust comme un C++ auquel on ajoute un borrow checker et d'autres outils :)
[^] # Re: Y'a un truc qui me chiffonne
Posté par Julien Jorge (site web personnel) . En réponse au lien The Reverse Rewrite. Évalué à 4 (+2/-0).
Il me semble qu'il est assez clair sur l'expressivité, même si effectivement on peut inclure dans ce terme ce qui s'adresse au compilateur. Je pense que le projet était surtout de montrer que ce qui est fonctionnellement faisable en Rust l'est aussi en C++ pour un coût équivalent. Il ne cache pas cependant que les garanties offertes par le compilateur Rust sont toutes perdues en C++.
Le coup du compte des lignes de code avec et sans tests m'a surpris aussi ; la comparaison ne tient pas la route. J'aurais aussi voulu avoir des benchmarks. Après, tout cela a été vibe-codé et sans doute vibe-rédigé donc je ne m'attends pas à une rigueur exemplaire :)
[^] # Re: Pendant ce temps
Posté par Julien Jorge (site web personnel) . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 4 (+2/-0).
Les résultats des dernières expériences, rien que pour toi :)
J'ai donc implémenté un algo en 4 heures hors pauses. Sur ces 4 heures j'ai passé 1 h 30 sur l'implémentation initiale qui comprend l'algo et l'ajout d'un paramètre pour activer l'algo. Le paramètre n'est pas une partie difficile mais ça avait un impact sur l'existant et demandait d'aller modifier un paquet de fichiers pour le prendre en compte. Les 2 h 30 restantes sont passées à chercher et corriger deux problèmes à côté desquels j'étais passé dans l'implémentation initiale, dont un problème bien compliqué qui m'a amené à faire intervenir un collègue (qui ne comprenais pas plus que moi mais qui a apporté le soutien dont j'avais besoin pour trouver la solution).
J'ai ensuite lancé une session avec Claude en partant du commit précédant mes modifs, dans un conteneur avec toutafon, IS_SANDBOX=1, et --dangerously-skip-permissions. Je lui ai donné un court document décrivant comment compiler le projet et comment le tester et après quelques étapes de chauffe (« lit le document. », « compile le projet », « lance tel test »), je lui ai demandé de trouver telle fonction à modifier et je lui ai décrit la tâche. Il était hyper motivé, il a sorti un très juste résumé des structures de données en jeu et comment elles étaient connectées.
Il m'a ensuite posé quelques questions pour éclaircissements. Les questions montraient que s'il avait compris les connections entre les structures au niveau code, il n'avait par contre pas compris la sémantique. Soit, je réponds sincèrement à ses questions.
Et hop il se met à patcher le code. Je n'ai même pas eu le temps de lui parler du paramètre de config ! En 35 minutes après le début de la session il avait implémenté l'algo d'une manière excellente. J'étais bluffé, son algo ressemblait comme deux gouttes d'eau au mien (comme quoi il a appris des meilleurs :)). Il est allé jusqu'à utiliser la même manière relativement particulière d'indexer conditionnellement une table dans une boucle (j'avais mis une indirection : à l'itération
ije traitaisdata[index[i]]ce qui permettait de sortir unifde la boucle et me semblait plus clair). C'était même un poil mieux parce qu'il avait en plus factorisé 3 lignes que j'avais dupliquées (j'étais simplement passé à côté de la similarité).Je me demande même s'il a pu avoir accès à mon code, mais je ne vois pas comment. Claude est dans un conteneur et travaille dans un dossier certes versionné sous Git mais sans l'historique ni l'URL de notre dépôt. Éventuellement il se peut que le code soit sur les serveurs d'Anthropic puisque des collègues travaillent avec Claude sur le dépôt, mais j'en doute à cause de la suite.
La suite est que son code qui ressemble énormément au mien est tellement semblable qu'il a les mêmes bugs. Les deux problèmes qui m'ont pris la tête sont aussi présents !
Il est donc parti dans la recherche de corrections pour ces problèmes, et là, c'est le drame. Il a été incapable de corriger. Je l'ai fait bosser 10 h en interaction, sans lui donner la solution évidemment (sinon ça n'aurait pas été juste). Ses analyses étaient très mauvaises, toutes ses pistes allaient dans la mauvaise direction. Il est passé d'un bug côté encodeur à un crash côté décodeur, puis il s'est retrouvé à crasher l'encodeur aussi avant de tout annuler. Plein d'aller-retours à essayer des trucs, rater, revenir en arrière, ré-essayer des trucs qui n'avaient pas marché.
Voilà le bilan. 35 minutes pour coder (un peu moins) que ce que j'ai codé en 1 h 30, puis 9 h 30 à ne pas réussir à corriger deux bugs que j'ai corrigé en 2 h 30.
[^] # Re: Pendant ce temps
Posté par Julien Jorge (site web personnel) . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 5 (+3/-0).
On utilise les intrinsics, c'est quand même beaucoup plus clair que de l'assembleur :)
C'est clairement utile parce que même si c'est tendance de balayer l'idée d'un coup en clamant que les compilateurs d'aujourd'hui sont performants, en pratique on a des gains de plusieurs dizaines de pourcents sur un encodage vidéo en passant quelques fonctions clés en AVX2. En fait même si le compilateur est très bon et même si on lui donne des indications à coup de
__restrictet d'unreachable, on arrive quand même à faire mieux. Et puis on n'est plus à espérer en croisant les doigts pour que le compilateur active les instructions vectorielles.C'est un des côtés les plus intéressants de ce projet. On a besoin à la fois d'optims bas niveau et algorithmiques, mais aussi de stratégies d'exploration de plus haut niveau, et des compromis à faire sur la perf et la qualité de la sortie. Le tout en essayant d'être carré et solide sur les tests. C'est très vaste :)
# Pendant ce temps
Posté par Julien Jorge (site web personnel) . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 10 (+37/-0). Dernière modification le 09 avril 2026 à 15:50.
La pression est forte au boulot pour que nous utilisions Claude. Bien sûr un tel outil doit être évalué rigoureusement avant d'être déployé, après tout on lui donnera quasiment les clés du dev. C'est pour cela que nous avons organisé diverses expérimentations afin que les collègues pré-acquis à la cause puissent expliquer comment l'utiliser. J'insiste, il ne s'agit pas de voir si c'est une bonne idée ni même de chercher les limites de l'outil, mais directement de trouver des Bonnes Pratiques™.
Intrigués par les retours, tout à fait identiques à ce qu'on lit partout (c'est mieux que ce que j'aurais fait ! Ça m'a fait gagner, heu… allez je vais dire 60% tiens, 60% du temps de dev !), j'ai aussi expérimenté dans ce que j'espère être une évaluation rigoureuse. Car si on me proposait un prestataire pas cher avec la promesse qu'il sache tout faire, aucun doute que ça activerait l'alarme charlatanisme.
J'ai donc pris notre dépôt de code et j'ai demandé à Claude d'écrire l'implémentation optimisée en AVX2 d'une fonction du logiciel. Pour le contexte on a dans le dépôt plein de fonctions du genre
foo_avx2pour la perf et leurs équivalentes en C++foo_cpour référence. On a un micro-benchmark qui évalue les deux, et on a une suite de tests qui vérifie que les deux sortent les mêmes résultats pour les mêmes entrées. Ma démarche d'expérimentation est la suivante : je supprime le corps defoo_avx2et je demande à Claude de l'implémenter avec comme consigne de la rendre aussi performante que possible en termes de temps d'exécution. Je lui mets à disposition le benchmark et la suite de test, comme ça il peut s'évaluer lui-même.Et effectivement il s'est débrouillé pour sortir une fonction valide ! Elle n'est que 50% à 300% plus lente que notre implémentation. Après de nombreuses itérations, des heures à être sur son dos en le guidant pour améliorer tel ou tel cas, il a pu produire quelque chose d'équivalent en perf.
Alors évidemment on m'a dit que je n'y croyais pas assez fort et que j'aurais du utiliser Opus 4.6 en max reasoning. J'ai donc refais l'expérience sur une autre fonction en mettant tous les curseurs à 11. Effectivement il a réfléchit très fort et a produit encore plus vite une implémentation 50% plus lente que la nôtre. J'ai à nouveau itéré jusqu'à aligner les perfs avec notre implémentation sans jamais réussir à l'égaler.
Dans les deux cas j'ai ensuite fait une revue du code. Le première fonction est implémentée de manière acceptable sans plus, la seconde est dégueux. Du code dégueux et plus lent, c'est ce qu'a produit Claude.
Et là je me sens seul. Je vois mes confrères grisés par l'expérience, jurant que je devrais essayer c'est trop bon, aveuglés par l'amour tels des ados épris dans une relation interdite, mais chacun de mes essais est un flop. Aucune montée d'adrénaline, les niveaux d'endorphine au plus bas, je me retrouve face à un énorme étron dans le code tandis que derrière moi toute l'industrie, euphorique, s'égosille : « Mange ! Mange ! ».
On nous rabâche le fait que l'on doit own la sortie de Claude mais pour moi ça ne fait aucun doute que personne ne saura ce qu'il se passe dans nos logiciels. 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.
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 ?
Cette semaine je ferai un autre essai plus orienté fonctionnel en demandant à Claude d'implémenter un algo que j'ai moi-même précédemment implémenté. La démarche sera la même, il partira du commit précédant mes modifs, et je lui décrirai le besoin. Il n'aura plus qu'à l'implémenter. Moi il m'a fallu 4 heures de travail effectif (7 à l'horloge murale) pour aller de zéro à la validation complète de la suite de test. J'aimerais bien le voir faire mieux, genre plus rapide pour la même qualité de code. Ça m'aiderait à comprendre mes confrères.
[^] # Re: quelques feedbacks rapide
Posté par Julien Jorge (site web personnel) . En réponse au journal Je me lance dans un petit projet en Rust. Évalué à 3 (+1/-0).
Merci pour les retours :)
Ah bah c'est de là que venait le
#[from]que j'ai tenté d'utiliser ! J'avais croisé ça sur StackOverflow ou un blog, sans savoir d'où ça venait.Blessed liste un certain anyhow qui a l'air bien tentant aussi.
[^] # Re: ... et c'est OK de cibler quelqu'un comme ça ?
Posté par Julien Jorge (site web personnel) . En réponse au lien Systemd et la surveillance de masse. Évalué à 5 (+3/-0).
Je suis bien d'accord. L'article est un encouragement au lynchage et au harcèlement.
[^] # Re: Pas si simple…
Posté par Julien Jorge (site web personnel) . En réponse au journal Les "fachos", fascistes, nazis et autres intolérants sont-ils tolérés sur linuxfr.org ?. Évalué à 10 (+34/-12).
La loi dit beaucoup de choses, tellement de choses qu'il y a des gens qui font leur métier d'interpréter ce qu'elle dit. Ils passent des mois voire des années à en débattre avec des confrères et des juges.
Alors que pourtant c'est simple, il suffit d'aller sur LinuxFr.org où des utilisateurs ont une capacité hors du commun à distinguer le légal de l'illégal. Capacité qu'ils utilisent non pas en citant des textes de loi ou des précédents juridiques, mais plutôt pour mépriser l'équipe de modération.
L'équipe de modération se passerait bien de tout cela, des appels à la haine tout comme des délateurs, des débats stériles, des bien-pensants prêts à en venir aux mains et aux mots, si critiques des autres qu'ils n'ont plus le temps de se critiquer eux-mêmes, des demandes d'intervention mais uniquement pour les messages des autres, parce que les autres ne comprennent pas que c'est eux qui se plantent, c'est pas faute d'insister depuis des jours et des jours dans le même fil de discussion. Incroyable, ils ne veulent pas comprendre, ces autres.
Venir poser un tel journal ici pour s'en prendre à la modération sans avoir auparavant fait la démarche de contacter l'équipe, sans discuter ni proposer de pistes d'amélioration, c'est juste agressif. C'est une démarche de destruction. Je ne vois pas l'intérêt de ce journal.
[^] # Re: POGAM, c'est très bien
Posté par Julien Jorge (site web personnel) . En réponse au journal Se défendre contre l'IA générative. Évalué à 3 (+1/-0).
La pub, comme d'hab. Déjà il faut faire la meilleure IA du marché. Ensuite avec les prompts des utilisateurs on créé des profils. Lorsque l'IA répond on passe le prompt et le profil aux annonceurs, et on injecte la pub direct dans la réponse comme si ça venait du LLM. Avec l'argent des annonceurs et investisseurs on maintient les prix bas jusqu'à tuer la compétition. Puis on fait ce qu'il faut pour augmenter le revenu.
[^] # Re: Question
Posté par Julien Jorge (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de janvier 2026. Évalué à 2 (+0/-0).
Merci pour ces stats qui ont l'air effectivement plus difficiles à sortir qu'à dire :)
Un à deux ans pour proposer une dépêche ou un journal, puis un peu moins de quatre ans de contributions avant de partir.
Par contre je ne me souviens plus pourquoi je voulais savoir cela…
[^] # Re: Question
Posté par Julien Jorge (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de janvier 2026. Évalué à 3 (+1/-0).
En quoi cela est-il bénéfique pour notre communauté ? Que perdons nous à arrêter cette pratique ?
Dans quel contexte un coup de fouet non-demandé est-il une bonne chose ? N'est-ce pas tout simplement un début de violence ?
[^] # Re: Question
Posté par Julien Jorge (site web personnel) . En réponse au journal LinuxFr.org : seconde quinzaine de janvier 2026. Évalué à 4 (+2/-0).
C'est difficile pour un nouveau d'entrer dans une pièce où se retrouvent des milliers de personnes se côtoyant depuis 20 ans et où chaque intervention est vue et jugée par tous. Viens sur LinuxFr, tu vas te faire mépriser si t'as un unique logiciel proprio dans ta chaîne, tu vas te faire tacler si tu mets le -eur sans le -rice, tu vas te faire troller gratuitement.
Pour moi la question n'est pas tant de l'entre-soi. C'est quel bénéfice y-a-t-il à intervenir sur LinuxFr en tant que nouveau ? Ça ne sera pas pour la visibilité car ça ne me semble pas très relayé. Je n'ai pas souvenir d'avoir vu une référence vers LinuxFr depuis un autre site d'ailleurs. Ce ne sera pas pour l'ambiance non plus comme dit plus haut, même si j'ai l'impression que ça s'est grandement amélioré. Sans doute que le plus gros intérêt est de susciter les commentaires des experts de leurs domaines qui errent ici mais ce n'est pas évident et ça demande une certaine démarche d'humilité. Parfois on peut aider les lecteurs en quelque sorte, en parlant d'un truc qu'on connaît et qui va enrichir le lecteur, mais même là, pourquoi le faire ici plutôt qu'ailleurs.
Est-ce que Benoît peut nous sortir des stats telles que le délai median entre la création d'un compte et la publication d'un contenu (par type de contenu, pour ceux qui ont contribué), ainsi que le délai médian entre le premier et le dernier contenu ?
[^] # Re: LLM comme moteur de recherche
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 9 (+7/-0).
Non seulement la qualité du moteur de recherche s'est dégradée mais en plus la qualité du web s'est dégradée.
[^] # Re: C++
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 4 (+2/-0).
J'ai longtemps hésité parce que ce sont des paramètres d'outils et non pas du langage. D'un autre côté le fait qu'il y ait besoin d'autant d'assistance pour faire des programmes vaguement corrects en dit long sur le langage :) On pourrait mettre -fsanitize=address & co. aussi.
[^] # Re: Langage pro
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 2 (+0/-0).
Je pense que ça vaut le coup de comparer au C++ alors, où chaque nouvelle version s'obstine à maintenir la compatibilité avec les précédentes au point que ça empêche de corriger les problèmes. Au final vaut-il mieux une rétrocompatibilité ou s'autoriser à tout casser ?
[^] # Re: C++ et auto
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 2 (+0/-0).
C'est beaucoup plus clair comme ça, merci !
[^] # Re: FOSDEM talk
Posté par Julien Jorge (site web personnel) . En réponse au journal Amélioration dans GNU coreutils par les dev de uutils (en Rust) . Évalué à 5 (+3/-0).
Comme je suis français je commence par le négatif : je trouve ça malsain de pointer les gens du doigt surtout quand il font preuve de faiblesse. Citer les commentaires sans nommer les auteurs aurait été mieux, et inviter l'audience à aller répondre auxdits auteurs relève du harcèlement.
Et je termine donc par le positif : excellente présentation. J'étais clairement dans le camp de ceux qui ne voient pas l'intérêt d'une réécriture d'outils qui juste marchent mais là je comprends mieux l'intention. L'approche du dev validé par les tests upstream et l'échange avec les développeurs des GNU coreutils est exemplaire, bravo :)
[^] # Re: La suite , la suite ...
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 5 (+3/-0).
Nobles langages que tu listes ici :) Pas sûr que l'un d'eux ait subit le syndrome du mode strict ajouté tardivement, si ?
[^] # Re: Connais-tu le PHP ? C'est un langage ...
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 10 (+10/-0). Dernière modification le 06 février 2026 à 07:18.
Mais oui ! Comment ai-je pu passer à côté d'une cible aussi facile…
[^] # Re: Facile l'assembleur !
Posté par Julien Jorge (site web personnel) . En réponse au journal De la rigueur dans la programmation. Évalué à 10 (+8/-0).
En plus ta technique marche avec tous les langages !
Cela dit je t'attendais plutôt sur une autre section de l'article ;)
[^] # Re: Spine
Posté par Julien Jorge (site web personnel) . En réponse au journal Sortie de Bim! en version 14, avec des barrières. Évalué à 3 (+1/-0).
Si tu faisais dans Blender un truc dans le style d'une animation 2D à la Spine, comment l'intégrerais-tu dans le jeu ensuite ? Comme un modèle 3D ?
Perso je me tâte à modéliser les persos en 3D. Ça me simplifierait les animations je pense, mais je pars de loin.
[^] # Re: Spine
Posté par Julien Jorge (site web personnel) . En réponse au journal Sortie de Bim! en version 14, avec des barrières. Évalué à 2 (+0/-0).
Je n'ai jamais utilisé Blender mais j'ai l'impression que ça ne vas pas être léger-léger comme solution :)
# Toujours pas convaincu
Posté par Julien Jorge (site web personnel) . En réponse au journal Retour d'expérience sur le développement d'une application par l'utilisation d'IA. Évalué à 10 (+39/-1). Dernière modification le 30 janvier 2026 à 15:30.
Tu nous dit :
Mais aussi :
Ainsi que :
Et j'ai l'impression que tu nous dit que l'IA ruine l'avenir des juniors mais leur facilite la vie. Ça m'a pas l'air hyper clair.
Perso en lisant ton retour ça me semble une expérience très négative. La seule qualité si je puis dire est que c'était rapide, mais en fait c'est plutôt vite-fait-mal-fait. Tu as une app qui semble faire ce que tu veux et avec laquelle tu ne veux rien avoir à faire, tu ne veux pas mettre les mains dedans.
Cet argument qui revient tout le temps, qu'il faut développer avec une IA pour garder son métier à l'avenir, c'est à mon sens purement bidon. C'est l'argument des vendeurs d'IA, ça permet de vendre, et les clients attrapés auront du mal à s'en défaire. C'est un peu comme quand on disait qu'il fallait fumer, tout le monde le fait, ça rend cool, les médecins le recommandent. Bah non, perdu, c'est négatif et ça se paye sur la durée.
Alors certes on va générer très vite une grosse quantité de code qui passe des tests et sans doute que certains arriveront à être les premiers sur un marché grâce à ça, mais je ne vois pas à quel moment ça devient un critère de qualité pour les clients ou les devs. Pour les investisseurs, oui, mais pour le reste du monde ? Une app mal fichue reste une app mal fichue, qu'elle ait été codée en 5 minutes ou en 5 mois. Et si par malheur ton app trouve un public je pense que tu vas bien souffrir à la maintenir pour suivre les demandes des utilisateurs.
[^] # Re: Les barrières sur 3 cases ?
Posté par Julien Jorge (site web personnel) . En réponse au journal Sortie de Bim! en version 14, avec des barrières. Évalué à 5 (+3/-0).
Bonne idée :) Je n'avais pas pensé a faire des assets sur trois cases, j'ai tendance à réfléchir case par case. Il faudrait sans doute faire des maillons plus gros mais ça pourrait le faire.
[^] # Re: Exemple de produit poussé par les fabricants
Posté par Julien Jorge (site web personnel) . En réponse au journal [Hors sujet] Des tablettes lave-vaisselle tout-en-un. Évalué à 10 (+8/-0).
Peut-être en mets-tu trop ?
Sur ces sujets je recommandes les excellentes vidéos sur la chaîne Technology Connections :
[^] # Re: Est-ce un troll ?
Posté par Julien Jorge (site web personnel) . En réponse au lien "Trente ans d’open source... pour en arriver là". Évalué à 3 (+1/-0).
Oui là dessus je suis assez d'accord, mais je ne pense pas que ça se limite à la frugalité. CMake, Ninja et Rust sont des outils qui résolvent des problèmes. Ce ne sont pas juste de nouvelles versions plus jeunes et plus fraîches d'anciens outils. Et le domaine géré par WebKit est énorme. De plus CMake et WebKit sont tous les deux en C++, un langage qui ne manque pas d'opportunités pour faire les choses inefficacement même quand on a de l'expérience :)
Mmh t'es sûr de ça ? Jusqu'ici j'ai plutôt entendu l'inverse, ce qui est plutôt ce que j'imagine quand on voit Rust comme un C++ auquel on ajoute un borrow checker et d'autres outils :)