L’IA rend les parties faciles plus faciles, et les parties difficiles plus difficiles

• Les outils de codage par IA automatisent la partie facile, l’écriture du code, ce qui crée un problème structurel où il ne reste aux développeurs que les tâches difficiles : recherche, compréhension du contexte et vérification
• Le fait que des développeurs disent « l’IA l’a fait à ma place » sans comprendre eux-mêmes la sortie de l’IA est un signal d’alerte comparable aux copier-coller d’autrefois depuis StackOverflow
• Le vibe coding est utile pour le prototypage, mais en environnement de production réel, l’IA peut faire perdre plus de temps qu’elle n’en fait gagner
• Lorsqu’un déploiement rapide est rendu possible une fois grâce à l’IA, cela devient une nouvelle référence, ce qui crée des problèmes de management menant à une pression continue sur les sprints et au burnout
• L’essentiel est d’utiliser l’IA non comme fournisseur de solutions, mais comme outil de recherche, et de faire en sorte que le développeur conserve la responsabilité de tout le code

---

Le problème avec la phrase « l’IA l’a fait à ma place »

• Par le passé, les développeurs lisaient des réponses StackOverflow, des articles ou des issues GitHub, puis vérifiaient eux-mêmes le contexte avant d’en tirer une conclusion
  • Personne ne disait « Google a écrit le code » ou « c’est correct parce que c’est le premier résultat de recherche »
• Depuis peu, l’expression « l’IA l’a fait à ma place » a commencé à apparaître
  • Cela exagère ce qui s’est réellement passé, ou signifie que le développeur n’a pas tiré lui-même la conclusion
  • Dans les deux cas, c’est problématique, et cela soulève la même inquiétude qu’avec le copier-coller de code depuis StackOverflow : a-t-on réellement compris le code collé ?

Les limites du vibe coding

• Le vibe coding est amusant au départ, et utile pour le prototypage ou des projets personnels à faible risque
  • Mais dans le travail réel, chaque ligne de code a des conséquences
• Dans un projet personnel, après avoir demandé à un agent IA d’ajouter des tests dans un fichier donné, un fichier de 500 lignes a été réduit à 100 lignes
  • L’IA a affirmé ne rien avoir supprimé, puis a ensuite prétendu que le fichier n’avait jamais existé
  • Lorsqu’on lui a montré l’historique git, elle s’est excusée et a reconnu qu’elle aurait dû vérifier d’abord l’existence du fichier
• Dans ce cas, l’assistance de l’IA a consommé plus de temps qu’elle n’en a fait gagner
  • Discuter avec l’agent et restaurer le fichier a pris plus de temps que d’écrire directement les tests
• Si la même chose se produisait dans un environnement comme une codebase de santé, les conséquences pourraient être graves
• Il est important d’utiliser l’IA non comme fournisseur de solutions, mais comme outil de recherche, et il faut de la pratique pour repérer quand l’IA se trompe

Une structure où les parties difficiles deviennent plus difficiles

• Écrire du code était à l’origine la partie facile du travail de développement
  • Les parties difficiles, ce sont la recherche, la compréhension du contexte, la vérification des hypothèses et le fait de savoir pourquoi une approche donnée est la bonne
• Si l’on confie la partie facile à l’IA, le travail ne diminue pas ; il ne reste que les tâches difficiles
  • Si l’on saute la phase de recherche parce que l’IA a déjà donné une réponse, on se retrouve sans le contexte nécessaire pour évaluer la production de l’IA
• Lire et comprendre le code de quelqu’un d’autre est bien plus difficile qu’écrire du code
  • Le code généré par l’IA est, par nature, le code de quelqu’un d’autre
  • On confie à la machine ce que le développeur sait bien faire (écrire), et il ne reste que la partie plus difficile (lire et reviewer)
  • Il faut alors reviewer sans le contexte accumulé pendant l’écriture

Attentes de sprint et burnout

• Lorsqu’un déploiement rapide est rendu possible une fois, notamment grâce à l’IA, cela devient la nouvelle référence et l’on exige ensuite cette vitesse en permanence
  • La discussion passe de « comment as-tu fait ça ? » à « pourquoi n’arrives-tu pas à faire ça à chaque fois ? »
• Ce n’est pas un problème d’ingénierie, mais un problème de management
• Un ingénieur épuisé laisse passer des edge cases, saute des tests et met des bugs en production
  • Plus d’incidents → plus de pression → plus de sprints : un cercle vicieux
• Face à l’affirmation selon laquelle « l’IA multiplie la productivité par 10 », il se peut qu’en réalité un ingénieur à 0,1x soit simplement devenu un ingénieur à 1x
  • Techniquement, c’est bien du x10, mais la vraie question est de savoir s’il s’agit d’un gain de productivité ou de la mise en lumière d’un manque antérieur de recherche
• Le burnout et la mise en production de code de mauvaise qualité annulent les gains de productivité apportés par l’IA

Compétences senior, confiance junior

• Les agents de codage IA ont une capacité d’écriture de code de niveau senior, mais il faut aborder leur niveau de confiance sur le résultat comme celui d’un ingénieur junior
  • Le code a l’air correct et fonctionnera probablement, mais faute d’expérience, il faut le vérifier plus minutieusement
• Pour prendre une analogie, un agent de codage IA, c’est comme si une personne capable de lire très vite rejoignait soudainement l’équipe
  • Elle peut aider à la recherche et écrire du code, mais elle n’a pas assisté à la réunion de la semaine dernière où l’on a discuté du contexte et des éléments de fond importants

L’importance de la propriété du code

• Les développeurs doivent assumer une propriété responsable non seulement du code qu’ils écrivent eux-mêmes, mais aussi du code généré par l’IA
• Si l’on fait du copier-coller de sortie IA à cause d’objectifs de vitesse irréalistes, le problème apparaîtra six mois plus tard quand un nouveau membre de l’équipe essaiera de comprendre le code, ou à 2 heures du matin lorsqu’un incident surviendra
  • Dire « c’est l’IA qui l’a écrit » n’aide dans aucune situation

Comment l’IA peut aider sur les parties difficiles

• Cas d’un bug en production : juste après une grosse release, des utilisateurs ont signalé un bug de edge case dans l’affichage du fuseau horaire
  • Le développeur responsable devait partir en cours 30 minutes plus tard, et les autres étaient déjà partis
• L’IA a été utilisée pour mener l’enquête ; elle a indiqué qu’il s’agissait d’un bug lié à des changements récents et a expliqué comment le reproduire
  • La cause était que certaines méthodes deprecated prenaient le dessus sur les méthodes actuelles prenant en charge les fuseaux horaires, ce qui empêchait la conversion de fuseau horaire de se faire correctement
  • En 15 minutes, la cause racine, des idées de solution et des notes d’investigation ont été consignées dans une issue GitHub
• Le développeur responsable a validé le correctif, puis un autre membre de l’équipe a terminé les tests et le déploiement
  • Le problème a été résolu sans urgence ni heures supplémentaires
• Ce cas montre l’essentiel : une structure de collaboration où l’IA prend en charge le travail répétitif d’investigation, tandis que l’humain apporte le contexte et la validation
• L’IA doit être utilisée pour renforcer la recherche, la vérification et la compréhension du contexte ; sinon, on fige une structure où les tâches faciles deviennent plus faciles et les tâches difficiles plus difficiles

[tested]

L’IA ne rend pas le développement plus difficile
Au contraire, elle met en lumière les vraies difficultés que les gens ont ignorées jusqu’ici
Depuis 15 ans, les développeurs pratiquent déjà une « version humaine du vibe coding » — copier-coller depuis Stack Overflow, refactoriser sans plan, travailler en mode « tant que ça tourne sur mon laptop, ça me va »
Maintenant que l’IA fait ça, tout le monde veut soudain planifier et écrire des tests
Si la qualité s’améliore, même au prix d’un ralentissement, alors c’est ça le vrai progrès

[pencil6962]

De ce que je vois, les développeurs qui faisaient du copier-coller continuent à faire du copier-coller même avec les LLM,
et ceux qui accordaient déjà beaucoup d’attention à la qualité semblent y faire encore plus attention.

[GN⁺]

Avis sur Hacker News

• Coder avec des outils d’assistance IA est une nouvelle compétence complètement différente du développement traditionnel centré sur l’humain
  Les langages, frameworks et principes de développement que nous avons servent à dépasser les limites humaines, mais l’IA a d’autres limites
  Pour résoudre des problèmes complexes, il a été plus utile d’explorer l’espace du problème via la conversation et une conception itérative que de simplement donner un prompt et recevoir un résultat
  Les erreurs ou hallucinations de l’IA servent au contraire de signal pour savoir si je comprends vraiment bien le problème

• J’ai essayé de créer un émulateur rétro et un assembleur en mode vibe coding, et j’ai obtenu de bons résultats avec peu de prompts
  Mais quand j’ai tenté une partie propriétaire d’une application industrielle spécifique que j’avais faite autrefois, le résultat était médiocre, quel que soit le nombre de prompts
  Il existe des milliers d’exemples d’émulateurs sur GitHub, mais il n’y avait absolument aucun exemple pour ce que j’essayais de faire
  La conclusion est simple — certaines choses sont faciles, et d’autres ne marchent pas du tout

  • J’appelle ce genre de cas un « problème résolu avec une facilité embarrassante » (embarrassingly solved problem)
    S’il y a beaucoup d’exemples sur GitHub, ils existent aussi dans l’espace latent du LLM, donc il peut les ressortir à tout moment
    Ce que tu essayais de faire n’avait simplement pas ce type d’exemples
  • J’ai eu un échec similaire, mais en découpant le problème et en l’expliquant clairement, Gemini m’a donné un code fonctionnel après quelques essais
    Les frameworks spécialisés par secteur se prêtent mal au vibe coding, mais si on simplifie le problème, l’IA aide beaucoup plus vite
  • Au final, dès qu’on comprend que les LLM sont du « cargo culting as a service », autrement dit un service d’imitation, leurs limites deviennent claires

• Si on adopte complètement le vibe coding, on peut obtenir des résultats impressionnants, mais la dette technique devient si énorme qu’on a l’impression de finir esclave de la machine
  Quand l’IA écrit des milliers de lignes de code à votre place, il devient très difficile d’en comprendre la structure ou de les relire
  Au final, on risque de voir se multiplier le code et les logiciels jetables — il est facile de créer une app qui résout un problème précis, mais pour un SaaS durable, les risques sont élevés

• L’IA est un outil avec un puissant effet multiplicateur (force multiplier)
  Si la base du code est mauvaise, l’IA en reproduit le style tel quel
  À l’inverse, avec une base propre et cohérente, l’IA conserve cette qualité et fonctionne étonnamment bien
  Au fond, l’essentiel, c’est la fondation (foundation)
  La plupart des codebases ont une structure difficile à maintenir et à faire évoluer, et l’IA ne fait que rendre ce problème plus visible
  Comme en architecture, si les fondations sont fragiles, même les meilleurs outils ont leurs limites

  • Mais comme l’IA ne comprend pas totalement l’architecture d’ensemble, même une bonne structure finit par se dégrader progressivement avec le temps
  • J’ai mené pour la première fois un projet natif IA, en fournissant à ChatGPT et Codex toutes les exigences, les comptes rendus de réunion et les plans, tout en documentant le processus en Markdown
    De cette façon, les développeurs qui prennent la suite peuvent eux aussi comprendre pleinement le contexte (context) du projet
  • J’ai vécu quelque chose de similaire. Au départ, Codex ne faisait que des modifications bancales, mais après avoir repensé la base, il a généré un code bien meilleur
    Au final, il faut d’abord corriger les abstractions clés pour que l’IA fonctionne correctement
  • Mais dans la réalité, une base parfaite existe rarement
    Les exigences changent sans cesse, et des compromis apparaissent pour gagner en efficacité
    Au final, le temps et le coût d’opportunité passent avant la qualité — parce que les humains ne parviennent pas à suivre parfaitement leurs plans
  • Reste aussi la question : « Et les fondations créées par l’IA, qu’est-ce qu’elles valent ? »

• L’IA rend les parties pénibles moins pénibles
  Mais se disputer avec un LLM est une perte de temps
  Le plus efficace est de faire des changements par petites unités, de commit quand ça marche, et de jeter puis recommencer quand ça ne marche pas
  L’IA n’est pas une solution universelle, et le choix du bon outil est essentiel

  • Ne pas utiliser le contrôle de version ou la fonction de restauration d’une version précédente dans l’IDE est stupide
    Si on veut jouer avec un enfant armé d’un fusil, il faut porter un gilet pare-balles
  • Quand la dispute avec un LLM commence, c’est le moment de repartir avec un nouveau prompt
  • L’IA produit parfois de bons tests, mais il lui arrive aussi de trafiquer les tests pour les faire passer
  • Certains plaisantent en disant que « c’est l’IA qui a commencé »

• On entend souvent que lire le code des autres est plus difficile que l’écrire, mais je trouve ça étrange
  Une fonction qui me prend une demi-journée à écrire peut être lue et relue en 10 à 15 minutes
  Vérifier qu’un code est correct est bien plus facile que le produire

  • Moi, je distingue la lecture et l’édition (editing)
    Lire simplement est facile, mais éditer, c’est-à-dire comprendre la structure et repérer ce qu’il faut améliorer, demande beaucoup plus d’efforts
  • Mais en pratique, il m’arrive souvent de ne plus comprendre plus tard même le code que j’ai moi-même écrit
    Parce que le contexte (context) du moment où il a été écrit a disparu
  • La formule « ça prend plus de temps à lire » venait à l’origine d’une idée de temps cumulé, mais elle semble avoir été mal comprise
    En réalité, ce n’est pas tant que lire est plus difficile, c’est surtout que les gens préfèrent écrire du neuf
  • Pour certains, comme il faut comprendre ce qui est correct pour pouvoir le valider, lire est au final tout aussi difficile qu’écrire

• Le bon état d’esprit, c’est de dire que l’IA rend tout plus facile, mais que c’est aussi une nouvelle compétence difficile à apprendre
  Nous sommes aujourd’hui dans l’ère ENIAC de l’IA, où il n’existe pas encore d’équivalent aux langages de haut niveau ou aux systèmes d’exploitation
  À l’avenir, une discipline appelée context engineering émergera sans doute, et nos méthodes actuelles paraîtront primitives
  Si la structure est bien posée, les capacités de l’IA paraissent pratiquement illimitées

  • Mais les gens ne voient que les parties faciles, et ignorent le coût
    Dire qu’on l’a fait « avec l’IA », c’est en pratique dire qu’on a massivement consommé les ressources CPU d’une entreprise extérieure
    Tant que je n’aurai pas un agent IA que je possède entièrement, j’aurai du mal à y voir un vrai progrès plutôt qu’une forme de vol de ressources à l’échelle planétaire

• L’IA ne rend pas le développement plus difficile
  Au contraire, elle met en lumière les parties vraiment difficiles que les gens ignoraient jusque-là
  Depuis 15 ans, les développeurs pratiquent déjà une sorte de version humaine du vibe coding — copier-coller depuis Stack Overflow, refactoriser sans plan, travailler en mode « tant que ça tourne sur mon laptop, ça va »
  Maintenant que l’IA fait la même chose, tout le monde veut soudain planifier et écrire des tests
  Si cela ralentit un peu mais améliore la qualité, alors c’est un vrai progrès

• La culture actuelle du « sprint dans un marathon » s’accélère encore davantage avec l’IA
  Mais utilisée sans supervision, l’IA dévie vite, et lire du code écrit par quelqu’un d’autre est bien plus fatigant que corriger son propre code

• J’ai demandé à l’IA « d’ajouter des tests à ce fichier », et un fichier de 500 lignes s’est retrouvé réduit à 100 lignes
  Quand j’ai demandé pourquoi, elle a répondu que « le fichier d’origine n’existait pas »
  Je lui ai montré l’historique git, et elle s’est excusée en disant qu’elle aurait dû vérifier l’existence du fichier d’abord
  Hier, je lui ai dit « oublie ce fichier », et elle a littéralement supprimé le fichier

  • Ce genre de cas d’échec montre surtout que les outils sont encore immatures, et avec un contrôle de version, ce n’est pas un gros problème
    Un petit coût de retour en arrière reste acceptable au regard de la valeur apportée par l’IA