- Si vous avez récemment utilisé des outils d’IA pour du travail de développement professionnel, merci de partager votre expérience
- Quels outils avez-vous utilisés ?
- Quels aspects ont été efficaces, et pourquoi ?
- Quelles difficultés avez-vous rencontrées, et comment les avez-vous résolues ? (si vous les avez résolues.)
- Merci d’indiquer suffisamment de contexte (stack technique, type de projet, taille de l’équipe, niveau d’expérience) afin que les autres puissent apprendre de votre expérience
- L’objectif est de comprendre objectivement la réalité du développement assisté par l’IA en mars 2026, sans récit fantaisiste
Résumé des réponses sur Hacker News
Problèmes de documentation et de communication générées par l’IA
- Des managers génèrent avec Claude des documents de conception de 50 pages, des PRD et des jeux de slides, puis les envoient en demandant de « revoir ça rapidement », alors qu’eux-mêmes ne les ont pas lus
- Certains employés produisent des slides sans fin tout en esquivant les questions concrètes
- Un problème de performance DB auparavant réglé en 30 minutes (ajout d’un GSI, etc.) peut désormais prendre une semaine à cause d’un document de 37 pages généré par l’IA (explication, atténuation, plan, revue, risques, déploiement, etc.)
- On voit apparaître un schéma de communication « IA vers IA » : l’expéditeur envoie du contenu généré par IA, puis le destinataire le résume à son tour avec une IA
- Dans le flux « concept → gonflage par LLM → résumé par LLM → destinataire », il existe un risque de perte de contexte et de nuances, comme dans un téléphone arabe
- Il est jugé impoli qu’une partie déverse du contenu de faible qualité tout en attendant une revue soignée de l’autre
- Exemple d’un client freelance qui envoie avec l’IA des spécifications excessivement raffinées, alors qu’en réalité il veut juste un tableau CSV de 30 lignes
Expériences négatives en environnement de travail
- Structure où des développeurs seniors font tout avec l’IA puis refilent le nettoyage aux développeurs juniors
- Le code généré par l’IA ne respecte pas la conception API du projet principal et contient en masse du parsing et de la gestion d’erreurs inutiles
- Le nettoyage a pris plus d’une semaine, alors que l’équipe d’origine produisait presque immédiatement, d’où un paradoxe : cela paraît en réalité plus lent
- Une grande entreprise cotée s’est fixé comme objectif 100 % de code généré par IA d’ici un an, et a poussé vers la sortie des employés de tous niveaux qui s’y opposaient
- Dans une culture qui optimise davantage la vitesse de livraison des fonctionnalités que la qualité du code, les ingénieurs qui travaillent sur la qualité sont structurellement considérés comme « inefficaces »
- Un membre d’équipe a pris du code écrit des semaines plus tôt, l’a mis dans Claude, puis l’a soumis comme si c’était terminé, alors que cela contenait de nombreuses erreurs métier et des bugs graves
- Dans les environnements où l’usage de l’IA est obligatoire, la charge de revue de code explose, avec des milliers de lignes de PR médiocres à examiner chaque jour
- « On m’a retiré tout ce que j’aimais, et il ne reste que ce que je détestais »
Expériences chez les FAANG et dans les grandes entreprises
- Employé FAANG : au travail, jamais obtenu de résultat intégrable tel quel, tandis que sur des projets personnels, la vitesse a été multipliée par 10
- La visibilité du modèle est limitée, car les frameworks et bibliothèques internes de grands codebases ne figurent pas dans les données d’entraînement
- Dans l’équipe, il n’y a pratiquement personne que l’on connaisse personnellement ayant eu un vrai succès
- Ingénieur Amazon : utilise Kiro (outil interne AWS) et Opus 4.6, avec une productivité 2 à 4 fois supérieure au travail, et plus de 10 fois sur son activité annexe
- Utilisation non seulement pour écrire du code, mais aussi pour l’analyse de données, le débogage et la gestion des boucles de déploiement
- Une fonctionnalité qui prenait auparavant un mois est implémentée en deux semaines — le gain essentiel étant le temps économisé à apprendre des détails techniques qui ne serviront plus ensuite
- Concernant une panne chez Amazon : l’interdiction du code IA rapportée dans les médias serait inexacte ; pendant l’incident, un seul conseil lié à l’IA s’appuyait sur un ancien wiki interne
- Ingénieur Microsoft : accès illimité à Opus via GitHub Copilot ; le travail va plus vite, mais les attentes ont grimpé de façon excessive (de 2 semaines attendues à 2 jours)
- R&D dans une grande entreprise : plus grande valeur dans le suivi de bugs et la génération de code de logging ponctuel, avec aussi un gain spectaculaire en prototypage
- Mais la baisse du coût d’implémentation intensifie la compétition autour de « quoi construire », ce qui exige une réflexion plus rapide et un jugement plus clair
Expériences positives et gains de productivité
- Ingénieur avec 10 ans d’expérience, petite équipe : construction et maintenance d’une application grand public à 100K DAU avec 3 personnes, alors qu’il en aurait auparavant fallu 10
- Pas de liste de bugs, codebase presque entièrement comprise par 2 personnes, refactorings beaucoup plus fréquents
- Simon Willison : depuis novembre 2025, écrit la majeure partie de son code avec des agents, y compris via Claude Code sur iPhone
- Des projets envisagés depuis des années sont réalisés en quelques heures, ce qui recalibre les possibilités du développeur solo
- Écrit une application Go avec Claude Code et apprend un nouveau langage par apprentissage osmotique
- Freelance expérimenté : après adoption de Claude Code, précision de 95 % sur Terraform et vitesse multipliée par plus de 5 sur des projets de traitement de données
- « Je peux maintenant faire ce que je ne pouvais pas faire ; ce qui était difficile est devenu facile ; et ce qui était facile est devenu plus rapide et plus simple »
- Petit studio de jeux : usage pour améliorer les outils internes et les workflows ; plus on est proche de l’idée, plus le codage par IA est efficace
- Exploitant d’une petite brasserie : automatisation de la comptabilité (16 h/mois → 3 h), rapports de production et de ventes, application de suivi des récompenses, soit plus de 5 outils internes créés
Usage pour comprendre une codebase et pour le débogage
- Efficace dans les codebases volumineuses ou legacy pour des questions comme « quelles fonctions touchent cette table ? »
- Exploration d’un énorme monolithe : à la question « combien existe-t-il de modes d’authentification pour les endpoints API ? », l’IA en trouve et résume 4 en 5 minutes
- Débogage : très utile pour comprendre pourquoi une regex complexe ne matche pas, et excellente pour l’analyse de stack traces et de logs
- Le temps d’onboarding sur une codebase inconnue est passé de plusieurs jours à quelques minutes
- Le processus consistant à « demander à un collègue en Inde ou en Europe de l’Est et attendre toute la nuit » serait entièrement remplacé par l’IA
Inquiétudes sur la qualité du code et la maintenance
- Problèmes récurrents du code généré par IA : complexité inutile, gestion d’erreurs excessive, logique dupliquée, non-réutilisation des fonctions existantes
- Pour du code destiné à être maintenu, l’écrire soi-même est plus rapide à long terme — avec du code IA, le modèle mental manque au moment de le modifier plus tard
- Cas où Claude a tenté de remplacer un sanitizer HTML par une regex personnalisée — les tests passaient, mais cela introduisait une faille de sécurité
- Cas où, lors de la création d’une API avec authentification, l’IA a ajouté une route permettant à n’importe qui de faire un PUT d’une nouvelle clé API
- L’IA fait très peu de refactoring proactif pour réduire la complexité d’une codebase, et continue d’accumuler logique dupliquée, abstractions inutiles et dépendances circulaires
- Il existe un cas de codebase de 200K LOC écrite à 99,5 % par IA, mais avec TDD stricte et revue de chaque ligne comme prérequis
Dégradation des compétences et impact psychologique
- « Comme je connais bien ma propre paresse, mes compétences vont se dégrader » — certains choisissent de ne pas utiliser du tout la génération de code par IA
- Un collègue reconnaît dépendre de l’IA depuis six mois ; il essaie d’arrêter, mais y revient facilement, comme à une drogue
- Un développeur junior soumet depuis un an des MR de plus en plus aberrantes, avec des traces d’usage de l’IA
- Ingénieur senior : « Je sais que mes compétences en code se dégradent, mais je ne suis pas sûr que coder soit vraiment la partie que j’aimais le plus » — il consacre davantage de temps à la conception et à l’architecture
- Sur des projets personnels, l’IA permet d’aller 10 fois plus vite, mais comme “ce n’est pas vraiment moi qui l’ai fait”, le sentiment de connexion disparaît et la motivation s’effondre avant la fin
- « L’IA fait bien les parties que j’aimais, et me laisse davantage de temps sur les parties que je détestais ou qui m’épuisent » — d’où un stress global accru
- Ingénieur avec 3 ans d’expérience : l’IA peut faire 90 %, mais pour faire les 10 % restants il faut disposer du modèle mental de ces 90 %, et ce modèle ne se construit qu’en codant soi-même
Workflows efficaces et bonnes pratiques
- Le flux spec → plan → critique → amélioration du plan → implémentation produit les résultats de meilleure qualité
- Utiliser le Plan Mode avant l’implémentation, puis ajouter une revue de code avec le même modèle après l’implémentation (de préférence dans une session séparée)
- Documenter style de code, patterns et interdits dans des fichiers AGENTS.md / CLAUDE.md, puis les mettre à jour à la fin de la session
- Donner à l’agent des capacités de débogage et de validation autonomes : exécution des tests, vérification des logs, validation par captures d’écran, etc.
- Si l’on explicite les contraintes à l’avance (« bibliothèque standard uniquement, pas de nouveau fichier, moins de 50 lignes »), la qualité du résultat s’améliore fortement
- Gestion d’un fichier d’état (mechanical ledger) entre plusieurs agents : commits, tests, échecs de patch y sont consignés afin que les nouvelles sessions reconstruisent le contexte à partir de l’état réel plutôt que d’une mémoire approximative
- Utilisation de Git worktree pour mener plusieurs tâches en parallèle tout en isolant les contextes
Rôles non techniques et extension de l’IA
- PM/directeur des opérations : dans une petite entreprise sans programmeurs, a construit 12 outils internes au cours de l’année écoulée et appris des concepts de développement à une vitesse surprenante
- Cofondateur non technique : peut générer des prototypes fonctionnels, mais le passage en production nécessite toujours un ingénieur — le pair programming est plus productif qu’un document de conception
- Débogage pendant 3 heures en session de pair programming du code ESRI Arcade généré par MS Copilot pour un manager non technique — le rôle d’« expert en débogage IA » devient une nouvelle prestation facturable
Différences d’efficacité selon les domaines
- Développement web/API : note A, efficace sur toute la stack, de l’architecture au débogage de compatibilité des packages
- Unity / développement de jeux : note C-, incapacité à comprendre le graphe de scène, le modèle de composants et les comportements dépendants du matériel
- Imagerie médicale : échec faute de connaissances spécialisées ; toutes les suggestions d’optimisation de performance ont échoué à améliorer les données réelles
- Applications Rust : efficace en greenfield Python/web, mais workflow agentique peu productif sur des applications Rust de moins de 100K LOC
- Traitement du signal, embarqué, HPC : hallucinations fréquentes et quasi-inutilité sur des API externes non documentées
- Algorithmes de graphe en C++ : résultats extrêmement non linéaires — soit juste du premier coup, soit échec total, sans entre-deux
Perspectives et inquiétudes pour l’industrie
- Prévision selon laquelle, d’ici 5 à 7 ans, l’aveuglement pro-IA des CEO/CFO conduira à une grave pénurie de talents et à un triplement des salaires
- Crainte d’une disparition des profils intermédiaires, avec seulement un petit nombre de seniors chargés de donner la direction, coordonner et exécuter
- L’IA entrerait dans une phase d’auto-amélioration récursive, rendant impossible toute prédiction fiable sur les six prochains mois
- Un article du MIT a confirmé les limites du scaling en largeur (width) des modèles, ainsi que les problèmes d’épuisement des données d’entraînement et de baisse de qualité des données synthétiques
- « Soit tout le monde perdra son travail, soit un effondrement massif du marché est imminent, soit les deux » — époque fascinante, mais anxiogène
- Marché freelance : les freelances installés sur des relations de long terme ne perçoivent pas encore de ralentissement, tandis que les petites missions ponctuelles pourraient être remplacées par l’IA
Le choix de ne pas utiliser l’IA
- Avant l’usage des LLM, un collègue disposait déjà de son automatisation, mais l’IA lui donne l’impression de s’occuper d’un junior incompétent, ce qui lui a fait perdre tout intérêt
- « Un piège qui ne résout aucun problème et n’en introduit que de nouveaux » — certains interdisent par principe l’usage de l’IA dans leur propre travail
- En robotique, avec C++ et Python, les essais de codage assisté par IA ne produisent que des déchets à moitié fonctionnels, et expliquer les besoins en langage naturel est pénible
- Le fait de coder soi-même pour réfléchir à l’architecture du code et à l’avenir technique est une valeur qui ne peut absolument pas être déléguée
Aucun commentaire pour le moment.