Chez Elao, l’article souligne le manque de collaboration entre designers et développeurs, souvent dû à des formations cloisonnées et à des outils incompatibles. Les designers, formés pour l’expérience utilisateur, négligent parfois la dimension technique des maquettes, tandis que les développeurs peinent à interpréter les livrables visuels. Pour y remédier, l’entreprise a intégré Storybook comme référence partagée, facilitant la communication et réduisant les itérations de correction. Cette approche vise à aligner les processus et à accélérer le développement des projets.

L’auteur, développeur de Writizzy, explore les dilemmes liés à l’ouverture du code de son produit, malgré son attachement à l’open source et ses avantages (contribution à l’écosystème, transparence, visibilité accrue). Il souligne que l’open source peut servir de levier marketing et favoriser une distribution plus large, comme en témoignent des plateformes comme Ghost, WordPress ou GitLab, où des acteurs économiques profitent de l’écosystème sans toujours contribuer en retour.

Cependant, il craint que Writizzy, s’il devient open source, ne subisse une exploitation commerciale disproportionnée par des tiers, captant une partie des revenus générés sans participer à la maintenance ou à l’amélioration du projet. Cette crainte s’appuie sur des exemples comme Substack ou Beehiiv, dont les modèles économiques reposent sur des logiciels non open source, tandis que Ghost, open source, génère une économie parallèle estimée entre 15 et 25 millions de dollars, dont une partie échappe à l’éditeur.

Face à ce dilemme entre éthique et viabilité économique, l’auteur envisage deux options : adopter une licence restrictive limitant l’usage commercial ou accepter cette dynamique sans garantie de retour sur investissement. Il souligne que Ghost, en tant qu’organisation sans actionnaires, peut se permettre cette approche, mais que pour un projet personnel, la question reste ouverte.

L’article aborde le malaise ressenti par les développeurs face à l’intégration des LLMs dans leur travail quotidien, entre utilité et désorientation. L’auteure, Laura Summers, y décrit une expérience à la fois prometteuse et épuisante, où l’automatisation partielle du code ne soulage pas la charge mentale mais la complexifie, notamment lors de la relecture et de l’orientation des contributions générées par IA.

Elle évoque aussi le paradoxe entre l’idéal de création pure, hérité des débuts de la programmation, et la réalité actuelle où les outils low-code ou IA, bien que plus performants, laissent persister un sentiment d’artificialité et de désorientation. L’exemple des PRs générées automatiquement, nécessitant une supervision humaine constante, illustre cette tension entre gain de temps et perte de sens.

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.

Cette page explique le processus de correction des vulnérabilités de sécurité dans Symfony UX, depuis la détection jusqu’à la publication. L’auteur, membre de l’équipe Symfony UX Core Team, détaille les étapes clés : développement des correctifs dans un dépôt privé pour éviter les exploits anticipés, triage des rapports pour distinguer les vulnérabilités critiques (CVE) des améliorations de sécurité mineures, et création de correctifs ciblant d’abord les branches maintenues en mode security-fixes-only.

Deux exemples concrets illustrent ce processus : CVE-2026-55877, une faille XSS dans symfony/ux-icons due à l’injection de SVG non échappés, corrigée via une usine centralisée de nettoyage des éléments dangereux ; et CVE-2026-55878, une traversée de chemin dans symfony/ux-toolkit permettant l’accès à des fichiers arbitraires, résolue par un rejet explicite des chemins contenant ...

L’auteur souligne l’utilisation d’outils automatisés (comme un assistant IA pour analyser les rapports ou générer des advisories GitHub) pour accélérer les tâches répétitives, tout en insistant sur la nécessité d’un examen humain pour valider les correctifs et les scores CVSS avant publication.

Ce billet humoristique et critique illustre les dangers du vibe coding (développement impulsif basé sur l’IA) à travers une expérience fictive où un développeur, pressé par le temps, utilise un assistant IA pour implémenter rapidement une fonctionnalité. L’auteur met en scène deux jauges symbolisant la vitesse de développement et la dette technique, montrant comment la précipitation mène à des erreurs critiques, comme l’exposition d’une clé d’API en dur dans un commit public.

Le récit, structuré comme un jeu de rôle, explore les conséquences d’un manque de rigueur : l’assistant IA génère du code erroné ou dangereux, tandis que le développeur, obnubilé par la productivité immédiate, ignore les signaux d’alerte. Les choix du protagoniste – accepter aveuglément les suggestions, négliger les tests ou reporter les corrections – aggravent la situation, culminant avec la compromission d’un compte et une dette technique ingérable.

À travers ce scénario, l’auteur souligne les risques d’une approche trop laxiste du développement assisté par IA, où la vitesse prime sur la qualité et la sécurité. Le ton sarcastique et les références aux jeux vidéo renforcent l’idée que le vibe coding peut rapidement virer au cauchemar, transformant une "petite feature" en un désastre professionnel.

L’auteur explique pourquoi l’utilisation des modèles de langage (LLMs) pour coder, ou "vibe coding", ne lui convient pas personnellement. Il évoque son manque d’enthousiasme face à cette tendance, sans pour autant nier les avantages potentiels des outils d’IA pour certains développeurs.

Il souligne deux raisons personnelles : son aversion pour les coûts récurrents des services d’IA, qu’il juge absurdes, et son expérience en tant que développeur expérimenté, qui lui permet de relativiser les promesses de productivité instantanée. Il compare cette hype à d’anciennes innovations en outils low-code ou no-code.

Enfin, il s’appuie sur les travaux de Fred Brooks, notamment The Mythical Man-Month et No Silver Bullet, pour rappeler que la complexité du monde réel ne peut être entièrement simplifiée par des outils, même avancés. Pour lui, le codage reste une question de compréhension des abstractions et de gestion de la complexité, plutôt que de productivité pure.

L’article critique l’idée selon laquelle l’ère de l’IA rendrait la technique obsolète au profit d’une approche strictement "product-first". L’auteur souligne que, malgré les gains de productivité permis par l’IA, la qualité technique reste essentielle pour éviter des problèmes comme des performances médiocres, une architecture chaotique ou des solutions ingérables. Il met en garde contre l’usage abusif de l’argument "product-first" comme prétexte pour négliger la rigueur technique, même si des compromis sont parfois nécessaires pour livrer rapidement.

L’auteur, qui utilise massivement l’IA pour coder, rappelle que savoir quoi construire ne suffit pas : le comment compte toujours, surtout pour des projets complexes. Il cite Rich Hickey pour rappeler que la simplicité et la clarté technique restent des piliers, même avec des outils avancés. L’IA accélère le développement, mais ne dispense pas d’une réflexion sur l’architecture et la maintenabilité.

L’article oppose deux approches du développement logiciel : le vibe coder, qui privilégie la rapidité de prototypage via des outils comme l’IA, et l’ingénieur logiciel, axé sur la qualité, la maintenabilité et la sécurité du code dans un environnement réel. L’auteur souligne que l’IA excelle pour générer des prototypes, mais que son utilisation dans un codebase partagé nécessite une évaluation rigoureuse, notamment en termes de revues, de tests et de maintenance.

L’idée centrale réside dans la mesure de la productivité : un vibe coder se concentre sur le temps nécessaire pour obtenir une première version fonctionnelle, tandis qu’un ingénieur évalue le temps jusqu’à une fusion sûre, incluant les coûts de revue, de déploiement et de maintenance. L’auteur met en garde contre l’illusion de gains de productivité si l’IA génère du code non maîtrisé, transférant la charge en aval.

Enfin, l’article insiste sur la nécessité de contraindre la production de code par l’IA pour éviter une accumulation de dette technique. Le code généré doit être minimaliste, justifié et aligné sur les standards existants, sous peine de complexifier inutilement le travail des équipes en aval.

Mistral Vibe est un assistant de codage en ligne de commande open source développé par Mistral AI, conçu pour interagir avec les projets via une interface conversationnelle en langage naturel. Il permet d'explorer, modifier et gérer un codebase grâce à des outils intégrés comme la manipulation de fichiers, l'exécution de commandes shell ou la recherche de code, tout en s'appuyant sur le contexte du projet (structure des fichiers, statut Git, etc.). L'outil cible principalement les environnements UNIX, bien qu'il soit compatible avec Windows.

L'installation se fait via une commande simple (curl ou uv tool install), et l'assistant propose plusieurs modes d'utilisation : interactif, programmatique ou vocal. Il inclut aussi un système de skills (compétences personnalisables) et des slash commands pour étendre ses fonctionnalités, avec une gestion avancée des sessions et des configurations.

Disponible sous licence Apache 2.0, Mistral Vibe se distingue par son approche modulaire, son intégration avec des modèles comme Mistral Medium 3.5 (pour le multimodal) et ses thèmes personnalisables, tout en garantissant une expérience CLI fluide avec historique et autocomplétion.

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’idée principale de l’article est de proposer une méthode de travail avec deux agents IA pour améliorer la programmation assistée par IA. L’un écrit le code dans un espace de travail dédié, tandis que l’autre, en parallèle, le révise systématiquement après chaque cycle de développement (TDD). Ce second agent, qualifié de « porteur de la lampe », maintient la vision globale du projet et évite que le premier agent ne s’éloigne des objectifs initiaux en se perdant dans les détails techniques.

L’auteur souligne que cette approche simple mais efficace permet de corriger deux problèmes majeurs : d’une part, l’agent codeur peut dériver de la mission initiale en accumulant des décisions localement optimales, et d’autre part, le réviseur identifie les erreurs structurelles ou les choix qui compliquent les étapes suivantes. Contrairement aux sous-agents de révision intégrés, ce réviseur dédié conserve une vision cohérente de l’objectif final tout au long du projet.

Enfin, l’article précise que cette méthode s’ajoute aux outils existants (comme les sous-agents de révision ponctuels) sans les remplacer, car ils remplissent des rôles complémentaires : les sous-agents gèrent les problèmes immédiats, tandis que le réviseur dédié préserve la cohérence globale. Cette coordination entre agents représente une évolution naturelle pour les utilisateurs maîtrisant déjà un agent unique.

L’auteur, développeur depuis 1983, partage son expérience de l’intégration de l’IA dans son workflow, notamment via le Markdown pour rédiger spécifications et architectures. Il critique à la fois le vibe coding (délégation aveugle à l’IA) et le rejet puriste de cette technologie, soulignant que la valeur réside désormais dans la conception et la supervision, pas dans la production de code brute.

Il utilise l’IA comme un outil collaboratif : pour des tâches simples, elle agit comme une exécutante rapide, tandis que pour les parties complexes, il supervise et valide, voire code lui-même. L’objectif est de maintenir une architecture compréhensible et maîtrisée, évitant ainsi les risques liés à des systèmes opaques ou dépendants de tarifs ou de disponibilités externes.

Enfin, il compare l’IA à un retour partiel du cycle en V, où la spécification redevient centrale. La confiance dans le code généré doit être proportionnelle à la capacité de le critiquer, et les rôles (spécification, validation, expertise) doivent rester clairs pour préserver la robustesse du système.

Chris Shiflett décrit la création d’un serveur MCP (Model Context Protocol) pour son laboratoire personnel, un espace où il centralise ses projets et outils maison. Il explique comment il a rationalisé son répertoire ~/local, autrefois encombré de projets inaboutis, en relançant des outils comme Landice, Faculty ou Schoolcase, tout en adoptant progressivement l’IA malgré ses réticences initiales. Son approche progressive avec l’IA, passant de simple référence à collaborateur, l’a conduit à voir cette technologie comme un "robot" capable d’exécuter du code, bien que des limites persistent, comme l’interface de Claude ou la perte de contexte entre conversations.

Shiflett souligne deux obstacles majeurs dans son utilisation de l’IA : d’abord, l’asymétrie entre l’exécution manuelle du code et l’approche automatisée de Claude Code, qui réduit sa participation active. Ensuite, le manque de mémoire des assistants, obligeant à résumer manuellement l’historique des échanges dans des fichiers Markdown avant de recommencer une conversation. Ces contraintes l’ont poussé à concevoir un serveur MCP pour mieux contrôler l’interaction avec l’IA et intégrer ses outils existants.

L’objectif final est de fluidifier ce processus en créant une interface unifiée, où l’IA agit comme un véritable partenaire de développement plutôt qu’un simple exécutant. Ce projet reflète sa volonté de concilier innovation technologique et méthodes de travail personnelles, tout en résolvant les frictions rencontrées dans l’adoption de l’IA.

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.

Ce billet explique comment l'auteur utilise FrankenPHP en développement, mettant en avant son mode worker qui maintient une instance PHP active pour éviter les recharges coûteuses à chaque requête. Trois mécanismes de hot reload sont combinés : --watch pour les fichiers statiques, tailwind:build --watch pour les styles, et le worker lui-même, permettant un rechargement instantané du navigateur sans configuration complexe. L'article souligne aussi l'intégration d'un certificat HTTPS auto-signé, accessible via https://localhost:8443 sans modification du fichier hosts.

L'auteur détaille l'architecture de FrankenPHP, un binaire Go combinant le serveur Caddy et PHP-FPM, simplifiant l'infrastructure en un seul processus au lieu de Nginx + PHP-FPM. Le mode worker évite le redémarrage complet de l'application à chaque requête, améliorant les performances en développement comme en production. Le même fichier de configuration est utilisé pour les deux environnements, avec des variables d'environnement ajustant les comportements selon le contexte Docker.

L’auteur partage sa méthode pour développer des produits avec l’IA tout en maîtrisant les coûts, en limitant la consommation de tokens à environ 20 € par mois. Il utilise principalement Claude pour coder, notamment pour ses projets Writizzy (une plateforme de newsletters) et Hakanai (blogs statiques), en appliquant une approche de context engineering pour guider l’IA et éviter les erreurs.

Pour structurer son travail, il s’appuie sur des fichiers Claude.md définissant les spécifications du projet et des règles conditionnelles (.claude/rules) qui imposent des bonnes pratiques (comme l’utilisation de Nuxt UI ou des vérifications de typage). Ces règles, affinées empiriquement, réduisent les explorations inutiles de l’IA et optimisent l’efficacité.

Enfin, l’auteur souligne que ces mesures ne sont pas infaillibles : il complète avec des contrôles automatisés (tests, linters, CI) pour limiter les risques d’erreurs. Il évoque aussi une possible transition vers un autre modèle, plus performant pour le code, tout en maintenant une approche budgétaire stricte.

Ce billet explique comment exécuter localement des grands modèles de langage (LLM) gratuitement avec Ollama, un outil simplifiant leur déploiement. L’auteur détaille l’installation via Docker, le téléchargement d’un modèle et son intégration dans une application Symfony grâce au Symfony AI Bundle, tout en évitant les pièges courants. L’objectif est de montrer qu’il est possible d’utiliser des LLM sans dépendre de fournisseurs externes payants, tout en maîtrisant les coûts et la confidentialité des données.

Ollama agit comme un runtime local, optimisant les modèles pour le matériel et exposant une API HTTP locale. Ses avantages principaux sont l’absence de coûts marginaux (seule l’électricité est consommée), la confidentialité des données (pas de transmission externe) et la portabilité (le même setup fonctionne en développement comme en production). Cependant, la qualité des réponses reste inférieure à celle des modèles cloud comme GPT-4, surtout pour des tâches complexes nécessitant une prose élaborée.

Le guide s’adresse aux développeurs PHP/Symfony et se concentre sur des cas d’usage concrets comme la génération de métadonnées SEO ou l’extraction de données structurées. Il mentionne aussi les prérequis matériels, soulignant que des modèles de plusieurs milliards de paramètres exigent une infrastructure adaptée, sans entrer dans des comparatifs techniques.

L’auteur, développeur depuis plus d’une décennie, défend l’idée que se former à un nouveau langage de programmation reste essentiel à l’ère de l’IA, malgré ses capacités croissantes à générer du code. Il souligne que l’utilisation excessive de l’IA risque d’éroder les compétences fondamentales en programmation, comme la modélisation des problèmes ou l’évaluation critique du code produit. Apprendre un nouveau langage permet de préserver ces bases tout en découvrant d’autres philosophies et pratiques, enrichissant ainsi sa vision du développement.

Pour cette année, il a choisi C#, un langage en constante évolution mais souvent associé à tort à l’écosystème Microsoft. Son objectif est de dépasser les préjugés et d’explorer la culture "craft" de sa communauté, qu’il juge dynamique et inspirante. Cette démarche reflète sa volonté de maintenir un esprit critique face aux outils automatisés, en s’appuyant sur une maîtrise solide des concepts fondamentaux.

L’article met en lumière l’importance de l’apprentissage continu pour rester pertinent dans un domaine en mutation rapide, où l’IA devient un allié plutôt qu’un substitut à l’expertise humaine.