Le CEO de GitHub : « Le codage manuel reste essentiel », même en plein boom de l’IA
(techinasia.com)- Le CEO de GitHub, Thomas Dohmke, souligne l’importance de maintenir les compétences en codage manuel malgré la généralisation des outils d’IA
- Même si l’IA génère du code, il affirme qu’il est plus efficace que les développeurs le modifient et le relisent eux-mêmes
- En s’appuyant uniquement sur l’automatisation, on risque une inefficacité réelle et une baisse de productivité ; en cas d’usage excessif du « vibe coding », les risques de qualité et de sécurité augmentent
- Il explique, en s’appuyant sur les tendances du secteur et des cas concrets, qu’une approche hybride entre l’IA et les développeurs humains est la plus efficace
- Le rôle des développeurs ne disparaît pas : il évolue vers une collaboration avec l’IA, exigeant davantage de résolution stratégique de problèmes et de capacités de conception
Le CEO de GitHub souligne l’importance du codage manuel à l’ère de l’IA
Thomas Dohmke, CEO de GitHub, insiste sur l’importance de préserver les compétences en codage manuel, même si l’usage des outils d’IA se généralise dans le développement logiciel
- Lors de son passage dans “The MAD Podcast with Matt Turck”, il a expliqué que les développeurs doivent avoir la capacité de modifier eux-mêmes le code généré par l’IA afin d’éviter une baisse de productivité
- Selon lui, un workflow efficace consiste à laisser l’outil d’IA générer le code et soumettre une Pull Request, puis à permettre au développeur d’utiliser ses compétences pour corriger immédiatement
- Il souligne qu’en s’en remettant uniquement à des agents d’automatisation, on risque de perdre inutilement du temps à décrire en langage naturel de simples modifications, ce qui crée de l’inefficacité
- Dohmke fait remarquer que « tenter d’expliquer en langage naturel une tâche qu’on sait déjà effectuer soi-même dans un langage de programmation est le choix le plus inefficace »
- L’expression “vibe coding”, mentionnée par le cofondateur d’OpenAI Andrej Karpathy, désigne une dépendance excessive au code généré par l’IA, et Dohmke appelle également à la prudence sur ce point
Insights et tendances du secteur
1. La meilleure réponse au codage par IA est une stratégie hybride
- Le point de vue de Dohmke rejoint le consensus du secteur selon lequel la combinaison de l’automatisation par l’IA et des compétences humaines en programmation est la solution optimale
- Selon une étude de Deloitte, les développeurs utilisent principalement les outils d’IA pour écrire du code boilerplate, mais obtiennent un gain de productivité de 10 à 20 minutes en conservant une relecture humaine finale
- Environ la moitié du code généré par l’IA contient des erreurs partielles, ce qui fait de la stratégie « faire confiance, mais vérifier » une norme du secteur
- Chez Google, plus de 25 % du code total est généré par l’IA, mais l’expérience montre qu’un processus actif de revue et d’amélioration par des développeurs humains reste indispensable
- Cette approche équilibrée reflète une maturité croissante du secteur : les limites de l’IA sont mieux comprises, et l’expertise des développeurs est augmentée plutôt que remplacée
2. Le rôle du développeur se transforme, sans disparaître
- Plutôt que de faire disparaître les métiers de la programmation, l’IA est en train de faire évoluer le rôle du développeur, du codeur pur vers celui de gestionnaire d’un processus de développement assisté par l’IA
- Les experts prévoient une scission des profils entre ingénieurs produit capables d’exploiter l’IA et architectes avancés garants de la qualité et de la sécurité des systèmes
- Cette transformation implique le besoin de nouvelles compétences : bonne utilisation de l’IA, résolution stratégique de problèmes et capacités de conception de haut niveau
- Avec la pénurie d’ingénieurs logiciels et l’efficacité prouvée des outils d’IA pour aider les développeurs juniors, ces outils ouvrent aussi de nouvelles opportunités de progression pour les profils expérimentés
- Comme lors de l’apparition passée de nouveaux outils de développement et de technologies d’abstraction, cette évolution suggère que la créativité humaine reste indispensable
3. Le dilemme productivité-qualité du « vibe coding »
- Le phénomène du “vibe coding” met en lumière à la fois les gains de productivité du code généré par l’IA et ses limites en matière de qualité et de sécurité
- Les outils d’IA favorisent le prototypage rapide et le développement itératif, mais renforcent aussi les inquiétudes liées à la baisse de qualité du code et aux risques de sécurité
- Des cas réels ont déjà montré l’apparition de failles de sécurité dues à l’usage non vérifié de code généré par l’IA
- Dans des structures comme les startups fondées par des entrepreneurs non techniques, l’abus de code généré par l’IA peut accumuler de la dette technique et freiner la croissance à long terme
- L’expérience des grandes entreprises IT montre que l’équilibre entre automatisation et contrôle qualité rigoureux est au cœur d’une adoption réussie de l’IA, et que cette leçon est tout aussi importante pour les startups
1 commentaires
Avis sur Hacker News
Je me demande vraiment pourquoi plus personne ne parle de la complexité essentielle des systèmes
Dans No Silver Bullet de Fred Brooks, il est expliqué que la vraie difficulté de l’ingénierie logicielle vient de la compréhension, de la clarification et de la modélisation du problème fondamental. La complexité accidentelle, comme les limites des outils, est secondaire
Ces derniers temps, on entend beaucoup dire que des agents IA vont créer une base de code entière à partir de prompts en langage naturel, à la place des ingénieurs. Mais cette hypothèse repose sur l’illusion que le problème de la spécification a déjà été résolu. En réalité, transformer une idée floue en un système détaillé et robuste reste le rôle central de l’ingénieur
Si quelqu’un fournit les spécifications détaillées et travaille de façon itérative avec l’IA pour produire un logiciel, alors on ne fait en pratique qu’éliminer la complexité accidentelle grâce à l’IA. C’est comparable au passage de l’assembleur aux langages de haut niveau. Cela ne remplace pas les ingénieurs, cela augmente seulement leur productivité. Cela réduit le coût des tâches répétitives et permet aussi d’élargir l’impact de leur travail
Si un agent peut produire un produit à partir de simples prompts, c’est que quelqu’un a déjà défini le système clairement en amont. Et si l’on utilise l’IA uniquement pour cloner des produits existants, alors on n’est plus dans la résolution de problèmes techniques mais dans la distribution ou la concurrence par les coûts ; ce n’est pas une innovation d’ingénierie, mais une innovation business.
Je me demande si je rate quelque chose
Le point clé, c’est que le travail de spécification était déjà négligé bien avant l’arrivée de l’IA
Les parties prenantes (clients, managers) ont toujours eu tendance à demander du code “au feeling”. Elles donnaient une explication approximative, puis quelqu’un produisait miraculeusement une solution censée y correspondre. Personne ne savait vraiment si la solution fonctionnait complètement. Souvent, tant que ça semblait marcher à peu près, on passait à autre chose
Dans la plupart des cas, c’est le programmeur qui précisait le besoin à partir de sa connaissance métier (par exemple parce qu’il sait instinctivement à quoi ressemble une bonne page de soumission de formulaire)
Maintenant, c’est simplement l’IA qui remplace l’interlocuteur, mais reste à voir si cette façon de faire peut continuer telle quelle
La distinction entre complexité essentielle et accidentelle est une intuition extrêmement importante pour réfléchir jusqu’où l’IA peut prendre en charge le développement logiciel
Beaucoup de développeurs ne savent pas forcément expliquer pourquoi ils ne seront pas remplacés par l’IA, mais c’est ce point qu’ils ressentent instinctivement
En pratique, j’ai moi-même essayé de faire résoudre par des agents comme Claude des problèmes dans de très grosses bases de code, complexes, avec beaucoup de logique métier externe. Mais l’IA n’a pas l’intuition nécessaire des exigences business ou du contexte, donc elle ne sait pas faire des changements réellement métier. Elle peut aider sur des changements de code simples avec un contexte limité. En bref, elle ne traite que la complexité accidentelle, et montre ses limites dès qu’il s’agit du vrai rôle du développeur, à savoir traduire des besoins réels en système
J’ajouterais qu’en réalité, beaucoup de développeurs résolvent peut-être davantage des problèmes de distribution ou de marché que des problèmes techniques. Remplacer les juniors par l’IA me semble encore risqué. Le plus gros problème, c’est que l’IA ne sait pas vraiment s’auto-corriger. Malgré tout, on continuera à voir apparaître des entreprises centrées sur l’IA essayant de réduire les coûts des business existants. Que ce changement soit bon ou mauvais importe peu pour ceux qui se feront évincer du marché du travail
Il y a une réponse à la question « est-ce que je rate quelque chose ? »
Il existe en réalité énormément de développeurs qui ne savent pas utiliser les logiciels. Ceux-là seront facilement remplacés par l’IA
Dans une ancienne phase de ma carrière, je travaillais en JavaScript, et les seules personnes vraiment impressionnantes étaient celles qui développaient par passion sur leur temps libre. En entreprise, la plupart avaient déjà du mal à afficher du texte à l’écran. Ce n’est pas une blague
Beaucoup se lancent dans d’énormes frameworks, mais au final ils ne font que du copier-coller jusqu’à ce que quelque chose fonctionne à peu près. Ils font semblant de gérer de la complexité avancée, alors que la plupart du temps ce sont des tâches inutiles ou de la démonstration de code
Ils ont très peu de capacité à créer des applications originales, à écrire de la documentation ou à mesurer l’utilisabilité réelle
Comment corriger ça ? En introduisant des standards élevés comparables à l’examen du barreau pour les juristes, en écartant sans hésiter ceux qui ne franchissent pas le niveau requis, et en ne recrutant qu’en juniors ou apprentis, afin que la génération suivante de développeurs puisse réellement progresser
La réponse simple à ce qui est « raté dans l’analyse », c’est que personne dans l’industrie n’a lu No Silver Bullet
Ceux qui écrivent sur la dette technique ou l’architecture des systèmes ne sont pas, en réalité, les décideurs qui pilotent équipes et business, et ce genre de livres reste optionnel pour les ingénieurs
Les personnes qui mènent le discours sur le remplacement du code par l’IA sont souvent incapables de distinguer la création d’un MVP de l’extension d’une base de code sur dix ans et de l’amélioration d’un legacy
Par exemple, un manager a déjà proposé de répartir trois projets sur une même journée à raison de 33 % du temps chacun — une suggestion typiquement absurde. L’allocation des personnes et la structuration du temps devraient relever du management, mais au final ce sont les ingénieurs qui compensent
Maintenant, ce sont ces mêmes managers qui proposent de « laisser l’IA régler toute la dette technique et les tests », et quand ça ne marche pas, ce sont encore les ingénieurs qui doivent expliquer pourquoi
Tout ce discours sur la complexité n’est au fond qu’une répétition des problèmes de mauvaise gestion. La plupart des ingénieurs expérimentés ne croient déjà pas que leur travail sera remplacé par un prompt simple
Le vrai sujet dont on devrait parler, c’est : « l’ingénierie logicielle souffre d’un sérieux problème de management, et l’IA le rend encore plus visible »
Beaucoup de non-développeurs ou d’étudiants ont l’impression que le développement logiciel consiste surtout à apprendre à manier des outils complexes, et sont donc séduits par la promesse selon laquelle « n’importe qui peut créer du logiciel s’il rédige bien les spécifications » (en oubliant soigneusement que la capacité à bien spécifier est elle-même extrêmement difficile et nécessite des techniques de support)
Le no-code fonctionnait déjà sur ce même ressort, et en pratique les outils no-code sont limités ; plus ils sont puissants, plus ils demandent un apprentissage complexe et spécialisé
La thèse du remplacement des SWE par les LLM n’est au fond qu’une nouvelle version de l’idée selon laquelle « au lieu d’apprendre le système, il suffit d’écrire un prompt en langage naturel et le modèle utilisera les outils à votre place »
Vu sous cet angle, ce qu’on appelle aujourd’hui le vibe coding est en quelque sorte l’aboutissement extrême de cet objectif (même si cela a des faiblesses concrètes, notamment en matière de maintenabilité)
À mon avis, l’une des raisons pour lesquelles certains managers veulent se débarrasser des SWE, c’est qu’ils ne savent pas bien communiquer avec eux
Avec les LLM, ils ont l’impression de pouvoir dialoguer avec la machine sans passer par les « nerds », et donc de résoudre ce problème
Les langages de programmation sont un médium adapté à la spécification précise du programme que l’on veut obtenir. Le langage naturel n’atteindra jamais ce niveau de clarté
Il est donc normal de relire et d’éditer ce que produit l’IA. Selon les cas, il peut même être plus simple de corriger directement soi-même que d’expliquer les changements à faire
Je me demande si les études indépendantes montrant que Copilot augmente le taux d’erreur n’ont pas naturellement contribué à diffuser une attitude plus prudente
Les vendeurs d’IA affirment souvent que les auteurs humains ne seront bientôt plus nécessaires
Les Transformers peuvent être appliqués à beaucoup de tâches : tests automatisés, extension de spécifications, accélération de nouveaux projets, exploration d’API inconnues, construction de premières fonctionnalités, revue de code, etc.
Même si l’on admet que le code est le bon support de la spécification, les Transformers jouent le rôle d’interface automatisée entre le langage naturel et ce médium qu’est le code
Grâce à l’ampleur de leurs connaissances, les Transformers récents n’ont pas de vrai problème à générer du code
De la même façon que les humains recherchent l’automatisation dans la programmation, les Transformers constituent un bond majeur
À un moment dans le futur, le remplacement des programmeurs par l’IA pourrait devenir une réalité (comme les métiers à tisser automatiques, l’imprimerie ou les calculateurs électroniques ont remplacé certains travaux humains)
Cela dit, cela n’arrivera peut-être pas tout de suite, ni même dans les dix prochaines années, et il reste encore des défis à relever : hallucinations, précision, outillage, infrastructure, etc.
L’existence ou non d’emplois de programmation pourra varier selon le domaine, le niveau et les attentes de rémunération
Il est important de prendre les outils d’IA au sérieux et de s’adapter. Sinon, on risque d’être distancé, comme lors de l’arrivée de l’informatique personnelle ou d’Internet
Je pense que la pseudo-créativité de l’IA a des limites
Si tous les résultats de l’entraînement des LLM ne font que reboucler en entrée d’autres LLM, l’espace des idées nouvelles ne s’élargira jamais
Les humains, eux, continuent à produire de la créativité en dehors de cet espace
Peut-être qu’un jour les LLM franchiront cette barrière, mais pour l’instant ce n’est guère différent de l’image du singe à la machine à écrire
D’après mon expérience, les LLM sont les plus efficaces lorsqu’on les utilise comme outil de scaffolding
Je leur déverse la fonctionnalité que je veux créer, de manière brute, puis je leur demande de générer le modèle et le contrôleur de base nécessaires
Il ne me reste alors plus qu’à me concentrer sur la vue et sur la vraie logique métier, ce qui clarifie bien la répartition du travail
Quand les langages de haut niveau sont apparus, il me semble qu’au tout début on leur faisait des critiques comparables à celles adressées aujourd’hui aux LLM ou au code en langage naturel, du type « ce n’est pas assez précis parce qu’on ne contrôle pas directement la mémoire »
Le problème n’est pas que le langage naturel soit incapable de précision, mais que la plupart des gens expriment leurs demandes de manière imprécise, ou qu’ils savent ce qu’ils veulent sans réussir à décrire correctement ce que l’ordinateur doit faire
Résultat : soit l’ingénieur doit énormément deviner en traduisant le besoin métier, soit le LLM essaie de jouer ce rôle tout en comprenant encore moins de contexte
Le meilleur usage de l’IA, pour moi, c’est de maintenir mon état de flow sans me bloquer sur une API que je découvre ou sur une fonctionnalité pénible que je n’ai pas envie de faire
L’IA peut appliquer rapidement et efficacement des motifs communs à l’ensemble du code, mais fondamentalement « elle ne sait pas elle-même ce qu’elle fait »
Pour partager une expérience récente, j’ai voulu faire refactorer par un LLM du code lié au calcul de taille et au positionnement d’une popup
Un endroit utilisait
if, un autreswitch, et le LLM n’a montré aucune souplesse face à cette différence ; même après une explication claire, il a uniformisé les deux enifou les deux enswitchLes LLM ont tendance à prolonger les motifs des tokens précédents
Ici ce n’était pas très grave, mais dans des situations un peu plus complexes, ils ignorent facilement les subtilités et produisent du code plausible en surface
En revanche, si on découpe en petites unités avec des consignes claires, le LLM peut être très efficace. Par exemple, une instruction du type « stocke la taille dans m_StateStorage puis applique-la à l’étape de rendu » est exécutée facilement
Surtout avec des modèles comme Cerebras, capables de traiter rapidement plusieurs kilo-octets de code, c’est bien plus rapide que de taper directement moi-même le code correspondant à ma pensée
Ce qu’on évalue aujourd’hui, ce n’est finalement que la performance actuelle des modèles Transformer
Le secteur évolue tellement vite que les limites d’aujourd’hui peuvent devenir insignifiantes dans un mois
Même le terme LLM est, à strictement parler, flou. Les Transformers récents sont multimodaux et traitent plusieurs formes de données, pas seulement du texte
Donc, si l’on veut critiquer quelque chose, il faut viser un modèle, un outil ou un paradigme précis pour que la discussion soit utile
À propos du « manque d’ingénieurs logiciels » et des études affirmant que « l’IA aide particulièrement les développeurs juniors »
Dans la réalité que je vis, le marché de l’emploi tech est au plus bas, et l’IA désavantage au contraire les juniors en leur retirant l’expérience qu’ils devraient justement acquérir
J’ai récemment eu une expérience amusante avec Claude. Dans Zed, je lui ai demandé : « corrige l’erreur à la ligne 71 », et il est allé changer un formatage inutile à la ligne 91
J’avais l’impression de jouer au téléphone arabe avec un LLM
Pour un correctif aussi simple, le faire moi-même allait plus vite. Cette expérience m’a encore conforté dans l’idée que « les LLM ne pensent pas vraiment »
Les LLM sont très mauvais avec les numéros de ligne
J’en ai tiré la leçon suivante : « les LLM ne savent pas compter les numéros de ligne »
La prochaine fois, il vaudra mieux dire « corrige l’erreur dans la fonction XYZ » ou coller directement la ligne concernée
Et bien sûr, un LLM ne pense pas. Ce n’est qu’une énorme équation
On dirait qu’il y a pas mal de gens dans ce fil qui codent avec l’IA pour la première fois
Cela peut aussi être une erreur d’opérateur
Il faut donner au LLM un contexte correct. Les numéros de ligne sont un mauvais contexte
Pour moi, le rôle d’un ingénieur logiciel consiste à transformer des exigences en logiciel
Le logiciel, ce n’est pas seulement du code, et les exigences ne sont pas non plus fournies uniquement en langage naturel
À l’heure actuelle, même en travaillant avec l’IA, je ne vais pas plus vite qu’elle ne m’aide, sauf pour les tâches simples ou les petits logiciels
Aujourd’hui, l’IA me paraît du niveau d’un développeur junior/intermédiaire
Sur les deux dernières années, je n’ai pas constaté d’amélioration radicale de l’IA dans mon expérience concrète
La plupart des exigences ne sont jamais documentées clairement
Il y a rarement quelqu’un qui sait vraiment ce qu’est la logique métier
Résultat, l’ingénieur logiciel doit souvent aller poser lui-même les questions
Cela demande aussi de l’expérience et de l’intuition pour réfléchir à la direction d’évolution du logiciel et à la façon de concevoir l’architecture pour préserver sa capacité d’extension
J’ai du mal à imaginer qu’un LLM puisse assumer ne serait-ce qu’une partie de ce rôle
Je n’ai jamais vu un seul projet logiciel avec des exigences clairement définies
La moitié du projet consiste à comprendre ce que les gens veulent réellement
Les LLM n’atteignent même pas encore le niveau junior
Si jamais l’IA actuelle était au niveau des développeurs intermédiaires de votre entreprise, alors c’est surtout un problème de recrutement dans votre société
L’un des plus grands atouts des ordinateurs, c’est une automatisation fiable et reproductible
Les langages formels comme les langages de programmation permettent de communiquer clairement, sans ambiguïté, les automatisations souhaitées
Le langage naturel n’offre pas ce niveau de précision
La véritable source de vérité d’un programme reste donc le code
Si l’on veut contrôler précisément le comportement d’un programme, la compétence la plus importante reste donc la capacité à comprendre et modifier le code
Le mot « manuel » a une connotation négative
Ce que l’article voulait probablement dire, c’est que « le codage humain reste essentiel »
Je ne sais pas avec certitude si le CEO de GitHub a réellement employé le mot « manual ». Ce serait bien d’avoir une source plus neutre ou plus précise sur la formulation exacte
Il n’est pas souhaitable de rabaisser le codage humain en le qualifiant de « manual ». Les développeurs humains utilisent eux aussi toutes sortes d’outils d’automatisation, pas seulement l’IA
Cela peut être presque aussi négatif que de parler de « pensée manuelle »
J’apprends seulement maintenant la connotation négative de « manual »
Je me demande si les gens ont vraiment aujourd’hui une telle aversion pour le travail manuel
Je me demande quelle différence il y a entre « manual coding » et « human coding »
« Ne dépendre que d’agents IA peut être inefficace »
Par exemple, il est souvent bien plus rapide de modifier directement le code que de décrire longuement en langage naturel un changement simple
Par conséquent, une interaction active avec les agents IA deviendra probablement le workflow optimal
Il m’arrive souvent de commencer à formuler un changement en langage naturel, puis, avant même d’avoir fini de l’écrire, de déjà voir dans ma tête comment faire directement la modification nécessaire
Plus un changement demande de contexte, plus j’ai l’impression d’aller plus vite que l’agent moi-même
Je me demande jusqu’où une interaction active reste acceptable
J’ai récemment rejoint une startup spécialisée dans l’outillage pour agents, et on discute beaucoup de ce sujet en interne
Dire en permanence à l’agent « franchement, là tu t’en sors mal ! » me paraît acceptable, mais certains aspects risquent malgré tout de devenir fatigants
Je serais curieux d’avoir d’autres avis, des idées de workflow ou des retours d’expérience
L’IA n’est pas encore à la hauteur des attentes
Par exemple, je souffre souvent de références erronées ou de spécifications incorrectes. Cela semble venir du fait que l’IA a été entraînée sur des données obsolètes et ne sait pas se mettre à jour en temps réel
Les solutions actuelles à base de LLM et de GI essaient trop souvent de résoudre d’un coup toutes les étapes d’un problème en n étapes, ce qui réduit leur utilité
Si elles savaient déjà bien traiter l’étape 1 jusqu’à l’étape i, ce serait beaucoup plus utile pour les humains
Je n’ai pas encore vu de solution d’IA entièrement modulaire correspondant à ce que je veux (par exemple : résoudre le problème x en se basant uniquement sur les ressources a, b, c et sur mon style GitHub)
Et j’espère voir émerger une IA de codage capable d’explorer le problème de façon séquentielle, en posant davantage de questions au fil du processus et en dialoguant en cours de route
Je trouve intéressant qu’un CEO exprime un avis un peu différent sur l’IA et le code
En général, les CEO ou les investisseurs prédisent une réduction du rôle des développeurs en disant que « plus de 30 % du code total est écrit par l’IA », alors qu’en pratique il s’agit surtout des mêmes développeurs qui utilisent des outils pour écrire plus vite
Il souligne à juste titre que l’écriture du code elle-même ne représente qu’une partie du travail de développement logiciel