Addy Osmani partage son workflow de codage avec les modèles de langage (LLM) pour 2026, soulignant l'importance de la planification et de la gestion des tâches. Il recommande de commencer par une spécification détaillée et un plan de projet clair, en collaborant avec l'IA pour définir les exigences et les étapes de mise en œuvre. Ensuite, il suggère de diviser le travail en petites tâches itératives, traitant chaque fonctionnalité ou correction une par une. Cette approche permet de maximiser l'efficacité de l'IA et de maintenir un contrôle humain sur le processus de développement.
Marine Dunstetter, ingénieure logicielle senior, explore les parallèles entre son métier et sa passion pour le jardinage. Elle souligne que ces deux activités, bien que différentes en apparence, partagent des similitudes fondamentales : un travail sans fin, un écosystème complexe à gérer et un apprentissage continu. Le jardinage, comme le développement web, demande une attention constante et une adaptation permanente aux changements. Les erreurs, inévitables dans les deux domaines, sont des opportunités d'apprentissage. L'auteur invite à voir ces défis comme des occasions de croissance et de compréhension plus profonde de nos environnements, qu'ils soient numériques ou naturels.
AGENTS.md est un format ouvert et simple pour guider les agents de codage, utilisé par plus de 60 000 projets open source. Il sert de complément au README.md en fournissant des instructions spécifiques pour les agents, comme les étapes de construction, les tests et les conventions, tout en gardant le README concis et axé sur les contributeurs humains. Le fichier AGENTS.md est compatible avec divers agents de codage et outils, et peut être adopté librement par quiconque trouve cela utile.
L'article explore une approche proactive pour intégrer la performance web dès le début du développement, évitant ainsi le cycle de dégradation des performances. Odell, ingénieur chez Canva, propose d'impliquer toute l'équipe et de rendre la performance visible tôt, plutôt que de la traiter comme un problème à résoudre a posteriori. Il explique comment les problèmes de performance s'accumulent silencieusement et pourquoi les corrections tardives sont souvent inefficaces. La solution proposée est de créer des systèmes et des processus qui favorisent naturellement les décisions rapides et performantes.
mise-en-place est un outil polyvalent pour la gestion des environnements de développement. Il permet de gérer les versions des outils (remplaçant asdf, nvm, etc.), de basculer entre différents ensembles de variables d'environnement (remplaçant direnv) et d'exécuter des tâches (remplaçant make ou les scripts npm). Licencié sous MIT, il est maintenu par @jdx et d'autres contributeurs.
L'article explore la méthode Spec-Driven Development (SDD), qui consiste à générer des spécifications détaillées en Markdown avant de coder, guidant ainsi les agents de codage. Bien que prometteuse pour structurer le développement avec l'IA, cette approche, inspirée du modèle Waterfall, présente des inconvénients majeurs : production excessive de texte, bureaucratie systématique, et sentiment de fausse sécurité. L'auteur suggère qu'une approche plus itérative et naturelle pourrait mieux convenir au développement moderne. Plusieurs outils comme Spec-Kit, Kiro, et Tessl sont mentionnés, mais leurs limites sont également discutées.
Cet article propose des habitudes de productivité concrètes pour les ingénieurs. Il aborde trois stratégies principales : rester débloqué en parallélisant les implémentations (backend vs frontend par exemple) pour minimiser les temps d'inactivité, réduire le temps de débogage en comprenant la structure du code et en investissant dans la journalisation, et investir dans l'outillage, notamment dans le domaine de l'IA, pour automatiser les tâches répétitives. Ces habitudes visent à améliorer l'efficacité et à surmonter les défis courants dans le développement logiciel.
Ross Wintle explore l’idée que le logiciel peut être « terminé », en proposant une définition simple : un logiciel est fini lorsqu’il est fonctionnellement complet et que rien ne doit y être ajouté, même si des évolutions restent possibles. Il souligne que des changements externes (matériel, plateformes, API, outils de build) peuvent rendre un logiciel obsolète, mais que cela ne dépend pas toujours des développeurs. Plutôt que de viser absolument la « finition », il invite à réfléchir aux leçons que cette approche peut apporter, comme la valeur de la stabilité et de la maintenance contrôlée. Il illustre son propos avec l’exemple du Gameboy, dont le logiciel embarqué fonctionne toujours des décennies plus tard, et rappelle que beaucoup d’entreprises reposent sur des mises à jour continues plutôt que sur des produits figés. Une réflexion stimulante sur la durabilité et les limites du contrôle en développement logiciel.
Dans cet article un peu décousu, l'auteur expose ses réflexions sur l'IA dans le développement. Ayant connu l'explosion de la bulle des années 2000, il essaye de relativiser un peu ce que nous vivons ces derniers temps : beaucoup d'emballement. Il poursuit en rappelant que certains devs sont avant tout des passionnés, même si le monde du travail tend à rendre le dev moins excitant en cherchant à tout prix la rentabilité. En particulier, l'automatisation permise par l'IA peut faire gagner du temps, mais gomme l'apprentissage de la résolution de problème par soi-même. Il rappelle aussi qu'il y a 10 ans, la grande mode était de délocaliser le développement à l'étranger... et qu'on en est bien revenus ! Il finit par conclure que l'IA est un outil intéressant pour les profils comme le sien : senior et qui sait ce qu'il fait... mais qu'il demande à voir ce que ça donnera avec des juniors qui n'auront que ça.
Devstral est un modèle LLM agentique open source développé par Mistral AI, spécialement optimisé pour les tâches de développement logiciel. Il se distingue par sa capacité à résoudre des problèmes complexes de programmation, comme la navigation dans de grandes bases de code, la modification de plusieurs fichiers et la correction de bugs, en agissant de manière autonome. Avec seulement 24 milliards de paramètres, il surpasse certains modèles fermés et open source plus volumineux sur le benchmark SWE-Bench Verified, tout en restant léger et utilisable en local sur des machines avec 32 Go de RAM ou une RTX 4090. Sous licence Apache 2.0, il s’intègre facilement à des frameworks comme OpenHands ou SWE-Agent.
L’article détaille son installation (via Ollama, plugins IDE ou OpenHands) et ses cas d’usage : génération de documentation, refactoring de code, création de projets structurés (ex. Spring Boot en DDD), ou amélioration de projets existants. Bien que performant, son efficacité dépend de la qualité des prompts et de l’environnement fourni. Devstral représente une solution prometteuse pour les développeurs souhaitant un assistant local, sécurisé et puissant, malgré quelques limites comme la génération occasionnelle de code inutile ou trop complexe. Une version "Large" est annoncée pour l’avenir.
L’auteur, développeur expérimenté, partage son retour sur l’utilisation de la GenAI (Claude Code) au quotidien. Il distingue trois usages principaux : le "vibe coding" (génération complète de scripts ou interfaces simples, gain de temps énorme), le "mode chirurgien" (résolution ciblée de bugs complexes ou manipulation de SDK obscurs), et l’assistance pour du code de production (génération de couches techniques répétitives, reviews, agents automatisés). Selon lui, la GenAI ne remplace pas les développeurs — elle libère du temps pour se concentrer sur la réflexion architecturale, l’intégration système et les bonnes pratiques, domaines où l’expertise humaine reste indispensable. Un outil à adopter pour booster sa productivité, mais sans illusions sur la disparition du métier.
L'auteur compare le développement logiciel à la création d’un mandala : un travail minutieux, parfois éphémère, où l’essentiel réside dans le processus plutôt que dans le résultat final. Comme les moines bouddhistes qui effacent leurs mandalas de sable après des jours de travail, les développeurs voient parfois leurs fonctionnalités abandonnées ou modifiées, non par manque de qualité, mais parce que les besoins évoluent. L’article souligne que la valeur du code ne se limite pas à ce qui est déployé, mais aussi à l’apprentissage, aux échanges en équipe et à la compréhension des besoins. Développer, c’est accepter l’impermanence tout en s’investissant pleinement, car c’est dans la démarche collaborative et la qualité du processus que réside la véritable richesse du métier. Une belle métaphore pour rappeler que coder, c’est aussi savoir lâcher prise.
Wojtek Jurkowlaniec explique comment il maintient un projet de 10 000+ lignes de code en combinant design manuel, documentation vivante (fichiers DESIGN et ARCHITECTURE), et itérations courtes et indépendantes. Le processus repose sur une séparation claire des rôles : l’humain définit la vision et l’architecture, tandis que le LLM génère du code, propose des refactors et accélère l’implémentation, toujours guidé par des documents à jour. Chaque feature est développée par étapes, testée et committée, avec une trace écrite des corrections dans un CODING-GUIDELINES.md pour éviter la dette technique. La clé ? Traiter le LLM comme un outil de transformation de texte, pas comme un co-développeur, et garder le code toujours dans un état fonctionnel. L’auteur insiste sur l’importance de documenter systématiquement et de refactorer régulièrement pour éviter l’accumulation de chaos, tout en limitant le contexte fourni au LLM pour éviter les hallucinations. Une méthode qui privilégie la consistance à la vitesse, et qui permet de scalabiliser l’usage des LLM même sur des codebases complexes.
Pour intercepter le trafic réseau d’une application Android, deux approches principales existent : l’inspection via Android Studio (réservée aux apps en développement) et l’utilisation d’un proxy HTTPS (comme Proxyman) pour les apps tierces. En développement, Android Studio exploite le flag android:debuggable="true" et le protocole JDWP pour rediriger les flux réseau via ADB, permettant d’analyser les requêtes HTTP(S) sans déchiffrement direct, mais en interceptant les objets mémoire des bibliothèques comme OkHttp. Pour les apps en production, non debuggables, la solution passe par un proxy HTTPS (ex : Proxyman) : il faut rediriger le trafic de l’émulateur/device vers le proxy, installer son certificat root dans le magasin système (nécessitant souvent un accès root ou un émulateur non-production), puis activer le déchiffrement HTTPS pour les domaines cibles. Cette méthode contourne les restrictions d’Android 7+ sur les certificats utilisateur, mais exige des manipulations avancées (injection de certificats via adb, configuration de SELinux, etc.). L’article détaille aussi le rôle clé de Zygote dans l’initialisation des apps et propose des scripts pour automatiser l’installation des certificats. Une alternative comme Frida est évoquée pour des cas plus complexes.
Cet article explore des techniques avancées pour personnaliser les Dev Containers, allant au-delà de la simple configuration de base. L’auteur illustre comment installer un outil comme SliDesk via différentes méthodes : en utilisant postCreateCommand (simple mais répétitif), en créant une feature (réutilisable et versionnable, idéale pour partager des configurations), ou en construisant une image Docker custom (pour un environnement sur mesure et optimisé). Il aborde aussi l’utilisation de Docker in Docker pour construire des images directement depuis le conteneur, et de Docker Compose pour gérer des environnements complexes incluant des bases de données ou d’autres services. Enfin, il présente les templates, qui permettent de pré-configurer des Dev Containers pour des projets similaires, évitant ainsi la duplication de code. Une lecture essentielle pour qui veut industrialiser et standardiser ses environnements de développement avec flexibilité et efficacité !
L’article relate l’expérience d’un ingénieur utilisant Claude Code pour automatiser des tâches de développement (refactoring, correction de bugs, écriture de tests). Si l’outil excelle pour des corrections ponctuelles, il génère souvent des PRs volumineuses et illisibles, rendant la revue de code difficile. La solution trouvée : apprendre à Claude à structurer son travail en "stacked PRs" (séries de petites PRs ciblées et indépendantes), comme le feraient des humains expérimentés. En guidant l’IA avec des instructions précises et en utilisant l’outil GT MCP de Graphite, l’auteur parvient à obtenir des PRs claires, testables et faciles à relire. Résultat : une intégration plus fluide de l’IA dans le workflow, permettant de construire des fonctionnalités complètes, de corriger des bugs complexes et d’ajouter des tests, tout en gardant un code maintenable et collaboratif.
L’IA est un outil puissant pour accélérer et optimiser le développement, pas pour remplacer les devs. L’article illustre comment intégrer l’IA à chaque étape d’un projet (ex. : un site de location de voitures) : planification (génération de briefs et wireframes en quelques minutes), design (création d’interfaces et de code HTML/CSS via des outils comme v0.dev), boilerplate (conversion rapide en React/TypeScript avec des prompts précis), et amélioration (refactoring collaboratif pour rendre le code scalable et propre). L’IA automatise les tâches répétitives (recherche, design, code basique), mais c’est au développeur de superviser, architecturer et corriger les imperfections (logique métier, réutilisabilité). L’enjeu ? Travailler plus intelligemment, en utilisant l’IA comme un "pair programmer" pour se concentrer sur les défis complexes (architecture, UX, performance). À condition de rester critique : l’IA génère du code, mais c’est à vous d’en garantir la qualité et l’éthique. "Un dev qui maîtrise l’IA aura toujours un avantage."
L'auteur partage son expérience approfondie de l'utilisation des Large Language Models (LLMs) pour le codage. Il souligne que l'utilisation des LLMs pour le codage est complexe et nécessite de fixer des attentes raisonnables. Il insiste sur l'importance de comprendre les dates de coupure d'entraînement des modèles et de gérer efficacement le contexte. Il partage des conseils pratiques tels que demander des options aux LLMs, fournir des instructions détaillées et itérer sur le code généré. Il discute également des avantages d'utiliser des outils capables d'exécuter et de tester le code, et introduit le concept de "vibe-coding" comme moyen d'apprentissage et d'expérimentation avec les LLMs. Il conclut que les LLMs accélèrent considérablement le développement et amplifient l'expertise existante, facilitant ainsi la mise en œuvre des idées et l'apprentissage de nouvelles choses.
L'article traite d'un phénomène courant dans le développement logiciel où des outils complexes ou peu familiers ne sont pas utilisés de novo, mais plutôt copiés et ajustés à partir d'exemples précédents. Ce phénomène, qu'il baptise « l'effet Makefile », est observé chez les ingénieurs de tous niveaux d'expérience. Par exemple, au lieu d'écrire un nouveau Makefile, un ingénieur copie souvent un Makefile existant d'un projet antérieur et le modifie jusqu'à ce qu'il fonctionne dans le nouveau contexte. Bien que cela puisse sembler efficace à court terme, cela indique que l'outil est trop compliqué ou ennuyeux à utiliser de zéro. Ce phénomène est également observé dans d'autres domaines comme les configurations CI/CD et les systèmes de build. L'auteur souligne que les outils qui encouragent ce comportement peuvent avoir des diagnostics ou un support de débogage moins qu'idéaux, décourager l'apprentissage approfondi, et être plus difficiles à utiliser de manière sécurisée. Il suggère que les concepteurs d'outils devraient viser à minimiser cet effet en rendant les outils plus intuitifs et faciles à utiliser dès le départ.