29 points par GN⁺ 2025-10-26 | 7 commentaires | Partager sur WhatsApp
  • Contrairement à l’idée reçue selon laquelle l’IA transformerait les développeurs en « managers » ou en « éditeurs », l’auteur propose une approche consistant à « coder comme un chirurgien », en mettant l’accent sur la concentration sur le travail essentiel
  • De la même manière qu’un chirurgien se concentre uniquement sur les étapes cruciales d’une opération avec l’appui d’une équipe de soutien, les développeurs peuvent déléguer les tâches annexes via des outils d’IA pour se consacrer à la résolution des problèmes de fond
  • Les tâches principales (par ex. le prototypage UI) restent réalisées directement par les humains, tandis que les tâches répétitives comme la documentation, la correction de bugs ou l’exploration du code sont prises en charge par des agents d’IA
  • En confiant à l’IA les tâches simples et répétitives, il devient possible de déléguer le grunt work sans problème de hiérarchie de statut, avec en plus une disponibilité 24 h/24 permettant de donner des consignes même tard dans la nuit ou pendant la pause déjeuner
  • Cette approche rejoint le concept d’« autonomy slider » d’Andrej Karpathy, et suggère que la stratégie d’utilisation de l’IA doit varier selon le niveau d’autonomie de la tâche

Coder comme un chirurgien : idée centrale

  • L’auteur s’oppose à la prédiction courante selon laquelle l’IA fera des développeurs des managers ou des éditeurs, et propose plutôt une manière de travailler comme un chirurgien (Surgeon)
    • Le chirurgien opère lui-même, mais s’appuie sur une équipe de soutien pour la préparation et les tâches secondaires, afin de se concentrer uniquement sur le travail essentiel qui exige son expertise propre
    • De la même façon, les développeurs peuvent utiliser l’IA comme personnel de soutien afin de se concentrer sur le travail créatif essentiel
  • L’auteur, qui travaille sur le prototypage UI, cherche à utiliser les outils d’IA pour consacrer 100 % de son temps à un travail à forte valeur
    • En déléguant les tâches annexes que l’IA peut traiter, il maximise sa productivité

Tâches annexes pouvant être déléguées à l’IA

  • Liste de tâches d’assistance que l’IA peut accomplir de manière satisfaisante
    • Rédiger des guides sur la codebase avant des changements d’ampleur
    • Générer une première ébauche de code de spike pour tester une grosse modification
    • Corriger des erreurs TypeScript ou des bugs lorsque les spécifications sont claires
    • Rédiger la documentation d’une fonctionnalité en cours de développement
  • Ces tâches peuvent être exécutées de manière asynchrone en arrière-plan
    • L’IA peut travailler pendant la pause déjeuner ou la nuit, pour une relecture dès le lendemain
  • Cela permet, comme un « chirurgien entrant dans une salle d’opération déjà prête », de se concentrer sur le codage essentiel une fois toute la préparation terminée

Mind the autonomy slider

  • Il existe une grande différence entre les tâches essentielles et les tâches d’assistance dans la manière d’utiliser l’IA
    • Le design central et le prototypage restent effectués directement par l’humain, où une boucle de feedback rapide et une forte visibilité sont cruciales
    • À l’inverse, pour les tâches annexes, il est plus efficace de laisser l’IA travailler de façon autonome pendant de longues périodes
  • Pour les longues sessions sans supervision, l’auteur préfère Claude Code, et plus récemment Codex CLI
  • Cette distinction est proche du concept d’« autonomy slider » d’Andrej Karpathy
    • Selon le niveau d’autonomie, les outils et l’état d’esprit nécessaires changent, et les confondre serait risqué

L’IA et le concept d’« équipe chirurgicale logicielle »

  • Le concept de « software surgeon » remonte à 1975, lorsque Harlan Mills l’a proposé dans The Mythical Man-Month de Fred Brooks
    • Un « chief programmer » occupe le rôle central, soutenu par un « copilot » et du personnel administratif
  • Autrefois, ces rôles de soutien étaient tenus par des humains, mais l’IA les remplace aujourd’hui sous une forme économiquement viable
  • L’auteur souligne que ce changement ne se limite pas à une réduction des coûts
    • Il atténue les problèmes de hiérarchie de statut
    • En déléguant à l’IA le grunt work répétitif et ingrat, il permet de réduire les déséquilibres dans la répartition des tâches au sein de l’équipe
  • L’IA étant disponible 24 h/24, elle peut aussi effectuer des recherches nocturnes ou des analyses de code impossibles à confier à un stagiaire humain

Notion et l’extension du « travail comme un chirurgien »

  • L’auteur explique que cette approche est déjà mise en œuvre chez Notion, où il travaille
    • L’entreprise encourage activement l’usage d’outils de codage IA, et la codebase est conçue en conséquence
    • L’effet sur la productivité est particulièrement fort pour les développeurs qui rejoignent une grande codebase
  • Côté produit, Notion cherche aussi à étendre cette manière de “travailler comme un chirurgien” à tous les travailleurs du savoir, au-delà des seuls programmeurs
    • L’objectif central n’est pas de déléguer le travail essentiel, mais d’identifier et de déléguer les tâches répétitives secondaires non importantes, afin d’aider chacun à se concentrer sur ce qui compte le plus

7 commentaires

 
vk8520 2025-10-27

Il me semble que cela signifie qu’il faut se concentrer sur le travail au cœur du métier et confier les tâches périphériques à l’IA. Sur ce point, je suis assez d’accord, et il semble possible de remplacer par l’IA certaines tâches qui ne relèvent pas du domaine métier central, déjà parfois remplacées par du SaaS, ainsi que des tâches administratives.
Ce qui sera encore plus sujet à débat, c’est de savoir si l’on peut remplacer par l’IA les tâches au cœur du métier. Au final, la tendance ira vers ce qui produit les meilleurs résultats. Quand on voit l’IA résoudre des problèmes d’IOI ou de LeetCode, elle montre parfois des capacités de programmation bien supérieures à celles des humains. Faire des prédictions hâtives dépasse un peu mes compétences, donc je pense qu’il vaut mieux attendre et voir.

 
fortune 2025-10-26

Cette analogie est complètement erronée, car elle ne saisit pas l’essentiel.

Une opération chirurgicale est un acte irréversible, alors que la programmation est un travail réversible (autrement dit, avec possibilité de save and load).

Si la chirurgie devenait elle aussi réversible, les chirurgiens feraient également faire l’opération à des subordonnés sachant opérer, et seraient plus efficaces en se chargeant ensuite de la conception, de la revue et du management depuis l’arrière-plan. En cas d’erreur, il suffirait simplement de revenir en arrière.

 
seunggi 2025-10-27

Je suis d’accord. De façon similaire, je pense qu’on confond souvent l’ingénierie logicielle avec l’ingénierie du secteur de la construction

  • Dans la construction, il existe des phases de transformation physique irréversibles (ou dont le coût de retour en arrière est excessivement élevé)
  • C’est pourquoi, dans la construction, la conception et l’exécution sont séparées, et c’est en imitant cela qu’ont émergé les projets SI de grande envergure au style enterprise, ainsi que les concepteurs de domaine et les architectes
  • À l’inverse, le logiciel est l’une des formes d’ingénierie les plus faciles à faire évoluer, et la conception est presque équivalente à la construction. Avec le Manifeste agile, le code lui-même et le fait qu’il fonctionne ont acquis une signification
  • Mais avec le développement fondé sur les LLM, il semble y avoir une dynamique où la conception est remise en lumière et où déléguer l’implémentation détaillée devient un facteur de productivité
 
chcv0313 2025-10-26

Si on veut vraiment coder comme de vrais chirurgiens, il ne faudrait pas réserver le code à ceux qui sont diplômés d’un cursus d’informatique ? Si on augmente les effectifs en informatique, les programmeurs devraient aussi s’unir et faire grève, un peu...

 
colus001 2025-10-28

Pourquoi il n’y a pas d’assistant de codage !?

 
forgotdonkey456 2025-10-27

hahahahahahahahahahahahahahahahahaha

 
GN⁺ 2025-10-26
Avis sur Hacker News
  • Si un chirurgien débutant commence une opération en pensant que les infirmières ou l’anesthésiste l’empêcheront de faire des erreurs, il peut tuer le patient très vite
    Le fait qu’une équipe chirurgicale soit nécessaire ne rend pas la formation d’un chirurgien senior inutile
    Le problème, c’est un chirurgien inexpérimenté qui se dit : « pas besoin d’apprendre puisque l’infirmière me tend le scalpel »
    Si au final il faut apprendre en sacrifiant des patients, alors soit, mais sinon il faut d’abord aller en faculté de médecine

    • L’auteur se présente comme « prototyper UI et quelqu’un qui touche aux concepts de design », tout en disant travailler dans une entreprise de logiciels de coding IA
      Du coup, tout le texte dégage un fort effet Dunning-Kruger (biais cognitif où une personne peu compétente surestime fortement ses capacités réelles)
  • Cela fait longtemps que je soutiens que tout ingénieur logiciel devrait lire The Mythical Man-Month
    Ces 25 dernières années, la manière de développer a énormément changé, comme le passage du waterfall à l’agile
    Mais quand on fait du développement basé sur les LLM (Codex, Claude Code, etc.), on a plutôt l’impression de revenir à des schémas de développement des années 70–80
    On peut désormais réfléchir à l’architecture comme si l’on concevait une cathédrale, et déléguer l’implémentation détaillée

    • Parmi les métaphores de Brooks, le modèle de l’équipe chirurgicale comporte une erreur
      En chirurgie, une seule personne opère à la fois, alors qu’en logiciel plusieurs personnes peuvent intervenir en même temps
      C’est en réalité plus proche d’une équipe de sport, et si la qualité prend du temps, c’est surtout parce qu’il nous manque de l’entraînement et du coaching
    • Quelqu’un a demandé à en entendre davantage sur la différence entre l’approche des années 70–80 et celle d’aujourd’hui
    • On se rapproche maintenant d’une sorte de CAO pour le logiciel, autrement dit de l’ère du CASE (Computer Aided Software Engineering)
      Cela permet de se concentrer davantage sur la conception que sur le coding
    • Réponse à l’idée de « concevoir comme on bâtit une cathédrale puis déléguer les détails »
      Si l’on construisait réellement un gratte-ciel, il faudrait se soucier jusqu’à la qualité de l’acier et la provenance des boulons
      Ignorer cela serait dangereux
  • Cette métaphore est erronée, au sens propre comme au sens figuré
    Le chirurgien n’est pas un simple exécutant, c’est le responsable de l’ensemble de l’opération, et en pratique l’anesthésiste est la personne la plus importante
    De plus, l’idée même de « simple besogne (grunt work) » est une mauvaise façon de voir les choses
    Se considérer comme le chirurgien et voir les autres comme du personnel d’appui relève d’une vision égocentrée

    • Il a été expliqué que l’interlocuteur citait simplement la métaphore de Fred Brooks
      Comme dans le concept de Chief Programmer de Brooks, le développeur principal peut travailler grâce au soutien de l’équipe
      L’auteur ne voit pas les juniors comme de simples subalternes, mais comme des mentorés
      Ce n’est pas une métaphore parfaite, mais le message sur les outils de coding IA mérite d’être pris en considération
    • À l’affirmation selon laquelle « l’anesthésiste est plus important », quelqu’un a répondu que sans chirurgien, l’opération elle-même est impossible
      Il a cité comme exemple le fait qu’historiquement, on pouvait opérer sans anesthésie
    • Certains ont aussi estimé que la comparaison avec du personnel d’appui visait les outils IA, et non un rabaissement de vraies personnes
    • D’autres métaphores sont elles aussi souvent fausses
      Par exemple, comme dans certaines explications de framework qui comparent les programmeurs à des menuisiers, un véritable artisan ne peaufine pas parfaitement chaque partie
    • Dans le débat sur la personne la plus importante au bloc, un lien a été partagé vers le cas de Leonid Rogozov, qui s’est opéré lui-même
  • J’aime bien cette métaphore et je pense l’utiliser à l’avenir
    On peut aussi prendre l’exemple de l’atelier d’un peintre classique
    Rembrandt ou Rubens faisaient préparer les toiles et peindre certaines parties par leurs élèves, tandis que le maître ne réalisait lui-même que les éléments essentiels
    En revanche, après le romantisme est apparu l’idéal de l’artiste qui achève tout seul l’œuvre entière
    Certains programmeurs veulent créer seuls comme Turner, mais moi je préfère, comme Rembrandt, penser le tableau d’ensemble et confier les détails à l’IA ou à des juniors

    • Mais dans le logiciel, le livrable n’est pas le code, c’est un produit qui fonctionne
      La qualité du code doit être bonne pour pouvoir réagir vite aux retours des utilisateurs
      Il ne s’agit pas simplement de « coder vite et passer à autre chose », mais de mettre en place une structure qui réduit le coût du changement
      Si l’approche façon Rembrandt mène à du bon code, très bien, mais les preuves manquent encore
  • J’ai moi aussi utilisé Claude pendant quelques mois, et j’ai trouvé plus efficace de coder directement moi-même
    En revanche, lors d’une grosse montée de version de base de données de MySQL 8 vers 9, j’ai demandé à Claude de repérer les requêtes potentiellement problématiques, et de façon surprenante il a visé juste dans la plupart des cas
    Ce n’était pas parfait, mais cela a beaucoup réduit le temps de débogage
    J’ai l’impression que les LLM apportent bien plus de valeur en repérant les points de risque qu’en écrivant directement le code

    • J’ai eu une expérience similaire
      Si on colle une stack trace issue d’une ancienne codebase, le LLM peut proposer une première direction de débogage
      Pour corriger des problèmes de performance aussi, on peut lui faire vérifier si deux chemins de code produisent le même résultat
      Pour l’instant, l’écriture de code reste au niveau de l’autocomplétion, mais le gain d’efficacité est bien réel
  • Cela m’a rappelé la présentation Software Faster de Dan North
    La formule « en logiciel comme en chirurgie, ne faire que le minimum nécessaire pour résoudre le problème » m’avait marqué
    Mais ce texte s’éloigne de cette philosophie

    • Mon prédécesseur suivait la philosophie du « pour gagner 5 minutes, copie-colle le fichier entier »
      Du coup, j’ai aujourd’hui l’impression d’être un chirurgien qui pratique souvent des amputations
  • La structure de type Chief Programmer Team semble redevenir à la mode
    Cette fois, l’équipe intègre des agents IA plutôt que seulement des humains
    L’idée de Fred Brooks attire de nouveau l’attention

    • L’auteur a aussi précisé qu’il citait directement Brooks et Harlan Mills
    • Il est surprenant que ce type d’organisation ne soit pas devenu plus populaire
      Si l’on associe une équipe compétente à un développeur 10x (10x-er), on peut réduire le temps perdu en réunions ou en gestion Jira
      Puisqu’on leur verse des salaires élevés, autant utiliser leur temps de la manière la plus précieuse possible
  • Comprendre le spectre de l’autonomie, ou spectre de la délégation, est la clé pour bien utiliser les outils de coding IA
    Les ingénieurs ne sont pas habitués à déléguer, alors que les fondateurs ont tendance à l’apprendre plus vite

  • À propos de l’expression « le chirurgien se concentre sur les tâches importantes », quelqu’un a fait remarquer qu’en réalité toutes les tâches de soutien sont tout aussi importantes
    Il faut rester humble, respecter l’aide autour de soi et les soutenir de la même manière