Une astuce pour récupérer le nom d'une méthode Java qui confine à la diablerie : on sérialise la référence de méthode, et on en extrait le nom de la méthode.
Je n'utilise pas docueye ... Mais je suis certain que ce genre de règle peut s'implémenter facilement dans Structurizr ...
Une société de service allemande prend une position claire sur son usage de LLM. J'aimerais bien voir plus d'articles comme ça, ça me permettrait de trouver des employeurs plus proches de mon éthique.
Avec mon excellent collègue Logan, on a eu la chance de parler d'ADR à DevLille. Dans les deux ou trois idées qu'on essaye d'apporter, il y a le modèle ACED et Cynefin, pour décider correctement quand écrire un ADR.
Un format d'atelier utilisant C4 et le DDD (et certains formats d'ateliers agiles) pour modéliser une architecture. Ca me semble aussi malin qu'efficace.
Un article permettant de comprendre en quoi les outils de mesure de l'augmentation de productivité grâce aux LLMs sont biaisés et mauvais.
Des outils de définition de stratégie. Ca paraît intéressant (et évidement très abstrait)
J'adore l'idée que jqwik (une librairie Java de test de propriétés) ait implémenté une sorte de poison pill pour LLM faisant en sorte de supprimer tous les tests JQwik quand on utilise les LLM.
Et j'adore tout autant le fait que le rapporteur du ticket ait très manifestement utilisé un LLM pour rédiger un ticket long comme un jour sans pain.
J'adore l'idée, et elle est facilement applicable en Java.
Un cadre d'architecture fonctionnel qui, comme à chaque fopis, semble rempli de belles et grosses définitions sans jamais apporter d'informations concrètes (et vu la tronche du truc, je parie que les détails sont payants)
Je vais tester Lundi ce truc histoire de voir si les conseils sont pertinents, mais je trouve en tout cas la démarche de détermination de choix techniques ou architecturaux intéressante.
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
C'ets bien la première fois que je vois SAP produire quelque chose d'utile ...
Je découvre le champ de recherche des sciences sociales computationnelles, dans lequel il semble bien que je produise du contenu ...
Un article de sceptique des LLMs qui tape juste par de nombreux aspects, tout en étant assez ... bienveillant envers les usagers de ces outils
Une nouvelle aussi ridicule qu'amusante ... Dans le monde de la sécurité, des start-ups font maintenant de l'authentique vaporware : elles annoncent un logiciel, mais ne le sortent pas, parce que ... "c'est irresponsable".
Evidement, cette tendance vient des débiles de Claude qui font des cascades marketing de neuneu avec Claude Mythos, LE nouveau LLM qui est sans doute meilleur que les précédent, mais qui est annoncé juste après que le code (ignoble) de Claude Code était été fuité par Claude Code ...
Vu que c'est le sujet de ma prochaine conférence, il va bien falloir que je lise cet article ...
Ce genre d'article est toujours très élogieux. Mais il y a deux ou trois choses qui me parlent vraiment concernant la conduite d'un processus de qualité, l'amélioration continue, la nécessaire compréhension des problèmes.
Une catégorisation intéressante des niveaux d'automatisation atteignables via des LLM. C'est intéressant, parce que ça montre où les utilisateurs veulent aller, mais terrifiant au sens où l'illusion du contrôle est parfaite.