Les organes de presse qui ont porté plainte contre les voleurs de savoir ont toutes les chances de gagner, vu que ces voleurs affirment clairement leurs actes.
Et pourtant les entreprises continuent à leur donner toutes leurs données internes, protégées par "des contrats" ...
Je trouve l'idée très intéressante, mais je ne comprends pas pourquoi cet outil utilise des commentaires Java plutôt que des annotations (quoi que je pense que les annotations auraient nécessité une dépendance à déclarer ... quelque part)
Ca par exemple, encore une librairie de parser combinators ? Mais avec cette fois-ci, semble-t-il, une réflexion sur l'ergonomie ? Ben c'est pas dommage !
Une façon vraiment propre de faire du Spec Driven Development. Le seul côté négatif, c'est que le LLM sous-jacent n'a aucune notion des bonnes pratiques. Du coup, le fichier constitution.md devient vite gros ... Oh, et puis c'est assez github-centric.
C'est rigolo cet outil qui vérifie directement via checkstyle qu'on n'appelle pas d'url http définie statiquement
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).
Le monde de l'IA est toujours un peu dingue, mais eux sont spécialement dingues
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 ...
Un outil qui semble permettre de savoir quels modèles vous pouvez effectivement exécuter en local. Ca complète sans doute agréablement tous les trucs à base de ollama
Oula, cette page wikiedpia (partagée par l'excellent Tristan Nitot) fait mal.
ok, donc en novembre tout s'effondre ?
Oui, l'envie de plonger dans ce trrou là me tente de plus en plus ...
Un très bon article qui explique particulièrement bien pourquoi le code Lisp est considéré comme difficile à lire.
L'idée d'un LSP découvrant le CLASSPATH à partir des dépendances Maven est vraiment très intéressante. Ca me donne bien envie de l'essayer. Et en plus il y a un MCP (qui aidera fortement un LLM à manipuler le code Java)
Un site qui raconte les couleurs. C'est vraiment bien !
Une étude sur les développeurs.
Et en 2026, les développeurs vont vraiment mal.
Les LLMs consomment en 2025 beaucoup trop d'énergie. ET EN CONSOMMERONT 7 FOIS PLUS EN 2030 SI ON NE CHANGE RIEN. L'article est limpide et devrait aider à prendre des décisions claires. Et je trouve franchement que les décisions indiquées en conclusion sont pusilanimes, vaines.
je me garde ce toot pour plus tard, parce que c'est à peu près le coeur de ce qui me pousse vers les outils de diagram as code : garantir le sens par la syntaxe
Une citation très intéressante, qui mérite d'être appliquée à toutes les couches
J'ai un faible pour les papiers peints dynamiques (mais pas trop). Si on me propose un outil performant pour gérer ça, je prends !