Le pari de Pascal à la sauce LLM selon Ploum. Il y a une proposition intéressante, qui est de pousser les partisans des LLMs à devoir démontrer leur valeur (ce qui n'est absolument pas le cas actuellement).

Et oui, les agents, si ils n'ont pas accès à des outils leur permettant de valider l'ensemble des contraintes architecturales du logiciel, introduiront de la dette. Le seul avantage de cette méthode, c'est que ça permet de verbaliser les contraintes (du genre Sonar, archunit, et compagnie). Ca évitera peut-être à l'avenir les discussions débiles de revue de code ...

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.

Je ne dirai pas que c'est mon soft spot, mais je teste régulièrement ce genre d'outils dans un contexte professionnel, et celui-ci semble partir de bonnes prémices

Sans surprise, les LLM codent comme des stagiaires, parce que leur jeu de données d'entraînement contient beaucoup plus de code de stagiaire qu'autre chose (et qu'un LLM a besoin de très nombreux échantillons pour apprendre).

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.

Je suis à peu près sûr que le use case idéal des LLMs est la recherche sémantique. Et ce programme en est un parfait exemple.

Alors ça c'est vraiment pour moi l'approche du futur : générer le code et le confronter à de vrais tests. J'aimerais bien trouver la même chose en Java et J

Définir un modèle de données abstrait à travers un protocole est une bonne idée. Ca fait de ce quicktype un truc plutôt intéressant.
Toutefois, le mécanisme de génération de code basé uniquement sur du code JS implique d'intégrer dans mon build ce feu de poubelle de sécurité ... J'avoue que ça limite mon intérêt.

L'article est aussi vieux que Java 8, mais je pense que l'auteur tient un truc ... qui mériterait d'être porté dans l'univers magique du code généré (pour une performance optimale). Si j'avais l'influx intellectuel, je tenterai bien un truc ...

Il n'y a pas vraiment d'IA dans cet outil de diagram as code. Mais admettons ... Toujours est-il qu'il permet assez correctement de créer un diagram BPM

Une analyse très intéressante des différents codes PIN

A priori, ce plugin permet de configurer dynamiquement tout un tas de plugins d'analyse de qualité de code (PMD, JDepend et autres)

La conférence a l'air très intéressante. En tout cas la transcription fait le bon travail de traduire en texte un spectacle. Et les sujets qui y sont évoqués me parlent particulièrement, parce que je suis justement en train de lire du code sans contexte.

Un outil sympa pour prioriser les refactorings. Et en plus il s'intègre dans maven

Trier les méthodes d'une classe Java en différentes catégories est en fait bien simple ... avec Eclipse !

L'article est intéressant mais, de mémoire, la méthode pour créer des catégories de méthodes dans une grosse classe en Java est moins astucieuse (il me semble qu'il faut mettre une annotation dans la Javadoc pour qu'Eclipse construise les différentes catégories)

Euh, c'est spectaculaire ce truc qui prend une lambda et en extrait l'expression pour fournir des capacités de génération de code !

Il y a des tonnes de gens qui utilisent des formateurs génériques pour leur code (editorconfig & co). Pour ma part, j'aime que les choses soient faites par les outils spécialisés. Et pour formater le coder, je trouve que spotless agrège agréablement tout un tas d'outils de formatage.

J'ignorais complètement qu'assertj disposait d'un plugin maven permettant de générer des assertions pour les classes que j'écris. C'est très cool!