Ce sera un très bon baromètre si les projets sur Codeberg sont considérés comme de meilleurs qualité ou s'ils seront considérés comme obsolètes car avançant trop lentement et bourrés de failles, le débat sera tranché !
Les anti-LLM contre les pro-LLM, allez vite contribuer sur votre plateforme pour faire gagner vos chevaux favoris !
Ca me fait penser à mon oncle qui m'a initié à l'informatique il y a quelques décennies.
Il venait de s'acheter un nouvel ordinateur pour compiler plus vite. Résultat il s'est retrouvé avec des maux de tête, il a du s'octroyer des temps de pauses (cool de bosser à son compte, premier enseignement que j'ai retenu !).
L'attente et la lenteur est ce qui permet de laisser travailler son imagination et produire mieux plutôt que plus.
Quand j'ai trop de boulot pour me permettre des temps morts je passe a des tâches faciles et répétitives qui ne demandent pas de concentration. Temps mort complet ou tâche simple sur le même projet (pour ne pas perdre complètement le fil) ce n'est pas la même chose, les deux sont nécessaires.
L'utilisation des LLMs semble briser cet équilibre précaire.
Le problème est que la partie chiante on ne va pas la vérifier sinon ça perd tout son intérêt. Ce n'est pas du tout la même chose qu'un générateur déterministe, une complétion, un compilateur, un template etc. dont l'avantage est justement d'appliquer bêtement ce qu'on lui demande et de ne surtout pas faire preuve d'intelligence !
J'ai exactement la même impression.
Peut-être que c'est parce qu'on ne sait pas s'en servir ou qu'on est trop réticent pour savoir apprécier ?
Toujours est-il que j'ai vu des collègues seniors l'utiliser, y compris pour me prouver de l'intérêt. Et a chaque fois ça a été catastrophique du genre parser (mal) du json avec du regexp au lieu d'utiliser la lib standard (le collègue ne savait pas que c'était foireux il l'aurait laissé comme ça), indiquer des options de cli d'une autre commande, une mauvaise explication du fonctionnement de pgBackrest qui donnait une fausse idée de la procédure, une doc d'un code hallucinante mais qui à l'air cohérente etc.
J'ai vu aussi des juniors essayer d'apprendre avec, c'est encore pire et c'est très gênant d'avoir à tout reprendre et faire le rabat joie.
Ce qui ressort c'est que dans le tas il y a un ou deux cas qui marchent et qui semble faire oublier tout le reste. Reste qui comprend énormément de cas qui semblent marcher si on regarde pas de près. Qui va relire une doc entièrement générée vu que le but est justement de ne pas s'occuper de ce côté rébarbatif ?
Donc d'aller relativement vide pour rester dans la course. ^ :-)
Ca me fait penser au moment où on court pour rentrer en sautant dans la rame de métro, s’asseoir tout fier et s’apercevoir finalement qu'on n'a pas fait gaffe et que ça n'est pas la bonne ligne. Aller vite n'implique pas forcément d'arriver plus tôt !
Aller vite à contre-sens de ses convictions c'est le burn-out assuré.
De manière pragmatique je n'ai pas du tout l'impression qu'utiliser l'IA permette de rester dans la course. Autant pour un sprint peut-être mais pas sur un marathon. Il est trop tôt pour être fixé.
On peut lire l'article en remplaçant LLM par coke, ça marche très bien !
J'ai vraiment du mal à voir l'intérêt sur des projets libres en bénévolat quand on est passionné de dev. C'est un peu comme si on me proposait de monter en voiture pour terminer plus vite une randonnée !
Ils ne sont pas vulnérables ils sont complices.
C'est comme les guerres. Tout ce qui met la pression sur la population venant de l'extérieur entraîne une demande de protection qui justifie la délégation de pouvoir et ainsi de suite.
Avec de l'autonomie et des communs, comme proposé, aucune raison d'avoir peur, aucune raison de déléguer notre pouvoir.
Je ne pense pas qu'il faille compter sur nos gouvernants mais plutôt sur nos communs, en particulier dans le numérique où on peut agir seuls sans attendre, dans une certaine mesure.
Quelque part quand on en manque à ce point je trouve ça assez lucide d'investir dans des prothèses.
D'autant plus quand on se sait impuissant (encore de la lucidité) :
Est-ce que la plateforme va voir arriver des projets voulant montrer qu'ils n'utilisent pas de LLMs et souhaitent favoriser la convivialité humaine ou va-t-elle plutôt en perdre par ceux qui considèrent que la technologie est froide et neutre ?
C'est le premier maillon d'une chaîne qui permettra de labelliser en quelque sorte les projets humains. Cela donnera une nouvelle raison de migrer vers CodeBerg pour montrer qu'un projet respecte le copyright humain.
Ca facilitera la modération ici par ex et le choix des libs.
En Go on importe les libs avec leur URL ce qui se voit dans tous les fichiers où elles sont utilisées. Donc au premier coup d'oeuil on voit d'où elles viennent, pratique !
You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code
Très peu mais il faut les encourager. Ce sont des girouettes, elles vont dans la direction du vent et le vent c'est nous.
Mais c'est très difficile il y a tellement de vent contraire dans les milieux associatifs sur le terrain.
Le numérique a toujours été délaissé alors que l'imprimerie était au coeur des mouvements alternatifs précédents. Et aujourd'hui où il y a une amorce de prise de conscience c'est considéré comme déjà trop tard. Hors il n'est jamais trop tard, il n'a jamais été aussi facile de changer, il suffirait juste d'une impulsion.
Quand je vois des gens dire qu'ils ne veulent pas installer DeltaChat car ils ne veulent par avoir trop d'applications alors qu'ils ont whatsapp, telegram, tiktok, X & co et n'arrêtent pas de jouer à un tas d'autres…
C'est même plus compliqué que ça, la productivité d'un développeur ne signifie pas que ça sera plus rentable pour la boite, ça peut même être l'inverse.
Produire du code est rarement ce qui est le plus long, c'est le plus agréable et ça permet de monter en compétence, donc gain en motivation et compétence qui serait donc perdu.
Le pire qu'on voit aujourd'hui c'est les devs qui se font virer. Hors un dev ça n'est pas qu'un producteur de code c'est un apport d'innovation, de diversité etc. Comment une boite peut-elle espérer prospérer en virant ses employés à part à très court terme ?
Produire du code plus facilement c'est aussi moins y réfléchir en amont et donc se retrouver avec une profusion de fonctionnalités au détriment de la qualité (simplicité) pour les utilisateurs et pour la maintenance. De mon expérience, c'est justement ce tri en amont qui fait la qualité d'un produit.
A la rigueur là où on pourrait y gagner c'est pour détecter un bug ou une faille de sécurité. Mais là encore le bénéfice sera vite annulé si on a produit plus de code souvent inutile et moins réfléchi en amont.
Ca va devenir de plus en plus difficile, le lobbying est tel qu'on est déjà passé à la phase suivante où c'est à ceux qui se posent des questions sur le réel bénéfice de démontrer que ce n'est pas rentable.
Ils sont d'autant plus bons qu'ils deviennent la référence de la vérité. Tu discutes à table et quelqu'un va sortir : mais si tu vois j'ai raison je viens de vérifier sur jaipaitai.
J'ai des doutes quand à la marge de progression d'une technologie basée sur la quantité et non sur la qualité. Il est possible que l'on soit plutôt au pic vu que les ressources nécessaires sont contraintes et même s'amenuisent. Que ce soit les ressources de fonctionnement (matérielles et énergétiques) que les ressources pour l'alimenter (les auteurs de contenus). On est passé dans l'industrialisation au détriment de la r&d.
En admettant que le rendement s'améliore légèrement, ce qui risque de se passer c'est simplement qu'on l'utilise encore plus. Exactement comme le pétrole. Plus il est abordable et plus les voitures sont économes plus on roule et plus elles prennent du poids. Le progrès s'arrête là, on se sédentarise et on perd en capacité physique. Je vois déjà la même chose avec l'IA. Au début les collègues devs se défiaient avec l'IA aujourd'hui je vois les mêmes perdre en compétence par facilité.
On constate actuellement un bénéfice très modeste et à court terme dans des domaines réduits pour une consommation de ressources complètement disproportionnée, c'est d'une efficience très médiocre. Ca n'empêche pas qu'il peut y avoir des résultats mais le rapport est de fait très mauvais.
Je ne parle pas de son avis sur l'usage des LLMs mais sur l'aspect technique des LLMs en elles-même qui de fait ont un rendement extrêmement mauvais vu la quantité de ressources nécessaires par rapport aux résultats obtenus.
Concernant l'impact sur ce projet ou un autre, beaucoup de de code généré entraîne beaucoup plus de maintenance donc là aussi un rendement bénéfice / coût loin d'être positif sur le long terme jusqu'à preuve du contraire.
Quand bien même les LLM auraient un quelconque intérêt, peut-être à court terme mais probablement pas à long terme, la technologie sous-jacente est extrêmement inefficace vu le rendement ressource / résultat. Dommage de ne pas avoir son avis technique sur le sujet plutôt que son avis politique voir religieux.
[^] # Re: Pratique en cascade
Posté par wilk (site web personnel, Mastodon) . En réponse au lien La forge logicielle Codeberg bannit les projets vibe codés. Évalué à 3 (+1/-0).
Ce sera un très bon baromètre si les projets sur Codeberg sont considérés comme de meilleurs qualité ou s'ils seront considérés comme obsolètes car avançant trop lentement et bourrés de failles, le débat sera tranché !
Les anti-LLM contre les pro-LLM, allez vite contribuer sur votre plateforme pour faire gagner vos chevaux favoris !
# Tonton, pourquoi tu ronfle ?
Posté par wilk (site web personnel, Mastodon) . En réponse au lien La « vibecoding fatigue » : épuisés par l’IA, les développeurs informatiques inventent leurs propres parades. Évalué à 10 (+21/-0).
Ca me fait penser à mon oncle qui m'a initié à l'informatique il y a quelques décennies.
Il venait de s'acheter un nouvel ordinateur pour compiler plus vite. Résultat il s'est retrouvé avec des maux de tête, il a du s'octroyer des temps de pauses (cool de bosser à son compte, premier enseignement que j'ai retenu !).
L'attente et la lenteur est ce qui permet de laisser travailler son imagination et produire mieux plutôt que plus.
Quand j'ai trop de boulot pour me permettre des temps morts je passe a des tâches faciles et répétitives qui ne demandent pas de concentration. Temps mort complet ou tâche simple sur le même projet (pour ne pas perdre complètement le fil) ce n'est pas la même chose, les deux sont nécessaires.
L'utilisation des LLMs semble briser cet équilibre précaire.
[^] # Re: résumé
Posté par wilk (site web personnel, Mastodon) . En réponse au lien xfwl4 et l'utilisation des LLMs dans la réécriture en Rust du Window Manager de Xfce. Évalué à 6 (+4/-0).
Le problème est que la partie chiante on ne va pas la vérifier sinon ça perd tout son intérêt. Ce n'est pas du tout la même chose qu'un générateur déterministe, une complétion, un compilateur, un template etc. dont l'avantage est justement d'appliquer bêtement ce qu'on lui demande et de ne surtout pas faire preuve d'intelligence !
[^] # Re: résumé
Posté par wilk (site web personnel, Mastodon) . En réponse au lien xfwl4 et l'utilisation des LLMs dans la réécriture en Rust du Window Manager de Xfce. Évalué à 7 (+6/-1).
J'ai exactement la même impression.
Peut-être que c'est parce qu'on ne sait pas s'en servir ou qu'on est trop réticent pour savoir apprécier ?
Toujours est-il que j'ai vu des collègues seniors l'utiliser, y compris pour me prouver de l'intérêt. Et a chaque fois ça a été catastrophique du genre parser (mal) du json avec du regexp au lieu d'utiliser la lib standard (le collègue ne savait pas que c'était foireux il l'aurait laissé comme ça), indiquer des options de cli d'une autre commande, une mauvaise explication du fonctionnement de pgBackrest qui donnait une fausse idée de la procédure, une doc d'un code hallucinante mais qui à l'air cohérente etc.
J'ai vu aussi des juniors essayer d'apprendre avec, c'est encore pire et c'est très gênant d'avoir à tout reprendre et faire le rabat joie.
Ce qui ressort c'est que dans le tas il y a un ou deux cas qui marchent et qui semble faire oublier tout le reste. Reste qui comprend énormément de cas qui semblent marcher si on regarde pas de près. Qui va relire une doc entièrement générée vu que le but est justement de ne pas s'occuper de ce côté rébarbatif ?
[^] # Re: résumé
Posté par wilk (site web personnel, Mastodon) . En réponse au lien xfwl4 et l'utilisation des LLMs dans la réécriture en Rust du Window Manager de Xfce. Évalué à 7 (+6/-1).
Ca me fait penser au moment où on court pour rentrer en sautant dans la rame de métro, s’asseoir tout fier et s’apercevoir finalement qu'on n'a pas fait gaffe et que ça n'est pas la bonne ligne. Aller vite n'implique pas forcément d'arriver plus tôt !
Aller vite à contre-sens de ses convictions c'est le burn-out assuré.
De manière pragmatique je n'ai pas du tout l'impression qu'utiliser l'IA permette de rester dans la course. Autant pour un sprint peut-être mais pas sur un marathon. Il est trop tôt pour être fixé.
[^] # Re: résumé
Posté par wilk (site web personnel, Mastodon) . En réponse au lien xfwl4 et l'utilisation des LLMs dans la réécriture en Rust du Window Manager de Xfce. Évalué à 4 (+4/-2).
On peut lire l'article en remplaçant LLM par coke, ça marche très bien !
J'ai vraiment du mal à voir l'intérêt sur des projets libres en bénévolat quand on est passionné de dev. C'est un peu comme si on me proposait de monter en voiture pour terminer plus vite une randonnée !
[^] # Re: Résumé
Posté par wilk (site web personnel, Mastodon) . En réponse au lien La « tech » française contre le logiciel libre. Évalué à 10 (+10/-0).
Une photo de l'article :
https://framapiaf.org/@houbahoubahop/116985659958591840
[^] # Re: Je comprends pas
Posté par wilk (site web personnel, Mastodon) . En réponse au lien General Resolution: LLM usage in Debian. Évalué à 6 (+5/-1).
Debian et Linux ont longtemps été illusoires… Et pourtant…
[^] # Re: oui c'est fou !
Posté par wilk (site web personnel, Mastodon) . En réponse au journal Dévoilement de 6 mois d'enquête sur le numérique - Commission d'enquête. Évalué à 8 (+7/-1).
Ils ne sont pas vulnérables ils sont complices.
C'est comme les guerres. Tout ce qui met la pression sur la population venant de l'extérieur entraîne une demande de protection qui justifie la délégation de pouvoir et ainsi de suite.
Avec de l'autonomie et des communs, comme proposé, aucune raison d'avoir peur, aucune raison de déléguer notre pouvoir.
Je ne pense pas qu'il faille compter sur nos gouvernants mais plutôt sur nos communs, en particulier dans le numérique où on peut agir seuls sans attendre, dans une certaine mesure.
# Combler un manque
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Le vibe programme de Retailleau prévoie 23 milliards d'investissements dans les LLM et un régime de dérogation au RGPD et à l’AI Act. Évalué à 7 (+5/-0).
Quelque part quand on en manque à ce point je trouve ça assez lucide d'investir dans des prothèses.
D'autant plus quand on se sait impuissant (encore de la lucidité) :
[^] # Re: Les ressources
Posté par wilk (site web personnel, Mastodon) . En réponse au journal Blog de Codeberg sur la protection des communs contre les LLMs. Évalué à 10 (+11/-0).
Il manque la phrase suivante pour comprendre :
# Quitte ou double ?
Posté par wilk (site web personnel, Mastodon) . En réponse au journal Blog de Codeberg sur la protection des communs contre les LLMs. Évalué à 4 (+2/-0).
Est-ce que la plateforme va voir arriver des projets voulant montrer qu'ils n'utilisent pas de LLMs et souhaitent favoriser la convivialité humaine ou va-t-elle plutôt en perdre par ceux qui considèrent que la technologie est froide et neutre ?
# Pratique en cascade
Posté par wilk (site web personnel, Mastodon) . En réponse au lien La forge logicielle Codeberg bannit les projets vibe codés. Évalué à 8 (+7/-1).
C'est le premier maillon d'une chaîne qui permettra de labelliser en quelque sorte les projets humains. Cela donnera une nouvelle raison de migrer vers CodeBerg pour montrer qu'un projet respecte le copyright humain.
Ca facilitera la modération ici par ex et le choix des libs.
En Go on importe les libs avec leur URL ce qui se voit dans tous les fichiers où elles sont utilisées. Donc au premier coup d'oeuil on voit d'où elles viennent, pratique !
[^] # Re: Incroyable
Posté par wilk (site web personnel, Mastodon) . En réponse au lien La forge logicielle Codeberg bannit les projets vibe codés. Évalué à 5 (+3/-0).
Oui, on peut préciser que la raison concerne les éventuels soucis avec le copyright.
https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36109b5cddca339e4aa1473
[^] # Re: smaaaaart
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Mais FUUUUUUUUUU, firefox revient sur X, ce réseau des enfers qu'on devrait mettre à la poubelle. Évalué à 7 (+5/-0). Dernière modification le 22 juillet 2026 à 10:54.
Très peu mais il faut les encourager. Ce sont des girouettes, elles vont dans la direction du vent et le vent c'est nous.
Mais c'est très difficile il y a tellement de vent contraire dans les milieux associatifs sur le terrain.
Le numérique a toujours été délaissé alors que l'imprimerie était au coeur des mouvements alternatifs précédents. Et aujourd'hui où il y a une amorce de prise de conscience c'est considéré comme déjà trop tard. Hors il n'est jamais trop tard, il n'a jamais été aussi facile de changer, il suffirait juste d'une impulsion.
Quand je vois des gens dire qu'ils ne veulent pas installer DeltaChat car ils ne veulent par avoir trop d'applications alors qu'ils ont whatsapp, telegram, tiktok, X & co et n'arrêtent pas de jouer à un tas d'autres…
[^] # Re: Preuve empirique
Posté par wilk (site web personnel, Mastodon) . En réponse au lien il n'y a pas de preuve empirique que les LLM améliorent la productivité des développeurs. Évalué à 5 (+3/-0).
C'est même plus compliqué que ça, la productivité d'un développeur ne signifie pas que ça sera plus rentable pour la boite, ça peut même être l'inverse.
Produire du code est rarement ce qui est le plus long, c'est le plus agréable et ça permet de monter en compétence, donc gain en motivation et compétence qui serait donc perdu.
Le pire qu'on voit aujourd'hui c'est les devs qui se font virer. Hors un dev ça n'est pas qu'un producteur de code c'est un apport d'innovation, de diversité etc. Comment une boite peut-elle espérer prospérer en virant ses employés à part à très court terme ?
Produire du code plus facilement c'est aussi moins y réfléchir en amont et donc se retrouver avec une profusion de fonctionnalités au détriment de la qualité (simplicité) pour les utilisateurs et pour la maintenance. De mon expérience, c'est justement ce tri en amont qui fait la qualité d'un produit.
A la rigueur là où on pourrait y gagner c'est pour détecter un bug ou une faille de sécurité. Mais là encore le bénéfice sera vite annulé si on a produit plus de code souvent inutile et moins réfléchi en amont.
[^] # Re: Preuve empirique
Posté par wilk (site web personnel, Mastodon) . En réponse au lien il n'y a pas de preuve empirique que les LLM améliorent la productivité des développeurs. Évalué à 10 (+10/-0). Dernière modification le 19 juillet 2026 à 19:05.
Ca va devenir de plus en plus difficile, le lobbying est tel qu'on est déjà passé à la phase suivante où c'est à ceux qui se posent des questions sur le réel bénéfice de démontrer que ce n'est pas rentable.
[^] # Re: Excellent article
Posté par wilk (site web personnel, Mastodon) . En réponse au lien [Clubic] Six semaines sans cloud : j'ai confié tout mon travail à une IA locale à 4 500 €. Évalué à 8 (+8/-2).
Ils sont d'autant plus bons qu'ils deviennent la référence de la vérité. Tu discutes à table et quelqu'un va sortir : mais si tu vois j'ai raison je viens de vérifier sur jaipaitai.
[^] # Re: An Engineering Disaster
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Linus Torvalds à propos de l'utilisation des LLM. Évalué à 3 (+1/-0).
En plus le développeur devenu inutile peut servir de compost, du coup c'est un double avantage pour l'IA.
[^] # Re: An Engineering Disaster
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Linus Torvalds à propos de l'utilisation des LLM. Évalué à 5 (+3/-0).
Pour illustrer (pas envie d'ajouter un nième lien/journal sur le sujet !)
https://next.ink/247785/lia-rend-ledition-scientifique-plus-lente-de-moins-bonne-qualite-et-plus-chere/
[^] # Re: An Engineering Disaster
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Linus Torvalds à propos de l'utilisation des LLM. Évalué à 4 (+3/-1).
J'ai des doutes quand à la marge de progression d'une technologie basée sur la quantité et non sur la qualité. Il est possible que l'on soit plutôt au pic vu que les ressources nécessaires sont contraintes et même s'amenuisent. Que ce soit les ressources de fonctionnement (matérielles et énergétiques) que les ressources pour l'alimenter (les auteurs de contenus). On est passé dans l'industrialisation au détriment de la r&d.
En admettant que le rendement s'améliore légèrement, ce qui risque de se passer c'est simplement qu'on l'utilise encore plus. Exactement comme le pétrole. Plus il est abordable et plus les voitures sont économes plus on roule et plus elles prennent du poids. Le progrès s'arrête là, on se sédentarise et on perd en capacité physique. Je vois déjà la même chose avec l'IA. Au début les collègues devs se défiaient avec l'IA aujourd'hui je vois les mêmes perdre en compétence par facilité.
[^] # Re: An Engineering Disaster
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Linus Torvalds à propos de l'utilisation des LLM. Évalué à 7 (+5/-0).
On constate actuellement un bénéfice très modeste et à court terme dans des domaines réduits pour une consommation de ressources complètement disproportionnée, c'est d'une efficience très médiocre. Ca n'empêche pas qu'il peut y avoir des résultats mais le rapport est de fait très mauvais.
[^] # Re: An Engineering Disaster
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Linus Torvalds à propos de l'utilisation des LLM. Évalué à 7 (+7/-2).
Je ne parle pas de son avis sur l'usage des LLMs mais sur l'aspect technique des LLMs en elles-même qui de fait ont un rendement extrêmement mauvais vu la quantité de ressources nécessaires par rapport aux résultats obtenus.
Concernant l'impact sur ce projet ou un autre, beaucoup de de code généré entraîne beaucoup plus de maintenance donc là aussi un rendement bénéfice / coût loin d'être positif sur le long terme jusqu'à preuve du contraire.
# An Engineering Disaster
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Linus Torvalds à propos de l'utilisation des LLM. Évalué à 0 (+6/-8).
Quand bien même les LLM auraient un quelconque intérêt, peut-être à court terme mais probablement pas à long terme, la technologie sous-jacente est extrêmement inefficace vu le rendement ressource / résultat. Dommage de ne pas avoir son avis technique sur le sujet plutôt que son avis politique voir religieux.
[^] # Re: Alternatives à la représentativité
Posté par wilk (site web personnel, Mastodon) . En réponse au journal Justice à 2 vitesses (au moins). Évalué à 3 (+1/-0).
On ne perçoit pas vraiment de politique énergétique en France, plutôt du brassage de vent sans éolienne, c'est ballot.