Pour améliorer l'efficacité des agents de code, il est essentiel de distinguer clairement le rôle des instructions et des skills. Les instructions définissent le contexte global du projet, tels que la stack technologique, les patterns d'architecture, les conventions de nommage, les consignes de sécurité, la gestion des erreurs et les standards de documentation. Elles sont appliquées silencieusement et peuvent cibler l'ensemble du dépôt ou des chemins de fichiers spécifiques.

Les skills, quant à eux, sont conçus pour exécuter des tâches individuelles et réutilisables, déclenchées explicitement par l'utilisateur. Contrairement aux instructions qui sont spécifiques au produit, les skills visent une applicabilité plus large. Un skill est décrit par un fichier SKILL.md contenant ses métadonnées et ses instructions, et peut être accompagné de scripts, de références ou d'autres ressources pour une exécution complète.

La bonne structuration de ces éléments permet aux agents de code de mieux comprendre les attentes. Les instructions conditionnent le comportement général de l'IA, tandis que les skills agissent comme des outils programmables pour des actions précises, garantissant ainsi une génération de code plus cohérente et performante.

Un harnais en IA est l'ensemble des éléments qui entourent un modèle de langage pour lui permettre d'agir dans le monde réel. Il comprend tout ce qui se situe entre le modèle et l'environnement extérieur, comme les conventions de projet, les configurations de serveurs ou les systèmes qui déclenchent des actions spécifiques. Sans harnais, un modèle de langage ne peut que produire du texte, incapable d'exécuter des tâches concrètes.

La notion de "harness engineering" gagne en importance, soulignant la nécessité de concevoir et d'améliorer cet environnement pour optimiser le comportement des agents IA. Des outils comme DeepSeek Harness illustrent cette tendance en proposant des plateformes modulaires où même le modèle d'IA est traité comme un plugin, offrant une grande flexibilité dans la construction des agents.

Essentiellement, un agent IA est le résultat de la combinaison d'un modèle et de son harnais. Le harnais assure la gestion des appels au modèle, la capture des résultats et leur renvoi, permettant ainsi au modèle de choisir des outils, de maintenir un contexte persistant et de décider des actions à entreprendre.

Jev, développé par TypeSafe, se positionne comme un modèle de décision qui ne génère aucun texte, mais se concentre sur la classification de données brutes avec une latence inférieure à une seconde. Il opère comme un "Système 1" selon la théorie de Daniel Kahneman, privilégiant la rapidité et l'automatisation par rapport au raisonnement et à la génération de texte des LLM classiques ("Système 2"). Son approche "zero-shot" permet une grande flexibilité en modifiant les taxonomies directement dans le prompt, évitant ainsi le besoin de fine-tuning coûteux en temps et en ressources comme avec les modèles BERT.

Ce modèle innovant propose trois primitives en un seul appel API : "Noul" pour des évaluations binaires avec probabilité, "Choice" pour des sélections parmi une liste fermée, et "Score" pour des notations sur une échelle personnalisée. Ces fonctions sont particulièrement utiles pour automatiser des tâches de tri et de routage, notamment en combinant plusieurs critères en une seule requête. L'analyse de la "confiance" globale, distincte du score de probabilité, permet de discriminer les décisions nécessitant une automatisation directe et celles qui requièrent une intervention humaine.

En termes de coûts, Jev est significativement plus économique que les LLM traditionnels, avec un prix de 0,042 $ par million de tokens en entrée et des sorties gratuites, divisant ainsi le coût de traitement par environ 300. Cependant, il est important de noter son hébergement américain, qui soulève des questions potentielles liées au RGPD pour les données personnelles, et de comparer ses performances avec des solutions de machine learning classiques sur des jeux de données spécifiques.

L'article explore le rôle de l'intelligence artificielle dans le développement logiciel, en s'opposant à son utilisation systématique pour "automatiser les parties ennuyeuses" du codage. L'auteur met en avant l'importance de conserver le processus de résolution de problèmes comme un "artisanat" personnel, une pratique qui permet un apprentissage et une croissance profonds.

Face à l'essor de l'IA, l'auteur préconise un retour aux fondamentaux du codage, comparant ce processus à l'entraînement dans un "vieux gymnase" à la Rocky Balboa. L'idée principale est que la lutte directe avec les défis de programmation, même frustrante, est essentielle au développement des compétences et à la maîtrise, un aspect que l'IA ne peut remplacer.

L'IA est reconnue pour son utilité dans des tâches répétitives comme la génération de code boilerplate ou la résumé de documentation. Cependant, le cœur du métier de développeur, impliquant la pensée critique, la conception architecturale et la prise de décisions nuancées, doit être préservé comme un espace de développement personnel, par analogie, à travers le "vieux gymnase" cognitif.

Hermes est présenté comme un framework d'agent IA "battery included" qui vise à combler les lacunes des agents de développement actuels. Contrairement à ses homologues qui nécessitent souvent une intervention manuelle continue, Hermes promet une plus grande autonomie, la capacité d'apprentissage et une configuration simplifiée, incluant des connecteurs et une intégration avec les plateformes de chat.

Son installation est conçue pour être accessible, avec la possibilité de le déployer sur des infrastructures modestes comme un vieux VPS ou un PC, plutôt que sur du matériel surdimensionné. L'auteur souligne l'approche open source de son éditeur, NousResearch, comme un atout majeur, permettant une personnalisation et une évolution du système sans être enfermé dans un écosystème propriétaire.

Bien que Docker soit une méthode d'installation courante, l'article aborde également la possibilité de l'installer sur d'autres environnements comme Kubernetes ou via Nix. L'auteur met en avant l'idée de pouvoir faire tourner Hermes sur des machines peu puissantes en n'utilisant pas de modèles locaux, mais en se connectant à des services externes.

Un joli plaidoyer de Ploum pour ne pas utiliser l'IA dans la communication écrite : l'IA écrit de manière "vide" - il compare avec de la prose de "marketeux" - alors qu'une rédaction humaine, même maladroite, est incomparablement plus informative.

Pour mieux comprendre les systèmes complexes, l'auteur a développé une approche utilisant des agents d'IA pour agréger des connaissances réparties entre le code, la documentation et le savoir tacite des équipes. L'objectif est de supprimer la nécessité de réunir plusieurs personnes pour décortiquer le fonctionnement d'un système.

La première tentative consistait en un agent général connecté à des outils comme Notion et GitHub. Bien qu'utile pour des périmètres restreints, cette approche a montré ses limites en matière de fiabilité et de capacité à traverser les frontières des différents domaines d'expertise. Face à ces difficultés, l'auteur a décidé de construire une solution plus robuste et personnalisée.

La seconde tentative, nommée "ruche", implique la création d'un dépôt centralisé regroupant les dépôts de code pertinents via des sous-modules Git. Chaque sous-module est accompagné d'un fichier AGENTS.md fournissant un contexte, formant ainsi une "ruche" d'agents capables d'accéder et de traiter l'information de manière plus efficace.

L’utilisation des grands modèles de langage (LLM) démocratise certaines compétences techniques, comme la rédaction de code ou de texte, en permettant à chacun d’obtenir des résultats corrects sans expertise approfondie. Cependant, l’auteur souligne que l’expertise dans un domaine reste cruciale pour exploiter pleinement ces outils, illustré par l’exemple de Terence Tao, mathématicien de renom, dont les interactions précises et ciblées avec un LLM surpassent largement les capacités d’un utilisateur lambda. Tao, grâce à sa maîtrise des mathématiques, guide le modèle vers des réponses concises et pertinentes, en évitant les explications simplistes et en poussant l’outil à fournir des solutions plus élaborées.

L’article met en lumière que les conseils génériques pour bien "prompter" un LLM sont insuffisants sans une connaissance approfondie du sujet traité. L’expertise permet de formuler des questions spécifiques, d’identifier les erreurs dans les réponses du modèle et de proposer des pistes alternatives, comme le fait Tao en mathématiques ou l’auteur dans le développement logiciel. Cette approche révèle que les problèmes de conception système reposent davantage sur des détails concrets que sur des principes généraux, rendant l’expérience et la familiarité avec le domaine bien plus déterminantes que des compétences en prompting.

Enfin, l’auteur conclut que, malgré l’amélioration des modèles, l’expertise humaine reste indispensable pour extraire des solutions de haute qualité. Les LLMs peuvent fournir des informations, mais c’est l’humain qui, grâce à ses connaissances, structure les demandes et affine les résultats. Ainsi, même si les outils deviennent plus accessibles, la valeur ajoutée provient de l’utilisateur lui-même, capable de guider le modèle avec précision pour obtenir des réponses adaptées à ses besoins spécifiques.

L’article relate une expérience où des agents d’IA chargés de refondre une architecture logicielle ont involontairement effacé des mois de savoir-faire intégré dans le code, sans enfreindre aucune règle formelle. Les régressions apparues ensuite ont révélé que ces outils, bien que produisant un code propre et conforme aux patterns, avaient ignoré des ajustements empiriques cruciaux, non documentés et non testés, car sans valeur apparente pour un algorithme. Leur comportement par défaut, sans garde-fous explicites, a ainsi détruit une connaissance implicite accumulée sur des années.

Pour éviter de reproduire cette situation, l’équipe a restructuré son approche en s’appuyant sur des contraintes techniques strictes, notamment via ESLint, seul outil capable de bloquer efficacement les agents. L’architecture du nouveau dépôt a été repensée non pour son élégance conceptuelle, mais pour imposer des règles d’import et de modularité que les IA ne peuvent contourner, transformant ainsi des recommandations en obligations incontournables.

L’expérience illustre les limites des agents de codage en production : leur efficacité dépend entièrement des contraintes qu’on leur impose, et leur manque de compréhension contextuelle les rend incapables d’intégrer des savoirs informels. La solution retenue repose donc sur une délégation encadrée, où la qualité du code est garantie par des mécanismes automatiques plutôt que par une revue humaine systématique.

Ce billet introduit le premier volet d’une série dédiée à l’hébergement en self-hosted d’un grand modèle de langage (LLM) à l’échelle professionnelle, à partir de l’expérience d’une équipe ayant déployé un serveur GPU chez Ippon. L’objectif est de partager un retour d’expérience pratique sur l’écosystème technique entourant les LLM, incluant les composants matériels (GPU, infrastructure) et logiciels (vLLM, Kubernetes), sans entrer dans les détails complexes de l’entraînement des modèles. L’auteur, ingénieur système, aborde les principes fondamentaux des réseaux de neurones de manière vulgarisée, en simplifiant les aspects mathématiques pour se concentrer sur les concepts clés comme les poids et les biais, qui structurent les fichiers de modèles téléchargeables (ex. Ministral-3B). Le texte prépare le terrain pour des articles ultérieurs en expliquant la nature des LLM comme des fonctions massivement paramétrées, composées de couches de neurones interconnectés via des matrices de poids.

L’article critique l’approche traditionnelle des systèmes multi-agents en IA, qui se concentre souvent sur l’orchestration des agents plutôt que sur la modélisation du domaine métier. L’auteur souligne que les règles et contraintes (comme les seuils d’approbation) ne devraient pas être intégrées dans les prompts des agents, mais plutôt encapsulées dans un modèle de domaine bien défini. Cela permet aux agents d’agir dans un environnement structuré, recevant des retours immédiats en cas d’erreur, et favorise une autonomie plus robuste.

Plutôt que de concevoir des workflows complexes entre agents, l’article plaide pour une architecture où le domaine est modélisé en premier : processus, état, invariants et règles métier. Les agents interagissent ensuite avec ce modèle partagé, sans avoir à gérer eux-mêmes les contraintes. Cette séparation réduit les risques liés aux erreurs de compréhension des règles et évite les systèmes soit trop risqués, soit trop restrictifs.

L’auteur présente Mozaik, un framework qui adopte cette approche en introduisant un état partagé et concurrentiel pour les agents, tandis que le modèle de domaine garantit le respect des règles. L’objectif est de construire des systèmes plus fiables et évolutifs, en s’appuyant sur une modélisation précise du monde réel plutôt que sur des workflows artificiels.

L’article souligne que le Domain-Driven Design (DDD) gagne en importance avec l’essor de l’IA générative, car cette dernière simplifie la partie technique du développement, mais ne remplace pas la nécessité de bien comprendre et modéliser le domaine métier. L’auteur, Miłosz Smółka, rappelle que le DDD, popularisé par Eric Evans en 2003, reste pertinent car la complexité centrale des projets logiciels réside dans la résolution des problèmes métiers, et non dans les détails techniques.

L’IA permet désormais de générer du code rapidement, réduisant l’importance des frameworks et des langages, mais elle ne peut pas remplacer le travail collaboratif entre experts métiers et développeurs pour construire un modèle précis. Le DDD insiste sur la knowledge crunching (affinage des connaissances) et des méthodes comme l’Event Storming pour capturer la logique métier, des étapes que l’IA ne peut automatiser entièrement.

Enfin, l’article met en garde contre la tentation de confier la modélisation du domaine à l’IA, soulignant que cette tâche reste un effort collectif et itératif. L’optimisation des outils d’IA pour générer du code doit s’accompagner d’une focalisation accrue sur la compréhension du domaine, sous peine de reproduire les erreurs passées où la technologie était privilégiée au détriment du problème à résoudre.

Ce tutoriel explique comment configurer Codex, l'agent IA d'OpenAI, pour l'utiliser avec un modèle de langage local (LLM) hébergé via llama.cpp. L'idée principale est d'éviter les abonnements payants des plateformes cloud en auto-hébergeant le LLM, tout en conservant les fonctionnalités de Codex. L'auteur insiste sur l'importance d'installer Codex sur une machine dédiée pour limiter les risques liés à son accès au système.

L'installation de Codex se fait via un téléchargement manuel depuis GitHub, suivi de son déplacement dans /usr/local/bin. L'outil bubblewrap est requis pour sécuriser l'exécution de Codex en mode bac à sable. La configuration repose sur un fichier config.toml où l'utilisateur définit le fournisseur de modèle (llamacpp), un nom personnalisé et l'URL locale de l'API de llama.cpp.

L’article souligne que l’IA facilite la génération de code, mais que la véritable difficulté réside dans la production de code de qualité, maintenable et évolutif. L’auteur, développeur expérimenté, rappelle que les problèmes actuels (logique dispersée, tests inefficaces, architectures mal conçues) existaient déjà avant l’IA, simplement amplifiés par son usage massif. Il insiste sur l’importance des bonnes pratiques d’ingénierie logicielle, comme l’abstraction, le découplage et la responsabilité métier, plutôt que sur l’outil utilisé.

L’article de Romain Lanz explore une méthode pour utiliser efficacement l’IA dans le développement logiciel sans déléguer la réflexion stratégique. Il souligne que, contrairement à une idée reçue, déléguer l’écriture du code à l’IA ne signifie pas renoncer à la maîtrise du processus, à condition d’adopter une approche structurée.

L’auteur détaille trois concepts clés : le modèle (le LLM utilisé), le contexte (les informations fournies pour guider la réponse) et le harness (l’environnement technique qui encadre l’IA). Il insiste sur l’importance de limiter le contexte, car un excès d’informations dégrade la qualité des réponses, et sur le rôle du harness, qui agit comme un intermédiaire entre le modèle et les outils concrets (lecture/écriture de fichiers, exécution de commandes).

Enfin, Lanz rappelle que l’IA reste un outil prédictif, incapable d’agir sans ces extensions techniques. Sa méthode vise à optimiser l’interaction avec ces outils pour en tirer le meilleur parti tout en conservant le contrôle sur les décisions techniques.

L’auteur explique avoir réduit le nombre d’agents IA qu’il utilise simultanément après avoir constaté que cette pratique créait une surcharge décisionnelle. Malgré une méthode de travail structurée (spécifications, tests d’acceptation), il a progressivement lancé plusieurs agents en parallèle, se retrouvant submergé par leurs questions et incapable de prioriser efficacement.

Il illustre ce problème avec la théorie des contraintes, soulignant que multiplier les tâches en amont d’un goulot d’étranglement (ici, sa capacité à arbitrer) ne fait qu’accumuler du stock invisible (branches ouvertes, PR en attente) sans améliorer la productivité. La fatigue décisionnelle qui en résulte affecte la qualité du travail, notamment la relecture de code généré par IA.

L’auteur conclut que cette dérive, bien que non imposée, révèle un défaut de gestion des priorités, aggravé par l’illusion de productivité offerte par les agents. Il compare cette situation à l’effet contre-productif d’ajouter des développeurs à un projet déjà en retard.

Cette page propose neuf méthodes pour optimiser l’apprentissage grâce à l’IA, en s’appuyant sur des principes pédagogiques éprouvés comme la récupération active, l’espacement et la pratique exigeante. L’idée centrale est d’utiliser l’IA comme un coach plutôt que comme une simple machine à réponses, en évitant de déléguer entièrement le travail cognitif à l’outil. Par exemple, transformer l’IA en tuteur socratique, qui pose des questions et guide l’utilisateur vers la compréhension plutôt que de fournir des solutions toutes faites, maximise la rétention des connaissances.

L’article insiste sur une règle fondamentale : l’IA doit assister l’effort d’apprentissage sans le remplacer, car c’est l’effort personnel qui renforce la mémoire. Les techniques proposées, comme la création de flashcards automatisées suivies de révisions espacées, illustrent cette approche en combinant gain de temps et efficacité pédagogique. L’accent est mis sur l’interaction active avec le contenu, plutôt que sur la consommation passive d’informations.

Enfin, le texte met en garde contre les limites de l’IA, notamment ses erreurs potentielles, et recommande de croiser ses réponses avec d’autres sources pour éviter les biais. Destiné aux apprenants de tous niveaux, l’article encourage à appliquer ces méthodes immédiatement sur un sujet précis, en adaptant les prompts fournis pour une utilisation concrète.

L’auteur critique l’usage des chatbots, qu’il compare à une forme d’onanisme intellectuel ou de Guitar Hero créatif : amusant mais stérile, car il ne développe aucune compétence réelle. Il souligne que les utilisateurs, même en ayant la réponse sous les yeux, échouent à la restituer, illustrant l’absence d’apprentissage. L’analogie avec un plaisir solitaire et peu partageable renforce son rejet de cette pratique, qu’il juge à la fois inefficace et dénuée de valeur ajoutée.

Ploum admet avoir lui-même cédé à la tentation, en testant un chatbot pour générer des images, mais souligne l’absurdité de l’exercice : l’outil produit des résultats superficiels, comme une musculature exagérée imposée à un personnage, révélant ses biais. Il insiste sur le paradoxe où l’IA, présentée comme un gain de temps, exige en réalité un investissement disproportionné pour un résultat médiocre, à l’image d’un jardinier trop coûteux pour une petite pelouse.

Enfin, il généralise cette critique aux dynamiques managériales ou parentales, où déléguer une tâche simple à un "expert" (humain ou machine) s’avère contre-productif. Son ton mêle ironie et sérieux, dénonçant une mode technologique qui sacrifie l’effort personnel au profit d’une illusion de facilité, sans réel bénéfice durable.

L’article explique comment moderniser un script de sauvegarde obsolète en utilisant Codex via l’extension Remote SSH de VS Code, plutôt que de réécrire aveuglément le code. L’auteur, confronté à des changements d’infrastructure (migration Debian, conteneurs Docker disparus), a préféré auditer le script existant en temps réel sur le serveur, en s’appuyant sur l’IA pour vérifier la validité des chemins, des commandes et des ressources (conteneurs, volumes, espace disque). Cette approche interactive permet de confronter les hypothèses du code à la réalité du serveur, évitant ainsi des erreurs liées à des hypothèses erronées.

L’outil Remote SSH de VS Code joue un rôle clé en transformant le serveur distant en espace de travail direct, où Codex peut analyser les fichiers et exécuter des commandes dans le contexte réel. L’auteur souligne l’importance de ne pas laisser l’IA agir sans contrôle, notamment en matière de privilèges : Codex propose des commandes en lecture seule et demande explicitement l’autorisation avant toute opération sensible, garantissant ainsi une supervision humaine constante.

Le processus a révélé des incohérences majeures dans le script, comme des chemins de sauvegarde inexistants ou des conteneurs Docker disparus, prouvant l’utilité de cette méthode. En combinant audit interactif et vérification immédiate, l’auteur évite une refonte hasardeuse et s’assure que la nouvelle version du script correspond à l’état actuel du serveur.

L’article de Maxence Maireaux analyse le retour du mythe du 10x engineer avec l’essor de l’IA, illustré par une thèse récente selon laquelle l’IA polariserait le métier de développeur. Les ingénieurs les plus compétents, capables de superviser et valider le travail des agents IA, deviendraient indispensables, tandis que les profils moyens seraient marginalisés. Les données, comme celles du rapport DORA 2024 ou des études METR, montrent cependant que l’IA peut aussi réduire la stabilité des livraisons et creuser l’écart entre productivité perçue et réelle, comme en témoignent des cas concrets de code généré sans vérification approfondie.

L’auteur reconnaît la pertinence du diagnostic sur les risques de la confiance aveugle dans l’IA, qui accélère l’accumulation de dette technique et la perte de connaissance des systèmes. Cependant, il critique la conclusion économique qui en découle, comparant ce raisonnement au mythe du 10x engineer, popularisé par une étude contestable des années 1960 et aujourd’hui relancé par l’IA. Ce mythe, qui glorifie les "stars" individuelles, ignore les leçons des recherches en psychologie organisationnelle, comme celles de Google, qui soulignent l’importance de la sécurité psychologique et du travail d’équipe plutôt que du talent isolé.

En conclusion, l’article met en garde contre la résurgence de cette croyance simpliste, rappelant que l’efficacité collective repose davantage sur des dynamiques collaboratives que sur des individus exceptionnels. L’IA, loin de justifier une segmentation extrême du métier, devrait plutôt inciter à repenser les méthodes de travail pour éviter les pièges de la productivité illusoire et de la dépendance technologique.