Snapkin went live in the App Store on September 24th. It got there on the sixth submission. The first five came back rejected, with seven different reasons between them. 😅

14 Oct 2026 2:34pm GMT

Snapkin is live on iPhone and Android. 😄

For the past few months, I've been working on a calorie tracker. I originally built it just for me.

14 Oct 2026 2:34pm GMT

Agentic coding lets me move very fast. A feature gets built in days. A design gets implemented in a matter of hours. Changing a layout, updating a template, reworking a flow: all of it happens at a speed I couldn't have imagined a year ago.

14 Oct 2026 2:34pm GMT

The AI Pascal's Wager

Should you accept contributions generated by LLMs in your Open Source project?

Let's put aside for a moment all the ethical/ecological/societal considerations about the use of generated code (also known as "slop" if you don't like it and "vibecode" if you do) in open source projects and consider it from a simple, practical, pragmatic point of view.

There are basically three potential positions:

1. Mostly accepting LLMs as neutral tools that contributors could use (with safeguards or not, with policy of human reviewing or not).
2. Finding a compromise or choosing not to do anything, issuing some "not yes, not no" guidelines. This is now known as the "Debian AI policy".
3. Strongly rejecting LLMs (with potential exceptions that have major safeguards).

The middle ground (position 2) may seem like the most rational position to take. It is also the default. Let's wait and not decide too quickly!

But what we can learn from Debian is that nobody is really happy with it. If we think about it from a longer-term perspective, we can infer that the middle-ground position is unsustainable. LLM generated contributions will eventually slip in despite some guardrails such as "human review is mandatory". The longer a project stays in the "middle ground", the more ineluctable the slop infection becomes.

Which is to say: not choosing or trying to choose a middle ground is basically full support of generated code, but slower. It is effectively choosing position 1 (pro-AI) without being explicit about it. It is either naive or hypocritical.

Instead of letting the world choose for you, I believe that each open source project is now facing a strong choice that has to be made urgently. Accept AI-generated contributions or not.

This is not easy.

Both choices will alienate some part of the community and some key contributors. That's sad, but a project cannot please everyone.

Now, contributors may argue whether pro-vibecode or anti-slop is better from a philosophical, ethical or pragmatic point of view. Nobody can decide what is best for a project but its key community members.

Let's try to think from a generic strategical point of view. What will be the effects of both positions on the project?

Adopting AI

PROS:

• More contributions and less time spent developing annoying stuff. While every study on the subject tends to conclude that using LLMs is actually slower than writing code yourself, let's admit that advantage.

CONS:

• Alienate a part of the community that rejects vibecoded software. In some FLOSS circles, that may include very influential users.
• Developing your project become increasingly dependent of on expensive and completely proprietary software over which you have no control.

So, in the short term, adopting AI mostly alienates some community members and abandons your independence in order to improve some (perceived) productivity.

Rejecting AI

PROS:

• Strong support from the "ethical" part of the community (see the growing number of anti-AI software lists)
• Nothing changes.

CONS:

• Alienate some contributors who really want to use AI.

When you think about it, contributors who are completely turned away by the fact that they can't use LLMs are probably contributors you don't want in your project, even if you have a Debian-like "moderate use of AI" position. People who don't want to contribute without LLMs are probably not able to review and understand the code by themselves (or they will lose that ability soon enough). To illustrate this, see the number of Pull Requests on Github were the author admits "not having the knowledge to test their own code".

So refusing contributions from those people is probably more of an advantage than a disadvantage.

More importantly, rejecting AI will not alienate any users. Nobody in the world is saying "I'm refusing to use this software because it was made by humans".

The longer-term perspective

One of the main problems with using generated code is that we still don't know what impact it could have in the long term. What will the codebase look like when each contribution is less and less understood by humans? What if AI assistants become suddenly too expensive to use and nobody understand the architecture anymore? What if huge portions of your code are, in fact, copy-pasted from another project using a different incompatible license?

Cory Doctorow compares slop to asbestos: it looks nice, shiny and it is easy to put it everywhere. But if you ever need to regain control or remove the slop, it will take years of work, at best.

Your own version of Pascal's wager

While mass marketing is trying to instil a Fear of Missing Out hysteria, the most rational and pragmatic approach is to strongly reject all AI-generated contributions to your projects. For now.

Someday, we might realise that LLMs are doing good in the world, that they are evolving toward ethical, reliable, sustainable solutions, and that people who use them are happier (try to read that sentence again without rolling your eyes). If that really happens, you could always change your AI policy. It will cost you nothing.

But if you let the slop in now, you may regret it forever… You may be forced to abandon your project.

On the other hand, if you refuse AI-generated contributions to your project right now, the worst very hypothetical regret you could ever have is "I should probably have done it sooner".

The conclusion is simple: If you are AI-agnostic, the pragmatic course of action is to strongly refuse any AI-generated contribution to your project.

• Picture of a Pascaline by Rama

14 Oct 2026 2:34pm GMT

Fuir le numérique ou bien le reconquérir ?

Le numérique est-il intrinsèquement mauvais ?

Comme le souligne Sandra, le minimalisme numérique ne vient pas du fait que le numérique soit mauvais en soi, mais juste qu'on a réussi à le rendre le pire possible sur tous les niveaux. Au niveau physique : on fait tout sur un petit écran trop brillant sans aucune sensation tactile et qui nous force à plier la nuque, au niveau psychologique avec l'addiction et l'optimisation pour les pertes de temps ainsi qu'au niveau économique : votre smartphone ne vous appartient pas vraiment, vous n'avez aucun contrôle dessus et, pire, il sert à vous espionner. Et vous allez racheter exactement le même rectangle noir tous les ans ou tous les deux ans.

• Minimalism vs Digital Minimalism (idiomdrottning.org)

Car comme le dit très bien Solderpunk, le créateur du protocole Gemini, nous croulons sous les appareils électroniques de mauvaise qualité qui envoyés au rebut (ou dans un tiroir) parce que « plus supporté par la société qui les a produit ».

Le contrôle de nos appareils nous pousse à en racheter de nouveaux, mais modifie également nos pensées au point de considérer que s'il n'y a plus de mise à jour, l'appareil se transforme soudain en presse-papier. Nous sommes tellement formatés à obéir aux grandes entreprises que nous en perdons toute créativité et toute compétence réelle avec des appareils qui sont des miracles de technologie.

• Lateral Thinking with Withered Technology (solderpunk)

Des miracles de la technologie qui fonctionne contre nous et non pas pour nous.

CodeTiger achète un robot « intelligent » et décide de bloquer l'envoi de données vers le fabricant. Ce qui entraîne à chaque fois une panne après quelque jour. Fâché, iel décide d'investiguer les entrailles de l'appareil : le robot est en fait un ordinateur tournant sous Linux qui envoie toutes ses données au fabricant, y compris la configuration de la maison, les habitudes des occupants, les codes wifi. On s'y attendait un peu. Mais, en plus, il est piloté à distance !

Une fois qu'il cesse d'envoyer ses données, quelqu'un envoie une commande pour désactiver l'appareil volontairement !

• The Day My Smart Vacuum Turned Against Me (codetiger.in)

Note: l'immonde illustration générée n'existait pas lorsque j'ai bookmarké ce site.

La fuite ?

Ce n'est pas un hasard si de plus en plus d'experts du numérique se tournent vers le retrocomputing ou le technopunk.

• La complainte du technopunk ringard (ploum.net)
• Un manifeste Offpunk (ploum.net)

Par exemple, le vénérable et très minimaliste navigateur web Dillo, relancé en 2024, après une petite décennie d'abandon.

Mais à quoi peut servir un navigateur qui ne supporte pas le JavaScript ? Bobby Hiltz explique comment il s'est mis à l'utiliser de plus en plus pour faire des recherches, lire les blogs et même écouter de la musique sur Bandcamp !

• Dillo Web Browser (bobbyhiltz.com)

Et non, ça ne scale pas. Le technopunk s'en fout de la mise à l'échelle ou de convaincre les investisseurs, il veut juste que ça fonctionne pour lui et ses potes.

• Against scale (tante.cc)

Cette même population fuit également de plus en plus la nocivité intrinsèque des réseaux sociaux.

Car suivre nos proches sur les réseaux sociaux serait en fait une mauvaise idée. Si les réseaux peuvent rapprocher des inconnus aux intérêts similaires, ce qu'ils ont fait à leurs débuts, ils peuvent également éloigner des gens proches dont les intérêts spécifiques ou les opinions diffèrent. Ils emprisonnent des groupes d'humains pleins d'énergie et de motivation dans un carcan consumériste (dédicace aux groupes Facebook qui se disent "anticapitalistes").

• Du risque de transformer nos amitiés IRL en relations parasociales (lalunemauve.fr)

Alors, certes, quitter Whatsapp n'est pas évident. Mais c'est possible.

• Résolution de la rentrée : quitter WhatsApp (www.baudelot.eu)

C'est par contre plus facile de quitter X…

Une image d'un meeting d'Hitler où une voix au milieu de la foule dit "Je reste sur X, mais c'est uniquement pour apporter de la contradiction" (posté par raphj@mamot.fr sur Mastodon)

C'est marrant, car ça me fait penser à ma nouvelle humoristique « Le dernier espoir » dans laquelle je mets justement en scène un handicapé numérique qui tente de lutter contre l'espionnage de toutes ces plateformes alors que sa famille essaye de le convaincre de les rejoindre. La nouvelle est dans le recueil « Stagiaire au spatioport Omega 3000 et autres joyeusetés que nous réserve le futur », disponible dans toutes les bonnes librairies, sur le site de l'éditeur (sans DRM) ou dans les archives d'Anna la pirate.

• Stagiaire au spatioport Omega 3000 (pvh-editions.com)

Un problème politique et social

Le pire, c'est qu'on ne vous ment (presque) pas : tout est dans les conditions que vous avez acceptées.

Nicolas Vivant insiste sur ce point : en cliquant "J'accepte", nous marquons notre accord pour être espionnés, mais, également, nous prétendons avoir l'accord de nos amis pour qu'elleux soient espionnés.

C'est notamment le cas de Whatsapp qui envoie toutes les infos de votre carnet d'adresses à Meta.

• Nous ne lisons pas les conditions d'utilisation, et c'est problématique (grenoble.ninja)

Bien que n'ayant plus de compte Meta sous quelque forme que ce soit, il existe un profil avec mon numéro de téléphone, tous les noms sous lesquels je suis renseigné dans les carnets d'adresses, un graphe de contacts qui permet de me situer précisément dans le tissu social. Sans compter les infos que j'ai données lorsque j'étais jeune et naẗf.

• Le suicide de mon compte WhatsApp (ploum.net)

Le plus effrayant, c'est que le fait que j'aie supprimé tous mes comptes doit certainement me faire apparaître dans une liste particulière qui peut-être utilisée pour tenter de me cibler avec des pubs qui vont me convaincre, puis pour s'assurer de me pourrir subtilement la vie et, enfin, pour me mettre sur la liste de "potentiels terroristes" le jour où le gouvernement de mon pays se mettra à suivre cette mode mondiale du fascisme.

Si j'étais Meta, par exemple, et que j'avais des infos sur un "réfractaire" à Meta et Google, je demanderais à Google de faire en sorte que les messages qu'il envoie via SMS se perdent un peu plus souvent. Que ses appels sonnent un peu plus dans le vide.

Nicolas oublie de préciser qu'il avait été estimé que si nous devions lire les conditions d'utilisation de tous les logiciels que nous utilisons, et leur mise à jour, 24h par jour n'y suffirait pas. L'acceptation des conditions d'utilisation est donc une pure fiction.

Le problème n'est donc pas que nous ne lisons pas les conditions d'utilisation. Le problème est que cette fiction permet aux entreprises de faire n'importe quoi. « Bien sûr que nous allons enlever son premier né pour boire son sang ! L'utilisateur a accepté ! »

Et il suffit d'une seule personne dans vos cercles sociaux qui accepte ces conditions en votre nom pour vous faire espionner.

Autrement dit, ce n'est pas de la faute de l'individu, c'est un problème 100% politique.

La preuve, c'est l'impact qu'a eu le RGPD dans le monde. Alors, certes, il n'est pas idéal et, en réalité, ne fonctionne pas vraiment.

• GDPR is a failure (nikolak.com)

Mais, quand même, le fait que tout le monde déteste le GDPR est un signe que c'est un pas dans la bonne direction. Il ne fonctionne pas vraiment, mais il fait très très peur aux grandes entreprises.

• matduggan.com

Reconquérir notre indépendance

Il est temps de réactiver vos comptes "indépendants" que vous n'utilisez pas, car "moins facile", "moins de personnes", "moins de dopamine",… Votre site perso, votre compte sur le Fediverse, vos expérimentations sur Gopher ou Gemini…

• Eternal 2020 (or not) (midnight.pub)
• Creating a Blog in Gemini:// (brennan.day)

Et surtout, de le faire avec vos petites mains, votre petit cerveau et toutes vos maladresses humaines.

Car quand vous publiez un billet de blog ou un post sur les réseaux sociaux qui a été généré par un chatbot, vos lecteurs s'en rendent compte. Très vite. Et ils arrêtent de vous lire instantanément. Et ils arrêtent de vous lire pour toujours.

Croire que ça ne se voit pas, c'est comme un fumeur qui pense que parce qu'il a éteint sa clope avant de rentrer dans une pièce, il n'empeste pas. C'est juste que le monde autour de vous est juste trop poli pour vous le dire franchement.

Comme le dit Bryan Cantrill, si vous pensez que personne ne va le remarquer, c'est que soit vous n'avez pas lu vous-même ce que vous postez, soit vous êtes devenu tellement incompétent en termes de lecture (pas d'écriture, de lecture) que vous n'êtes plus capable de lire correctement.

• The revolt of the reader (bcantrill.dtrace.org)

Comme je le disais, si vous ne prenez pas le temps de l'écrire, pourquoi devrais-je prendre le temps de le lire ?

• Soyez humains, communiquez ! (ploum.net)

Et si il n'y que la « performance » qui compte pour vous, vous êtes en train de détruire votre réputation. Pareil avec les illustrations générées. Le moteur de recherche Kagi permet de signaler les contenus qui sont du « slop » de manière à les cacher. Petit à petit des réseaux vont se mettre en place pour exclure les contenus générés. Et la réputation que vous êtes en train de construire aujourd'hui aura un effet demain. Plus vite que vous ne le pensez…

J'utilise personnellement le filtre AI Blacklist pour uBlock Origin. Il m'a arrêté bien des fois lorsque je suivais un lien. Et vous savez quoi? Je ne l'ai jamais regretté jusqu'à présent !

• AI uBlock Origin Blacklist (github.com)

D'ailleurs, il est grand temps de mettre vos filtres uBlock à jour vu qu'OpenAI tente désormais d'espionner votre comportement en ligne, même si vous êtes déconnecté de votre compte ChatGPT. J'avoue être bien content de n'en avoir jamais créé, même « pour tester ».

• ChatGPT now knows what you do on other websites via ad collector (www.buchodi.com)

Évitez le slop, évitez d'en générer et tentez de créer et de communiquer le plus loin possible des grandes plateformes privatrices. Bref, cultivez votre indépendance !

Vous allez voir, on y prend vite goût !

• Illustration : La Liberté guidant le peuple, de Delacroix

14 Oct 2026 2:34pm GMT

Ah ouais, quand même, on en est là !

À ce point immergé dans notre propre stupidité.

Durant la dernière vague de chaleur, je suis tombé sur un article dans la presse nationale belge vantant les mérites d'une application permettant de mieux survivre à la canicule. Il suffisait d'entrer sa position et quelques données techniques sur son habitation (volume, type d'isolant, exposition…) et l'application vous disait quand ouvrir et fermer vos fenêtres pour garder un maximum de fraîcheur.

Cet article m'a frappé. Ni le journaliste ni l'auteur de l'app ne se rendait compte à quel point le principe était complètement irrémédiablement débile. D'une connerie sans nom.

Car, pour conserver autant que possible la température de votre logement, il suffit de tout fermer quand l'air est plus chaud dehors et de tout ouvrir quand l'air est plus frais dehors. Si vous avez deux thermomètres, le tour est joué.

J'ai beau me creuser la tête, je n'arrive pas à trouver un seul cas de figure différent. Et si un cas très spécifique existe (baie vitrée par exemple), ce n'est pas une app qui va pouvoir vous aider.

Dans l'article, l'auteur de l'application reconnaissait n'avoir aucune formation de développeur et d'avoir « vibecodé » tout le bazar. Lui-même n'a donc aucune idée de comment fonctionne son app, même approximativement. Et le résultat est là : sans avoir testé l'app moi-même, je peux garantir que l'app ne fonctionne pas, qu'elle ne fait qu'afficher des recommandations purement aléatoires.

Et le journaliste ne s'est posé aucune question.

Ah ouais, quand même, on en est là !

Un outil pour les idiots

Si le créateur de l'app avait été un entrepreneur et avait engagé un développeur, il aurait été forcé de se confronter à des questions telles que « sur quelles bases scientifiques nous basons-nous pour le calcul ? ». Mais, grâce aux chatbots, plus besoin de cela. On peut désormais faire semblant de réaliser nos idées les plus stupides sans garde-fou. Je dis bien « faire semblant » car, comme le prouve l'exemple, au final cela ne marche pas.

Comme le dit Cory Doctorow: les patrons adorent les chatbots non parce qu'ils font le travail, mais parce qu'ils disent toujours oui et trouvent toutes vos idées géniales. C'est peut-être pour ça que je n'aime pas les chatbots: quand quelqu'un trouve toutes mes idées géniales, je me dis qu'il réfléchit encore moins que moi au sujet !

Un autre cas avait fait le buzz : une personne qui avait patiemment développé une app à travers ChatGPT, pendant des semaines. App qu'elle demandait à ChatGPT de faire tourner pour la déboguer à travers des captures d'écran générées par ChatGPT. Au final, quand cette personne avait voulu accéder au code source, ChatGPT avait fini par reconnaître qu'il n'y avait pas d'app, pas de code source, que tout était inventé en direct.

Cory Doctorow a mis le doigt sur un point crucial de cette bulle IA : si les chatbots devaient soudainement disparaître demain, rien ne changerait à part quelques collégiens qui devraient réapprendre à copier les uns sur les autres pour leurs devoirs. Les états s'empressent de vouloir développer une « IA souveraine », mais si demain Trump bloquait ChatGPT et Claude dans toute l'Europe, l'impact serait nul. Voire positifs argueront certains.

• Pluralistic: Why businesses lie about AI (01 Aug 2026) (pluralistic.net)

Comparez cela au chaos total si, soudainement, Trump bloquait Outlook, Whatsapp ou Gmail dans toute l'Europe.

Non, l'IA n'est pas la nouvelle bulle Internet

Comme le dit Cory, la bulle Internet s'est construite sur des employés qui voulaient utiliser Internet pour être plus efficaces alors que leurs patrons leur interdisaient. Des milliers de nouvelles entreprises apparaissaient chaque jour pour tenter de coloniser ce nouvel espace. La bulle IA, au contraire, est imposée par les patrons et j'ai déjà entendu de première main des témoignages de gens qui prétendent que le code qu'ils ont écrit manuellement a été généré, juste pour faire plaisir à leur boss. Certains des employés m'ont personnellement raconté faire tourner les chatbots sur des questions sans intérêt juste pour montrer à leur patron qu'ils ont utilisé des tokens.

Une personne a même reçu une réprimande pour n'avoir pas utilisé assez de tokens. Donc pour avoir fait son travail en utilisant moins d'argent que prévu.

Ah ouais, quand même, on en est là !

Et, malgré tout le ramdam, nous n'avons pas encore la moindre success-story d'une entreprise qui aurait fait fortune grâce à un produit au moins partiellement conçu par l'IA.

Si l'IA était une ruée vers l'or, des milliards seraient utilisés pour nous convaincre que les nouvelles pelles intelligentes sont la panacée, les blogs seraient remplis de témoignages comme quoi la pelle intelligente fait vraiment gagner du temps pour planter ses bégonias dans son jardin de banlieue, mais personne n'aurait encore trouvé la moindre pépite d'or. Toute la bulle tiendrait sur le fait que « Vu comme on creuse, on va forcément trouver de l'or et si un jour on trouve de l'or, mieux vaut être habitué à utiliser une Pelle Intelligente (TM) pour en profiter ».

Chose marrante, certains patrons qui poussent l'utilisation de l'IA commencent à se demander pourquoi leurs employés font de la merde.

• Shopify CEO Who Pushed Staff to Use AI Is Now Horrified by What He's Wrought (futurism.com)

Le culte de l'idée

Le problème majeur, je l'ai déjà expliqué, c'est que nous sommes biberonnés au concept de « La grande idée ». Il n'est pas un film d'action, d'aventures ou d'espionnage qui ne repose sur la découverte ou le vol d'un objet représentant « une grande idèe ». Hitchock appelle d'ailleurs ces objets des « McGuffin ».

• De la mystification de la Grande Idée (ploum.net)

Or, je me répète, l'idée seule ne vaut rien. Strictement rien ! Et une idée doit être confrontée, discutée, mise en balance pour s'affiner, se transformer et, après bien des efforts, exister.

Comme le soulignait très bien Marcello Vitali-Rosati dans « Éloge du bug », cette croyance imprègne la philosophie occidentale depuis Platon : il y a les penseurs-décideurs et les exécutants. Rien d'étonnant donc qu'un produit qui vous fait croire que vous êtes un décideur avec accès à une puissance d'exécution ait du succès. Marcello compare cette croyance au génie de la lampe d'Alladin qui, sous prétexte d'obéir à Alladin, le manipule en réalité à sa guise.

• Qu'est-ce que l'outil va faire de moi ? (ploum.net)

Décrire une idée dans ses moindres détails revient, en réalité, à la réaliser. Il est tellement compliqué de faire des spécifications exactes d'un logiciel qu'on a littéralement inventé des règles pour traduire ces spécifications en langage machine. Cela s'appelle « un langage de programmation ». Et si vous n'êtes pas capable de programmer, vous n'êtes tout simplement pas compétent pour demander à un chatbot de le faire à votre place.

Cela fait 60 ans que nous avons des langages de programmation, cela fait 60 ans que l'on tente de trouver un moyen de se passer des programmeurs (genre avec des schémas graphiques, avec des "langages de spécification"). Mais c'est impossible : les idées humaines sont par définition imprécises et floues, un ordinateur ne peut pas faire quelque chose de précis à partir d'idées floues.

Les chatbots sont un produit qui prétend réaliser votre idée sans la discuter, en acceptant tout. Les chatbots sont donc, essentiellement, une arnaque parfaite pour ce que Ed Zitron appelle les « business idiots » et que j'appelle les « Juliuses ».

• Mon collègue Julius (ploum.net)

Le résultat issu d'un chatbot est soit non-fonctionnel, ce qui est parfois marrant, soit fonctionnel, ce qui est terrifiant. Parce que cela signifie que des centaines voire des milliers de décisions n'ont pas été prises. Les choix que vous n'avez pas vus ont été aléatoirement faits par le génie d'Alladin, un algorithme opaque d'une grande entreprise américaine. Si cela ne vous terrifie pas, c'est que vous n'y avez pas réfléchi assez.

Des outils incompétents pour personnes compétentes

Nombre de projets Open Source que je fréquente sont désormais envahis de contributions générées par chatbots. J'ai été témoin d'un pseudocontributeur qui disait, en substance « voici un patch pour corriger le bug XXX. Je l'ai généré et n'étant pas codeur, je n'ai pas la compétence de savoir s'il fonctionne ».

Reconnaissons à cette personne d'être honnête et transparente. Mais si j'avais cette personne en face de moi, j'aurais envie de lui demander si elle avait réfléchi deux minutes à ce qu'elle fait. Quelle est la valeur qu'elle espère ajouter au projet ? Si résoudre le bug était juste une question de demander un patch à un chatbot, ne serait-ce pas fait depuis longtemps ?

Ah ouais, quand même, on en est là !

Il faut être honnête : j'ai été témoin de cas où je reconnais l'utilité des chatbots. Mais, sans exception, il s'agissait à chaque fois d'une personne compétente. D'une personne qui aurait pu réaliser le travail sans chatbot et a réussi à gagner un peu de temps. De l'ordre de quelques minutes à quelques jours selon ses dires. Sûrement moins, mais passons…

• AI Isn't Breaking Work. It's Already Broken. (calnewport.com)

Dans 100% des cas que j'ai entendus, il faut préciser qu'il s'agissait soit de prototypage très expérimental, soit de réaliser une tâche parfaitement absurde, mais administrativement nécessaire. J'ai moi-même codé, à la main, un générateur aléatoire de timesheets lorsque j'ai été soumis à ce régime.

Force est de constater que si vous vous posez la question de développer une app et que vous n'avez pas envie de concevoir un prototype, un petit test vibecodé pourrait éventuellement vous permettre de "tester".

Mais comme le démontre amplement l'exemple de l'application anti-canicule, même le prototypage nécessite un minimum de compréhension du problème, de compétence, bref, d'intelligence.

L'effet Tetris

Une intelligence qui nécessite de l'attention, de la concentration.

Vous vous souvenez de vos heures passées à jouer à Tetris ? Le soir, en vous endormant, est-ce que vous ne voyiez pas des pièces tomber devant vos yeux ? Moi j'ai eu ça très fort en jouant à démineur sur mon 386 et en écoutant en boucle un CD de 2unlimited (oui, je sais, mais il y a prescription). Lorsque j'entends 2unlimited aujourd'hui, 35 ans plus tard, je revois des carrés de démineur devant mes yeux.

Ce que nous apprend cette expérience c'est à quel point notre cerveau est déformé par ce à quoi nous donnons notre temps et notre attention. Ce qui peut être une bonne chose lorsque c'est intentionnel.

Mais la notification qui vient de vous interrompre est-elle intentionnelle ? La 7ème vidéo Youtube que vous regardez durant votre « pause » est-elle intentionnelle ? Et ce n'est pas parce que c'est libre que c'est mieux. Ce enième toot mastodon sur le réchauffement climatique est-il intentionnel ?

Non ? Pourtant, il déforme votre cerveau comme le faisait Tetris ou chez moi, démineur…

• Attention is all you have (alicegg.tech)

Du coup, je n'ose pas imaginer l'état du cerveau des gens qui chattent avec une IA toute la journée, ne s'interrompant que pour les notifications de leur smartphone. Surtout si ces personnes ont du pouvoir.

Ah ouais, peut‑être que ça explique pourquoi on en est là !

• Photo par Basile Morin

14 Oct 2026 2:34pm GMT

Querido Duolingo, please make those annoying puzzle pieces optional! That's it, that's the post.

Source

14 Oct 2026 2:34pm GMT

Source

14 Oct 2026 2:34pm GMT

Een oude pianist vertelt over zijn jeugd in het weeshuis en waarom hij alleen op openbare piano's speelt. Het lijkt soms een jeugd avonturenroman, maar dan wel een heel donkere. Andrea schrijft zoals ik veronderstel dat Joe piano speelde; zonder kapsones en virtuoos (zoals hij dat ook deed in het sublieme "Waak over haar"). 4/5…

Source

14 Oct 2026 2:34pm GMT

Gabrielle Deman, de jonge naar avontuur en wetenschap hunkerende dochter van een Brusselse uitgever, trok in het begin van de 20ste eeuw als eerste blanke vrouw met haar man Commandant Sillye door de toenmalige Congo-Vrijstaat. Ze fotografeerde en verzamelde insecten en vogels voor het Afrikamuseum en documenteerde haar ervaringen in dagboeken en brieven die later ook in de collectie van het…

Source

14 Oct 2026 2:34pm GMT

Ahhhh … September! Geniet ervan, ook met "Tell me I never knew that" van caroline featuring Caroline Polachek! Watch this video on YouTube.

Source

14 Oct 2026 2:34pm GMT

Proposals for main track talks for FOSDEM 2027 can now be submitted!

FOSDEM offers open source and free software developers a place to meet, share ideas and collaborate. Renowned for being highly developer-oriented, the event brings together some 8000+ geeks from all over the world.

The twenty-seventh edition will take place on Saturday 30th and Sunday 31st of January 2027 at the usual location, ULB Campus Solbosch in Brussels.

Main track presentations cover topics of interest to a significant part of our audience that do not fit into any of the usual developer rooms, perhaps because of the topic or the large size of the anticipated audience.

We're looking for both highly technical talks, and also less technical insights into areas of interest to open source communities.

This year presentations are either 25 or 50 minutes long including audience questions.

Submission for talks in devrooms will open after devrooms are selected and announced.

The conference language is English. All content must relate to Free and Open Source Software. By participating in the event you agree to the publication of recordings, slides and other content provided under the same licence as all FOSDEM content (CC-BY). You also accept the FOSDEM Code of Conduct.

If you have questions or need help crafting a good submission, contact us at program@fosdem.org.

The deadline for submissions is 16th November.

Submit your talk here.

14 Oct 2026 2:34pm GMT

Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.

Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.

Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.

Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.

Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.

If you missed the keynote, you can watch the video below or download my slides (86 MB).

More ways to reach more people

The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.

Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.

React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.

At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.

This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.

Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.

With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.

What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.

Opening Drupal's capabilities to other software

The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.

In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.

If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.

That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.

Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.

But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.

That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.

I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.

The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.

And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:

Talk louder about Drupal

In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.

Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.

So I announced the Drupal Advocacy Program, led by the Drupal Association.

Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.

The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.

If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.

Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.

That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.

I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.

It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.

You can learn how to earn Drupal advocacy credit and submit your advocacy work.

My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.

I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.

14 Oct 2026 2:34pm GMT

PARTY TIME!

I removed the Node.js component from my configuration management repository yesterday.

Not because of some grand redesign. I deleted a reusable GitHub Action, and then realized it was the only reason Node.js was still hanging around.

The repository is Ansible, YAML, shell scripts, and a bit of Python. No JavaScript. No TypeScript. Yet somehow I was still carrying a Node.js toolchain, npm dependencies, and CI jobs that no longer served a purpose.

So out they went.

As a bonus, I also retired an old ESLint workflow. No JavaScript means no need to lint JavaScript.

Simple.

I'll admit I've never been a fan of dependency-heavy ecosystems. If I actually need the functionality, that's fine. But if a dependency tree exists purely because of historical baggage, I'd rather remove it than maintain it.

The result?

• One less runtime
• One less workflow
• Fewer dependencies
• Less attack surface
• Less maintenance

The repository is now a little smaller, a little simpler, and a little more boring.
In infrastructure work, boring is usually a compliment.

Sometimes the best improvement isn't adding something new.
It's deleting something you no longer need.

So here's to unnecessary dependencies:
May they rest in peace.

And to Node.js:

Thank you for your service. Please don't let the door hit you on the way out.

14 Oct 2026 2:34pm GMT

Recently, I've been getting a new type of comment spam on my blog.

The comments are surprisingly relevant to the articles they're posted on. They refer to the actual content of the blog post, use appropriate terminology and even sound as though someone has taken the time to read what I wrote.

Except they have that familiar, bland, generic style of AI-generated text. They say something vaguely positive about the article, perhaps add a superficial observation, and then include a link.

The link is the whole point.

I suspect these comments are generated by large language models (LLMs). Rather than posting the same generic spam message everywhere, spammers can now generate a superficially relevant comment for each individual blog post. That makes the comments harder to distinguish from genuine contributions using simple content filters.

I don't particularly mind whether someone uses AI to help write a comment. What bothers me is using AI to manufacture plausible-looking comments solely to smuggle promotional links onto other people's websites.

So I decided to address the actual problem rather than trying to determine whether a comment was written by a human or an AI.

No URLs in comments

My solution is straightforward: comments on my blog are no longer allowed to contain URLs.

I use the Code Snippets plugin to add a few small PHP snippets to WordPress.

The first removes the Website field from the comment form. The second rejects comments containing URLs. Another one prevents comment authors' names from linking to their websites, including when older comments already have a URL stored in WordPress. And finally, comments are disabled on any post older than 180 days.

This doesn't stop bots from submitting AI-generated comments. They can still generate text that refers to the article, praise the author and imitate the style of a genuine discussion.

But they can't use the comment to publish their spammy links.

That's the distinction I care about. I don't need to identify every spammer or build a perfect AI detector. I just need to remove the incentive for this particular kind of spam.

If someone genuinely wants to contribute to a discussion, they can still do so. They simply can't use my comment section as a vehicle for link promotion.

A small, pragmatic solution

This isn't a universal solution to comment spam. Spammers can adapt, and not every unwanted comment contains a URL. The URL detection is also based on pattern matching, so it isn't foolproof.

But it addresses the behaviour I'm actually seeing, without adding another dedicated plugin or trying to outsmart the latest AI-generated text.

If the bots want to keep writing bland, AI-generated comments about my blog posts, they're welcome to try.

They just won't get to leave their links.

The actual PHP code is left as an exercise to the reader.

14 Oct 2026 2:34pm GMT

Dependency updates are one of those areas where AI is often presented as an obvious win. But when you look closely, the value proposition can be surprisingly thin.

Every few months I find myself looking at a piece of automation I wrote and asking a dangerous question:

"If I deleted this today, would I miss it?"

Recently that question came up while looking at some code that uses AI to assist with commit messages for automatic dependency updates.

It's undeniably cool. And if we're being honest, "cool" has probably justified more engineering decisions than we'd like to admit. Somewhere, a developer is about to spend three days adding AI to a workflow that already takes five seconds, and nobody is stopping them.

When a bot updates a dependency, AI can inspect the diff, generate a polished commit message, summarize release notes, estimate risk, and even draft a pull request description. Give it another six months and it'll probably offer unsolicited opinions about my coding style, too. Beep-boop-beep-beep.

But do I actually need any of that?
For dependency updates specifically, I'm not convinced.

The Diff Already Explains Everything

Most dependency update pull requests are boring.
That's not a criticism. Boring is good. In fact, "boring" is one of my favorite qualities in infrastructure. Right up there with "predictable", "consistent", and "unlikely to trigger a sensory response."

A typical update looks like this:

- Newtonsoft.Json 13.0.2
+ Newtonsoft.Json 13.0.3

Or:

- actions/checkout@v3
+ actions/checkout@v4

The dependency changed. The version changed. The automated tests passed.
What more needs to be said?

An AI-generated commit message such as:

Update Newtonsoft.Json from 13.0.2 to 13.0.3 to incorporate the latest improvements and fixes.

is objectively more polished than:

chore: update thing

and considerably less polished than the commit messages written by developers who own more than one ergonomic keyboard.

But it doesn't add information.
It's merely a longer version of the diff.

The Cost of Automating the Obvious

AI systems are not free.

Even when the direct cost is negligible, there is still operational complexity:

• Prompt engineering
• API keys
• Rate limiting
• Error handling
• Monitoring
• Dependency on external services
• Additional maintenance burden

For a feature whose main purpose is generating text that developers may never read, that's a surprisingly long list.

The irony is hard to ignore.
I'm adding dependencies to manage dependency updates.

Once an Xzibit meme accurately describes your architecture, it's probably time for a design review.
Or at least a moment of honest self-reflection and perhaps a nice cup of tea.

Most Dependency Updates Require Validation, Not Summarization

The real value in dependency management isn't explaining what changed.
It's determining whether the change is safe.

Questions such as:

• Did tests pass?
• Are there breaking changes?
• Did security vulnerabilities disappear?
• Has runtime behavior changed?
• Should this be rolled out gradually?

Those are useful questions.
An automatically generated paragraph of prose is not.

If I had to choose between:

• AI-generated release summaries
• Better test coverage

I'd take better tests every time.

Where AI Actually Helps

To be clear, I'm not arguing that AI is useless in dependency management.
There are situations where it genuinely provides value.

For example:

Large Version Jumps

Updating from:

React 17 -> React 19

is not the same as:

React 19.1.0 -> 19.1.1

That's the difference between "let's merge this before lunch" and "let's spend the next three hours reading documentation for fun."

The first update may involve deprecations, migration guides, and behavioral changes spread across hundreds of pages of documentation.
Having AI summarize those changes can save time.

Dependency Investigation

When a vulnerability appears in a transitive dependency, AI can help answer questions like:

• Why do I have this package?
• Which component pulls it in?
• What are my upgrade options?

That's actual analysis.

Pull Request Triage

In environments processing hundreds of updates per week, AI can prioritize and categorize changes:

• Security-related
• Major version updates
• Low-risk patch releases
• Updates requiring manual review

Again, this is valuable because it's helping people make decisions.

The "Because We Can" Trap

One of the easiest mistakes in engineering is automating something because it is technically possible. AI makes this temptation even stronger.

You add a model call.
The output looks impressive.
Everyone nods.
Nobody wants to ask whether the feature is genuinely useful. Which is ironic, because asking uncomfortable questions is usually how I ended up adding the feature in the first place.

Six months later nobody reads the generated text, nobody remembers why it exists, and the system is carrying around a feature whose primary function is making demos more interesting.

That's usually the moment when the dangerous question returns:

"What would happen if I deleted this?"

If the answer is "nothing," deletion should be a serious option.

Simplicity Is a Feature

The software industry currently has a tendency to ask:

"How can we add AI to this?"

A more useful question is:

"What problem exists that AI uniquely solves?"

For routine dependency updates, I'm not sure there is much of a problem to solve.

• A dependency bot opens a pull request.
• The diff shows the change.
• CI validates the result.
• Humans review anything important.

That's already a remarkably effective system.

The AI-generated commit message may be neat. It may even spark a ten-minute discussion about style, consistency, and aesthetics that is somehow completely unrelated to dependency management. But aesthetically pleasing is not the same thing as necessity.

And sometimes the best engineering decision is not building something new.
Sometimes it's deleting code and discovering that nothing got worse.

Maybe Open Source Instead of Delete?

Just because I'm questioning a feature's place in my workflow doesn't mean the code itself has no value.

What started as an experiment in AI-generated commit messages evolved into a working GitHub Action. It takes a diff, calls an LLM, and produces a commit message that is often more polished than what most developers would write themselves.

The question isn't whether it works. The question is whether it solves a problem I still have. For routine dependency updates, I increasingly think the answer is "not really."

For routine dependency updates, the diff already tells the story. The generated explanation rarely influences whether I merge a change. Most of my confidence still comes from test results, release notes, and experience with the dependency itself.

But that doesn't mean the idea is universally useless.

Some teams maintain hundreds of repositories. Some want consistent commit messages. Some value automated summaries and release notes. Others simply enjoy experimenting with AI-assisted workflows.

So rather than keeping an optional AI component embedded in a critical workflow, I have extracted it into its own repository and made it public on GitHub:

https://github.com/amedee/ai-commit-message

That has a few benefits:

• My dependency update process stays simple.
• The action remains available for anyone who finds it useful.
• Future development can happen independently.
• The project can stand on its own merits. Or fail gloriously on its own merits. Open source is wonderfully impartial that way. Besides, releasing a side project to the public is significantly cheaper than buying another keyboard, graphics card, or suspiciously expensive cardigan.

In a way, open-sourcing it feels like a more honest outcome than quietly keeping it around forever. If the idea is genuinely useful, people will adopt it. If not, that's valuable feedback too. I've spent enough time collecting niche interests to know that "a surprisingly specific audience of twelve people" can still be a community.

Sometimes publishing a project is the fastest way to discover whether you've built a product, a feature, or simply an interesting experiment.

Not because I'm convinced AI-generated commit messages are essential, but because software doesn't have to be essential to be useful. Sometimes an experiment is worth sharing even after you've decided not to keep it in production.

Worst case, it becomes a small open-source artifact of a particular moment in the industry's AI enthusiasm.

Best case, somebody finds a use for it that I never did.

A Note on How This Post Was Written

Some honest truth: was this blog post (co-)written by AI?

Yes.

I gave Copilot (don't shoot me! I also use other Large Language Models) an abstract, a rough outline of the argument I wanted to make, and the source code of the GitHub Action discussed in this article. It generated an initial draft. Which, to be fair, is also how I approach many hobbies: start with an overwhelming amount of information and then spend hours reorganizing it until it feels right.

After that, though, the process looked a lot like editing any other piece of writing. I rewrote sections, changed wording, moved paragraphs around, added examples, removed points that didn't fit, and generally shaped the article into something that reflects my own opinion. In other words, the AI produced a draft and I spent the rest of the time refining presentation details until they felt correct. If that process sounds familiar, no further questions.

I can't escape the irony of using AI to help write a blog post that questions whether AI is needed for a particular problem.

That irony is intentional.
In fact, it reinforces the point I'm trying to make.

The problem was never "AI bad" versus "AI good". The question is whether AI adds enough value to justify its complexity. For writing, brainstorming, editing, and turning rough ideas into a first draft, I often find that it does. For generating commit messages for routine dependency updates, I'm much less convinced.

AI helped me write this post faster.
I'm not sure it helped me review dependency updates any better.

And that distinction is precisely why this blog post exists.

14 Oct 2026 2:34pm GMT