Mitchell Hashimoto partage son parcours d'adoption de l'IA, en six étapes, depuis le scepticisme initial jusqu'à une intégration efficace dans son flux de travail. Il commence par abandonner l'utilisation directe des chatbots pour le codage, soulignant leur inefficacité pour des tâches complexes. Il recommande ensuite d'utiliser des agents, des modèles de langage capables d'interagir avec des outils externes. Hashimoto décrit son expérience avec Claude Code, où il a reproduit manuellement ses propres travaux pour améliorer ses compétences et comprendre les capacités de l'IA. Il insiste sur l'importance de diviser les tâches en étapes claires et actionnables pour maximiser l'efficacité. Son approche nuancée et mesurée offre une perspective équilibrée sur l'adoption de l'IA dans le développement logiciel.

Nirina Rabeson explore la question de l'utilisation de l'IA par les développeurs juniors. Initialement opposée à cette pratique, elle change d'avis après avoir observé des juniors utiliser efficacement des outils comme GitHub Copilot et ChatGPT. Elle souligne que son approche traditionnelle d'apprentissage par la pratique présente des limites, notamment en ne permettant d'apprendre que ce que le mentor connaît déjà. Elle conclut que l'IA pourrait être un atout pour les juniors, à condition qu'ils sachent bien implémenter les feedbacks et traiter la dette technique.

Joppe De Cuyper explore l'idée d'un monde où l'IA génère du code sans intervention humaine, remettant en question l'importance des principes de "clean code". Il présente un projet Symfony sans code source, où seul un ensemble de spécifications et de tests sont maintenus. L'IA génère le code nécessaire à chaque build, le rendant obsolète après utilisation. Cette approche permet une amélioration continue du code grâce aux avancées de l'IA, sans héritage de code ancien. Le projet, illustré par une API de gestion de tâches, montre comment les spécifications détaillées peuvent remplacer le code source traditionnel.

L'article décrit comment son travail en ingénierie logicielle a évolué avec l'utilisation d'outils d'IA comme Codex. Il explique que, bien qu'il n'écrive plus de code manuellement, il passe par des étapes rigoureuses de planification, de vérification et de test, en utilisant des agents pour générer des implémentations. Les tâches sont divisées en planification (25-35%), revue et tests (40-50%), et exécution par l'agent (15-25%). Les gains de productivité sont significatifs pour des tâches standard, mais les agents ont encore des limites dans des domaines comme les refactorisations architecturales complexes ou le débogage profond. Les contraintes actuelles incluent les limites de contexte et la dérive architecturale.

Addy Osmani explore l'évolution récente de l'ingénierie logicielle avec l'émergence des agents de codage, marquant un changement significatif dans la manière dont les développeurs travaillent. Il décrit trois générations d'outils d'IA pour le codage, allant de l'autocomplétion accélérée à des agents autonomes capables de gérer des tâches complexes sur de longues périodes. Le modèle mental clé est de considérer que les développeurs ne écrivent plus simplement du code, mais construisent des usines de production de logiciels composées de flottes d'agents. Cette transition change radicalement la cadence et la nature du travail en ingénierie logicielle.

Dans cet article, l’auteur raconte comment il a transformé son workflow de développement en confrontant systématiquement deux IA — Claude Code pour générer et planifier le code, et Codex pour faire une code review objective — ce qui améliore nettement la qualité du code produit : il utilise un fichier CLAUDE.md pour configurer les attentes d’emblée, exige des plans avant l’écriture, et fait reboucler les remarques de Codex vers Claude Code jusqu’à alignement, tout en s’appuyant sur des tests, du linting et un jugement humain pour garder le contrôle.

Addy Osmani explique pourquoi il est préférable d'éviter d'utiliser le fichier AGENTS.md généré automatiquement par la commande /init dans les projets de développement. Selon des études récentes, ces fichiers peuvent ralentir les agents, augmenter les coûts et réduire l'exactitude. Les fichiers AGENTS.md écrits par des humains, contenant des informations non découvrables par les agents, sont plus bénéfiques. De plus, une hiérarchie de fichiers AGENTS.md, placés à des niveaux pertinents dans le projet, est plus efficace qu'un seul fichier centralisé. L'auteur souligne l'importance de ne garder dans ces fichiers que les informations essentielles et non redondantes.

Chez Les-Tilleuls.coop, l'IA redéfinit les métiers du développement en passant d'une logique de codage à une approche d'orchestration. Les développeurs supervisent désormais des agents autonomes qui analysent, implémentent, testent et documentent, réduisant ainsi le temps passé à écrire du code. L'utilisation de fichiers Markdown pour structurer la connaissance et la documentation devient cruciale pour optimiser l'efficacité des LLM. L'intégration de l'IA dans les processus Dev/PO vise à centraliser l'information dans le repository Git, facilitant ainsi une collaboration fluide entre développeurs et Product Owners.

James Randall, un développeur expérimenté, partage son évolution dans le monde de la programmation depuis ses débuts à l'âge de 7 ans en 1983. Il évoque avec nostalgie l'ère des machines 8-bits et des premiers PC, où la compréhension technique était essentielle et où la créativité naissait des contraintes matérielles. Il décrit comment l'industrie s'est professionalisée, rendant la technologie plus accessible mais moins fascinante. Il exprime aussi sa déception face à l'utilisation actuelle des technologies pour la surveillance et l'extraction de données, loin de l'optimisme initial. Malgré ces changements, il souligne l'adaptabilité des développeurs face aux transitions technologiques constantes. Un témoignage poignant sur l'évolution de la programmation et de ses promesses.

Depuis 1969, chaque décennie voit émerger des promesses de simplification du développement logiciel pour réduire le besoin en développeurs. De COBOL aux outils CASE, en passant par Visual Basic, chaque innovation a échoué à éliminer la complexité inhérente à ce métier. Malgré des avancées technologiques, la nécessité de compétences spécialisées persiste, frustrante pour les dirigeants mais révélatrice de la nature complexe du travail en logiciel.

Le Context Driven Engineering émerge comme un nouveau paradigme de développement logiciel à l’ère de l’IA : au lieu de simplement générer du code à partir de prompts, les équipes doivent fournir un contexte structuré (spécifications, contraintes, règles et documentation) et suivre un workflow type spec-plan-act afin de fiabiliser la production et d’industrialiser l’usage des assistants. L’article montre que cette évolution entraîne la mise en place de règles pour les agents, d’outils de gouvernance, d’intégrations CI/CD et de nouvelles pratiques de documentation, tout en soulevant des enjeux humains et organisationnels tels que la formation des juniors, la mutation du rôle des développeurs et la nécessité de conserver les fondamentaux de l’ingénierie — architecture, tests, sécurité et documentation — qui deviennent encore plus critiques dans un contexte où le code peut être produit massivement par des IA.

L’article décrit comment créer une compétence (skill) pour Claude Code qui implémente un système de mémoire de projet, capable de conserver automatiquement les décisions architecturales, bugs résolus, faits clés et historiques de travail pour éviter que l’assistant n’oublie d’une session à l’autre; ce système, appelé project-memory, tient en moins de 300 lignes et a permis à l’auteur de gagner beaucoup de temps en réduisant la répétition des explications et erreurs déjà traitées, tout en montrant comment structurer et déclencher une skill via un fichier SKILL.md et l’installer (par exemple via le CLI skilz) pour standardiser la mémoire de projet à travers plusieurs outils d’aide au développement.

L'article explore l'utilisation pratique des outils de codage basés sur l'IA pour les développeurs responsables. Il met en lumière comment des outils comme Copilot, Cursor, Claude et ChatGPT peuvent améliorer le flux de travail en gérant des tâches fastidieuses, en aidant à naviguer dans des codebases complexes et en facilitant l'implémentation de fonctionnalités dans des langages inconnus. L'auteur partage des techniques concrètes pour utiliser ces outils de manière responsable, en insistant sur la qualité du code, la sécurité, la confidentialité et l'approbation des outils par l'employeur. L'article se concentre sur des applications pratiques, notamment la compréhension de codebases inconnus et la gestion des changements de rupture lors des mises à niveau.

L’article explique que dans le développement logiciel, l’ego des développeurs est souvent la vraie source de dysfonctionnements en équipe car il transforme les débats techniques en combats de personnalité et freine l’amélioration collective; l’egoless programming consiste à laisser le problème guider les décisions plutôt que la défense de ses propres idées, en restant ouvert aux idées des autres, en acceptant les retours sans défensivité et en dissociant sa valeur personnelle de la qualité du code, ce qui améliore collaboration, innovation et résultats produit.

L'article explore l'évolution des stratégies de développement logiciel, passant du traditionnel "Build or Buy" à un nouveau paradigme "Build, Buy, Run or Vibe" (BBRV) avec l'essor de l'IA. L'auteur souligne que la capacité à produire du code n'est plus un avantage compétitif durable, car les assistants de code boostés par l'IA permettent de reproduire rapidement des logiciels existants. Il illustre ce point avec des exemples comme Nolto.social et Pono-job.eu, des alternatives à LinkedIn développées par de petites équipes grâce à l'IA. L'article met en lumière les défis pour les créateurs de logiciels, notamment les SAAS, et suggère que la compréhension métier devient un facteur clé de différenciation.

L'auteur partage son expérience sur l'impact de l'IA dans son processus de développement, tout en soulignant l'importance cruciale du rôle humain dans la revue et l'analyse des sorties générées par l'IA. Bien que l'IA ait transformé son flux de travail, il insiste sur la nécessité de revoir chaque modification pour garantir la qualité, la sécurité et la compatibilité des changements. Il argue que la responsabilité et la compréhension des systèmes restent essentielles, et que les ingénieurs et architectes logiciels sont plus cruciaux que jamais dans cette nouvelle ère.

L'auteur partage son expérience et ses réflexions sur l'importance de diversifier ses compétences au cours de sa carrière, plutôt que de se cantonner à une seule spécialité. Il suggère de viser un profil en "N" ou en "M", c'est-à-dire d'acquérir des compétences dans plusieurs domaines. Par exemple, un SRE (Site Reliability Engineer) ayant également une expérience en développement sera plus à même de comprendre les besoins des développeurs et de travailler efficacement avec eux. De plus, cette diversité de compétences permet de mieux détecter les problèmes et de participer activement à la résolution des incidents. L'auteur encourage à changer de poste pour acquérir de nouvelles expériences et compétences, ce qui est enrichissant et valorisant.

L’article présente une sélection d’essais influents qui ont marqué la pensée et les pratiques de l’auteur en tant qu’ingénieur logiciel. Parmi les textes cités, on retrouve des classiques comme « Choose Boring Technology » de Dan McKinley, qui prône l’utilisation de technologies éprouvées pour éviter les risques inutiles, « Parse, Don’t Validate » d’Alexis King, qui encourage à transformer les données en types riches pour éliminer les états invalides, ou « Things You Should Never Do, Part I » de Joel Spolsky, mettant en garde contre les réécritures complètes de code. D’autres essais, comme « The Majestic Monolith » de DHH ou « The Rise of ‘Worse is Better’ » de Richard P. Gabriel, remettent en question les tendances architecturales (microservices, perfectionnisme) au profit de solutions pragmatiques et adaptées au contexte. L’auteur souligne aussi l’importance de la qualité (« Software Quality at Top Speed » de Steve McConnell) et de la valeur métier (« Don’t Call Yourself a Programmer » de Patrick McKenzie). Enfin, des conseils plus larges, comme « How To Become a Better Programmer by Not Programming » de Jeff Atwood, rappellent que les compétences techniques ne suffisent pas : comprendre le domaine, communiquer et éviter la complexité inutile sont tout aussi cruciaux. Une lecture inspirante pour repenser sa pratique du développement.

Stanislas a développé une interface en mode texte (TUI) pour indexer et rechercher ses sessions avec des agents de codage locaux comme Claude Code, Codex, OpenCode, et Copilot. Face aux limitations des fonctionnalités de reprise de session des agents (recherche limitée, sessions liées à un répertoire), il a créé un outil permettant de rechercher dans le contenu des sessions et de les reprendre rapidement. L'outil utilise Tantivy pour l'indexation et orjson pour le parsing rapide des fichiers JSON, et offre des fonctionnalités comme la recherche incrémentale, la navigation intuitive, et des statistiques. Le projet, nommé fast-resume, est disponible pour essai.

L'auteur explore l'évolution de la création logicielle avec l'essor des outils comme Claude Code, marquant un déplacement vers des logiciels personnels et éphémères. Il souligne la chute des barrières d'entrée pour le développement, permettant aux non-développeurs de créer des outils sur mesure pour des besoins spécifiques. Cette tendance s'éloigne du modèle SaaS traditionnel, axé sur la rétention, vers des solutions éphémères, locales et sans friction, optimisées pour l'immédiateté et le contrôle. L'article met en lumière une nouvelle ère où le logiciel devient une utilité personnelle générée, plutôt qu'un produit acheté, reflétant un retour aux origines des tableurs comme outils de résolution de problèmes ponctuels.