Cet article explique comment écrire directement dans la mémoire vidéo du mode VGA, une étape essentielle pour continuer à afficher du texte après le passage en mode protégé 32 bits, où l'accès au BIOS n'est plus possible. Il détaille le fonctionnement de la mémoire vidéo en mode texte couleur, où chaque caractère occupe deux octets : un pour son code ASCII et un pour sa couleur, cette dernière étant codée sur plusieurs bits pour définir les couleurs de premier plan et d'arrière-plan.

Le texte présente ensuite des exemples de code assembleur permettant de placer des caractères à des adresses spécifiques de la mémoire vidéo, en spécifiant leur code ASCII et leur combinaison de couleurs. Ces manipulations permettent de tester l'affichage de caractères simples, y compris certains caractères étendus du jeu de caractères Code Page 437, illustrant ainsi la capacité à contrôler finement l'affichage sans recourir aux services du BIOS.

Bien que cette technique permette d'afficher des caractères isolés à des positions définies, l'auteur souligne qu'il s'agit d'une première étape et que d'autres fonctionnalités comme l'affichage de chaînes de caractères, la gestion du curseur ou le défilement de texte restent à développer pour un contrôle d'affichage plus complet.

L'article aborde la problématique du "code sloppé" généré par l'intelligence artificielle, en soulignant que cette notion englobe divers types d'échecs sans cause unique ni solution universelle. Il identifie des schémas récurrents tels que des validations redondantes, la création de fonctions quasi-identiques ou des vérifications excessives pour des entrées impossibles, qui nuisent à la qualité et à la maintenabilité du code.

Une cause majeure de cette accumulation de code de mauvaise qualité réside dans le manque de contexte pour les agents d'IA. Ces derniers, ne disposant pas des informations complètes sur les validations précédentes ou les fonctions existantes, ont tendance à synthétiser des solutions locales et redondantes, exacerbant le "problème de localité" où le code qui devrait évoluer ensemble est difficile à trouver et à modifier.

Pour remédier à ce problème, l'article propose d'identifier précisément les comportements ou problèmes récurrents, de préférer des descriptions de problèmes spécifiques plutôt que des termes vagues comme "code sloppy". L'utilisation d'outils comme des règles de linting ciblées, inspirées par des travaux comme ceux de Dillon Mulroy, peut aider à identifier ces schémas de code problématiques et orienter les efforts de nettoyage, qu'il s'agisse de corrections locales ou de refontes architecturales.

L'article décrit la construction de PABLO, un orchestrateur développé en Symfony, visant à automatiser les tâches répétitives et à réduire les changements de contexte pour les développeurs. PABLO s'appuie sur une machine à états pour gérer le cycle de vie des tâches, allant de la compréhension initiale à la mise en production.

Avant PABLO, l'auteur utilisait un environnement de développement basé sur des agents capables de comprendre les tickets et le code associé. Cependant, la phase post-développement, impliquant les revues, les tests QA et la surveillance de la CI/CD, restait un processus manuel coûteux en changements de contexte et en temps.

PABLO a été créé pour combler ce fossé, en centralisant la gestion de ces différentes étapes. Son objectif est de décharger le développeur des corvées d'attente et de vérification, lui permettant de se concentrer sur l'écriture de code et l'innovation, tout en maintenant une vision claire de l'état d'avancement des projets.

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.

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'auteur décrit une expérimentation où il délègue la génération de code à des agents basés sur l'IA. Initialement, il agissait comme un intermédiaire, copiant-collant des tickets dans des sessions d'agents pour déclencher leur travail. Cette tâche répétitive l'a conduit à réaliser que la partie réellement créative et intéressante du processus de développement se situait en amont, lors de la spécification des tickets.

Cette évolution s'inscrit dans une progression sur plusieurs années, passant de la complétion de code (Copilot) au dialogue avec les modèles (chat), puis à l'agentique où les IA peuvent modifier des fichiers et exécuter des commandes sous supervision. L'étape actuelle consiste à retirer l'humain de la boucle de déclenchement des agents, transformant son rôle.

Le changement majeur est passé de l'écriture directe de code à la spécification détaillée de ce qui doit être codé. L'expérimentation actuelle vise à pousser cette idée plus loin en retirant l'humain de la seule action de lancer les agents, le rôle du développeur se concentrant désormais sur la définition précise des tâches à accomplir par l'IA.

Graft est un outil open-source conçu pour améliorer les performances des agents de codage tels que Claude Code, Cursor, Codex et Gemini. Il vise à les rendre plus rapides, moins coûteux et à améliorer leur compréhension contextuelle de votre base de code, permettant ainsi des économies significatives en temps et en coût, tout en améliorant parfois la précision des résultats.

L'outil fonctionne en créant un graphe de votre base de code. Ce graphe permet aux agents d'accéder à des informations contextuelles pertinentes, réduisant ainsi le besoin de traiter l'intégralité du code à chaque requête. Graft s'intègre en douceur, notamment avec Claude Code, en ajoutant automatiquement des hooks et en gérant la génération du graphe en arrière-plan, rendant ainsi l'amélioration transparente pour l'utilisateur.

Une fonctionnalité notable de Graft est son application GitHub qui analyse automatiquement les pull requests, offrant des revues de code plus efficaces. Il supporte également une variété de langages de programmation et offre des outils en ligne de commande pour la recherche, la cartographie et la visualisation du graphe de code.

MicroLighter est une bibliothèque de coloration syntaxique légère et sans dépendances, conçue pour être rapide et facile à intégrer. Elle ne génère pas de <span> superflus dans le code, ce qui contribue à sa performance. Les grammaires, au format TextMate utilisé par VS Code, peuvent être chargées de manière asynchrone pour optimiser le temps de chargement.

L'installation de MicroLighter se fait simplement via npm. Il suffit d'importer la fonction highlightAll et un thème CSS, puis d'ajouter la classe language-* aux blocs de code. Une option existe pour un chargement automatique immédiat, ainsi qu'un bundle pour utiliser des éléments personnalisés offrant des fonctionnalités comme la copie ou la numérotation des lignes.

MicroLighter prend en charge plusieurs langages de programmation, tels que JavaScript, CSS, HTML, Ruby, Python, SQL et C++. La librairie est pensée pour une utilisation efficace et moderne du code dans les projets web.

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’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.

L’article explique pourquoi les IA comme Claude génèrent du code standard, souvent éloigné des conventions spécifiques d’une équipe, et propose une solution via les rules. Sans instructions précises, l’IA se base sur des pratiques moyennes en ligne, ce qui peut entraîner des incohérences dans une base de code. Les rules permettent d’intégrer les bonnes pratiques internes sous forme d’instructions claires, comme des conventions de nommage ou des principes architecturaux, afin d’harmoniser le code produit.

Les rules sont des directives écrites au format DO/DON’T, intégrées à la session de l’IA pour guider ses choix. Elles couvrent des aspects variés, des unités de mesure aux bonnes pratiques comme le debounce pour optimiser les performances. Ces règles, une fois formalisées, réduisent les corrections répétitives en revues de code et facilitent la transmission des savoir-faire techniques au sein de l’équipe.

Ce dépôt GitHub propose une collection d'outils et de compétences conçus pour les ingénieurs logiciels, axés sur le développement d'applications réelles plutôt que sur des approches superficielle comme le "vibe coding". L'idée centrale est de fournir des compétences modulaires, adaptables et faciles à intégrer, basées sur des décennies d'expérience en ingénierie, afin d'améliorer la productivité sans sacrifier le contrôle du processus.

Deux méthodes d'installation sont proposées : via un script skills.sh qui copie les compétences dans un projet pour une personnalisation complète, ou sous forme de plugin pour Claude Code, offrant une solution clé en main et automatiquement mise à jour. Le projet met l'accent sur la simplicité et la flexibilité, permettant aux utilisateurs de choisir entre une intégration personnalisable ou une solution préconfigurée et maintenue.

L’article Why write code in 2026 défend l’idée que, malgré l’essor des agents IA et des outils automatisés, écrire du code reste essentiel pour les développeurs. L’auteur souligne que coder permet une compréhension directe de l’architecture logicielle, bien au-delà d’une simple lecture passive ou d’une supervision d’agents. Cette pratique favorise une meilleure attention aux détails, une réduction des erreurs et une amélioration de la qualité du code, évitant ainsi l’accumulation de "slop" (code bâclé) qui nuit aussi bien aux humains qu’aux agents.

L’auteur reconnaît que la plupart de son code est généré par IA, mais insiste sur le fait que l’écriture manuelle offre une expérience immersive et une maîtrise impossible à obtenir autrement. Il compare les agents IA à des stagiaires fraîchement embauchés, capables de suivre des instructions mais souvent limités par des descriptions imprécises ou des environnements mal structurés. Écrire du code permet de penser de manière algorithmique et de calibrer la précision nécessaire, contrairement à l’anglais, trop vague pour exprimer des computations complexes.

Enfin, l’article critique l’idée que les agents IA devraient être traités comme des compilateurs, ce qui justifierait la production de code médiocre. Au contraire, les développeurs doivent rester actifs dans le processus pour garantir la robustesse et la cohérence du logiciel. L’auteur cite l’exemple d’un choix d’architecture (local storage) qui, bien que fonctionnel, illustre comment une décision prise par un humain peut avoir des conséquences durables, soulignant l’importance d’une réflexion approfondie dans le développement.

L’article défend l’idée que dans les grands systèmes logiciels, une compréhension partielle de la base de code est non seulement inévitable, mais aussi suffisante pour travailler efficacement. L’auteur conteste la vision de Peter Naur, qui prône une maîtrise totale du code via une "théorie du programme", arguant que cette approche est irréaliste pour les systèmes complexes et à forte rotation d’équipes. Il souligne que les grands systèmes accumulent des cas particuliers impossibles à recréer de zéro, et que leur maintenance repose souvent sur une reconstruction progressive plutôt que sur une refonte complète.

L’auteur illustre son propos en expliquant que les équipes doivent souvent reprendre des bases de code abandonnées, en partant d’une compréhension locale avant d’étendre leur maîtrise. Il insiste sur le fait que la culture du "tout comprendre" est davantage valorisée dans les discussions en ligne, alors qu’elle est inadaptée aux environnements industriels à grande échelle. Selon lui, l’efficacité repose davantage sur la capacité à naviguer et modifier localement le code que sur une vision globale inaccessible.

L’auteur explique comment l’usage d’agents IA pour écrire et reviewer son code a transformé son rôle de développeur. Désormais, des agents spécialisés analysent ses pull requests sous plusieurs angles (frontend, sécurité, bases de données), réduisant son travail à un rôle d’arbitre. Il souligne que la détection de bugs n’a pas disparu, mais s’est déplacée vers une revue automatisée et adversariale, où plusieurs agents tentent de repérer des failles que lui-même aurait pu manquer.

Il insiste sur le fait que la fiabilité des agents reste limitée : un agent auteur peut produire du code plausible mais incorrect, et des tests écrits par IA ne garantissent pas une qualité suffisante. Pour compenser, il utilise une "essaim" d’agents reviewers, chacun ciblant des vulnérabilités spécifiques, tout en conservant un contrôle humain final sur les vérifications déterministes et les décisions critiques.

Enfin, il note que cette approche lui permet de s’appuyer sur des compétences qu’il ne maîtrise pas (comme la sécurité ou les requêtes SQL complexes), sans pour autant abandonner toute responsabilité. Le processus reste exigeant, mais redistribue les tâches vers une collaboration homme-machine plus efficace.

Goose est un agent IA open source et extensible conçu pour aller au-delà des simples suggestions de code. Il permet d'installer, d'exécuter, d'éditer et de tester avec n'importe quel grand modèle de langage (LLM), offrant ainsi une interaction plus complète et automatisée.

Le projet se distingue par sa capacité à interagir dynamiquement avec des environnements de développement, en intégrant des outils pour manipuler des fichiers, exécuter des commandes et même interagir avec des plateformes comme Databricks. Il prend en charge Docker et propose des instructions détaillées pour la compilation et l'exécution sur différentes plateformes.

Goose est activement maintenu avec une communauté importante, comptant plus de 48 000 étoiles et 5 200 forks sur GitHub. Le projet inclut également des évaluations de performance, des exemples d'utilisation et une documentation complète pour faciliter la contribution et l'adoption.

L’article aborde la notion de « bon code » dans un contexte où l’IA facilite la génération de code, tout en soulignant que sa qualité reste un enjeu majeur. L’auteur s’appuie sur les travaux de Simon Willison pour définir un code efficace : il doit fonctionner correctement, être validé par des tests et des vérifications, et résoudre un problème réel plutôt qu’un besoin technique mal ciblé. La robustesse face aux erreurs, la simplicité, la documentation à jour et l’évolutivité sont également mises en avant.

L’auteur insiste sur l’importance de gérer les cas d’échec avec des messages exploitables et d’éviter la complexité inutile, tout en respectant des critères non fonctionnels comme la sécurité ou la maintenabilité. Ces principes, valables avant l’ère de l’IA, deviennent encore plus cruciaux avec l’automatisation, car ils garantissent la fiabilité et la pérennité des solutions produites.

Ce dépôt GitHub propose Caveman, un plugin pour Claude Code (et autres outils d'IA) qui réduit drastiquement la taille des réponses en adoptant un langage minimaliste, inspiré du "parler caveman". L'idée centrale est de conserver la précision technique tout en diminuant jusqu'à 75 % des tokens utilisés, ce qui optimise les coûts et la rapidité des interactions.

Le projet inclut des exemples concrets comparant les réponses standard et celles compressées, comme une explication sur les re-rendus de composants React passant de 69 à 19 tokens. Il propose également des benchmarks, des guides d'installation et une documentation détaillée pour une intégration facile avec plus de 30 outils compatibles.

Développé sous licence MIT, Caveman s'appuie sur des scripts d'installation automatisés et une structure modulaire pour faciliter son déploiement et ses contributions. Le dépôt met en avant des améliorations continues, comme la consolidation des fichiers de configuration et des correctifs pour les scripts d'installation.

L’article interroge la qualité croissante des logiciels et l’impact de l’IA sur leur fiabilité, dans un contexte marqué par des failles de sécurité fréquentes et des fuites de données. L’auteur souligne que les vulnérabilités (CVE) ont fortement augmenté depuis 2017, attribuant cette hausse à des facteurs comme la pression des mises à jour quotidiennes, l’expansion du numérique et l’intensification des cyberattaques, plutôt qu’à l’IA. Il relativise cependant ce lien, notant que les CVE reflètent aussi une meilleure détection des bugs et une industrie cyber en croissance.

L’auteur évoque des exemples concrets, comme des failles majeures chez GitHub ou des attaques contre des institutions françaises, pour illustrer la dégradation perçue de la qualité logicielle. Il critique l’idée selon laquelle l’IA serait la principale responsable, soulignant que la baisse de fiabilité précède son adoption massive et s’explique davantage par des enjeux économiques et géopolitiques.

Enfin, l’article aborde la perception selon laquelle l’IA accélérerait la production de "code de merde", une idée que l’auteur juge exagérée. Il conclut que la qualité des logiciels dépend davantage des pratiques de développement et des pressions du marché que de l’IA, tout en reconnaissant que cette dernière pourrait aggraver certains problèmes si mal utilisée.

CodeGraph est un outil open source conçu pour optimiser l'analyse de code par des agents IA comme Claude Code ou Cursor. Il génère un graphe de connaissances pré-indexé (symboles, relations, appels de fonctions) permettant aux agents d'interroger instantanément la structure du code plutôt que de scanner les fichiers, réduisant ainsi les coûts et les appels d'outils.

L'installation est simplifiée avec des scripts dédiés pour macOS/Linux et Windows, ou via npm. CodeGraph s'intègre automatiquement aux agents configurés et fonctionne localement sans dépendances externes, tout en restant compatible avec des projets existants.

Les benchmarks sur sept bases de code réelles montrent une économie moyenne de 35 % des coûts, 59 % de tokens en moins et un gain de vitesse de 49 %, grâce à l'indexation sémantique qui évite les recherches coûteuses.