Le fameux livre est encore une fois mis à contribution, cette fois-ci au service d'une critique vraiment subtile de la génération de code par LLM. Je trouve cette idée de code sans réflexion théorique vraiment intéressante, spécialement quand j'entends des collègues parler de générer du code métier avec des LLMs.

Des astuces éparses qui peuvent bien aider.

OCaml n'est pas supporté par Codingame, donc je ne risque pas de m'y mettre.
Mais le fait que ce livre soit disponible, et le fait que certains anciens collègues de confiance soient des fans, donne - un peu - envie de s'y mettre.

Les méthodes plus et minus en Groovy sont vraiment marrantes. Mais le fait de ne pas pouvoir faire map.minus(key) est aussi frustrant pour moi que pour l'auteur de cet article ... Sauf que lui a agi et ajouté ce qui lui manquait.

Un article qui semble très complet, et qui fournit tout un tas de moyens pour rendre le code Rust conforme avec les exigences classiques de production (comme par exemple l'observabilité et compagnie)

Attendez, en 2026, il y a encore des gens qui créent des éditeurs ? ok ...
Non, mais, en 2026, il y a encore des gens qui créent des éditeurs EN JAVA ? Alors ça c'est fort !

Et tous les projets mentionnés dans cette liste affirment utiliser, ou autoriser l'usage, de LLM pour produire du code

Tous ces projets affirment clairement ne pas utiliser de LLM pour produire du code. C'est bien.

Je ne connaissais pas ce jeu de programmation, qui semble exister depuis bien longtemps (ils en sont déja au 1000ème concours de code)

Ca m'a bien servi pour une cascade de rétro-ingénierie ...
(en l'occurence pour créer dynamiquement un script Groovy dans un autre script Groovy capable de lire des PlantUML pour régénérer des fichiers workspace.dsl)

Ohlala, encore du code ésotérique ...
C'est très rigolo, et très bizarre en même temps.

Avec mon excellent collègue Clément on a parlé à Devoxx de ce qu'il se passe dans votre cerveau, en particulier quand vous lisez du code.

C'est clair, c'est simple, c'est direct

Un article pas idiot sur ce qui fait une bonne revue de code. C'est très intéressant, et je pense que ça peut aider. Toutefois, je ne peux m'empêcher de penser que les revues de code sont toxiques par construction, et qu'il vaut mieux mettre autant de ces règles que possible dans des validateurs automatiques.

Une collection de lois, principes, axiomes divers, trouvée par Nicolas Frankel

Une liste de recommandations pour l'ergonomie des outils en ligne de commande. C'est très bien. Mais franchement, il y a peut-être à chose à faire pour avoir une ergonomie correcte.

Un outil permettant d'accéder à la base de données de poids d'un LLM comme, justement, à une base de données. Ca me paraît la manière la plus pertinente de reprendre un peu de déterminisme avec ces outils

Un site vraiment bien pensé pour travailler les design patterns dans le monde JS (et aussi pour comprendre comment marche JS en 2026)

J'ai un collègue à qui cette idée parlera fort

C'est niche, mais je suis toujours surpris que certaines parties du monde informatique, par fatigue, n'implémentent pas encore d'éléments d'ergonomie et de reconnaissance de formes