- Les LLM, outils de programmation assistée par l’IA, occupent déjà une place indispensable dans le développement logiciel
- Beaucoup de personnes autour de l’auteur pensent encore que l’IA n’est qu’un effet de mode passager, mais il insiste sur le fait qu’il est déjà temps de changer d’avis dans le développement
- Les agents de codage automatisent les tâches répétitives et fastidieuses, permettant aux développeurs de se concentrer sur un travail plus significatif
- Il existe des controverses sur la qualité, la propriété et le support outillage du code généré par l’IA, mais elles ne font le plus souvent que reproduire des problèmes déjà présents dans les environnements de développement existants
- Une attitude trop réservée face à l’adoption des LLM n’est pas appropriée, et tout indique que des transformations technologiques encore plus importantes approchent
Introduction : l’IA, la programmation et le scepticisme
- Ces derniers temps, les dirigeants des entreprises tech ont tendance à imposer l’adoption d’outils LLM, mais c’est une mauvaise stratégie
- Parmi les développeurs brillants que connaît l’auteur, certains considèrent l’IA comme une mode passagère comparable aux NFT et ne la prennent pas vraiment au sérieux
- Pourtant, dans les faits, l’adoption des LLM a déjà provoqué de grands changements dans le développement
- Le texte se concentre sur la signification des LLM dans le développement logiciel et n’aborde pas d’autres domaines comme l’art, la musique ou l’écriture
Les agents LLM et leurs usages modernes
Se mettre à niveau : les LLM d’hier vs. les agents d’aujourd’hui
- On assiste à la diffusion d’un environnement d’agents LLM plus évolué, très différent de l’époque où l’on utilisait simplement ChatGPT ou Copilot il y a 6 mois à 2 ans
- Aujourd’hui, les développeurs laissent les agents explorer et modifier librement la base de code, ce qui permet d’automatiser la création de fichiers, la compilation, les tests et les itérations
- Cela inclut la fourniture de l’arborescence du code et de code issu de sources externes, l’extraction d’informations via des outils Unix, les interactions avec Git et l’exécution de divers outils de développement
- La logique effective de manipulation du code reste elle-même un code système simple
- Se contenter de copier-coller du code depuis ChatGPT, comme auparavant, revient à passer à côté du changement de fond
Les effets positifs des LLM
- Dans la plupart des projets, les portions de code simples et répétitives peuvent être facilement générées par les LLM
- Les LLM savent récupérer des informations sans avoir à faire de recherche ou relire la documentation, et ils ne souffrent pas de l’inefficacité liée à la fatigue
- Quand il est difficile de démarrer une fonctionnalité à cause de la barrière d’entrée d’un nouveau langage ou environnement, les LLM peuvent fortement réduire cette difficulté
- Le refactoring de tests de maintenance, la gestion des dépendances et autres corvées du développement peuvent être pris en charge par les LLM
- Les développeurs peuvent ainsi consacrer davantage d’énergie aux aspects importants et créatifs
Réponse à l’argument : « on ne comprend pas le code généré par les LLM »
- Il est normal de lire et d’ajuster au style de l’équipe le code que l’on fusionne
- Le code produit par les LLM est prévisible sur le plan « algorithmique », et il est possible d’en comprendre et d’en vérifier les résultats
- Si l’on manque de capacité pour relire du code répétitif, il est probable qu’on ait aussi du mal à absorber le code confus écrit par des développeurs humains
Point de vue sur le « problème des hallucinations de l’IA »
- Les agents LLM exécutent aussi le lint, la compilation et les tests, ce qui corrige les erreurs factuelles et améliore la fiabilité
- Dans la plupart des environnements, le problème des hallucinations est déjà en grande partie résolu
- Pour les utiliser efficacement, il faut moins une surveillance minutieuse qu’une confiance dans le processus d’automatisation
Critique : « le code IA est de faible niveau »
- Le coût d’un service LLM est inférieur au salaire d’un stagiaire (par exemple : Cursor.ai à 20 $/mois)
- Le rôle des développeurs seniors est d’augmenter la productivité d’un stagiaire peu performant ou du code produit par un LLM
- La capacité à exploiter des agents de codage, le tooling et la conception de prompts constituent aussi un nouveau domaine de compétence technique
- Il existe une confusion autour de la question de qui prend en charge quoi, mais fondamentalement, les développeurs restent responsables de l’orientation, de la validation et du jugement
La controverse : « l’IA est mauvaise en Rust »
- Les limites de compatibilité avec certains langages ou outils sont des défis propres à des écosystèmes spécifiques
- Dans des langages compatibles avec les LLM comme Go, l’usage de l’IA est très élevé
- Les difficultés avec Rust ne constituent pas une limite générale des LLM, et il faut des stratégies adaptées selon les langages
L’artisanat du code et la programmation en conditions réelles
- Le développement logiciel a pour objectif de résoudre des problèmes concrets
- Une obsession inutile pour la qualité du code relève du « yak-shaving » et nuit à l’efficacité dans le travail réel
- Les tâches répétitives et pénibles doivent être déléguées aux LLM, afin que les développeurs concentrent leurs efforts sur les zones de création de valeur
Accepter la banalité du code IA (« mediocrity »)
- Dans la plupart des cas, il n’y a pas de problème à ce que le code soit simplement ordinaire
- Il faut augmenter la qualité là où c’est important, et transformer ailleurs les réductions de coût permises par les LLM en avantage
- Le code LLM est plus sûr sur les parties répétitives, et dans le domaine algorithmique, il peut parfois avoir une approche plus large que celle des humains
Avis sur l’idée selon laquelle « l’AGI est encore loin »
- L’auteur ne s’intéresse pas vraiment au débat sur l’AGI ; seul compte le fait que cela fonctionne réellement
- Les performances concrètes et les gains de productivité sont les critères de jugement immédiats
La controverse sur le remplacement des emplois
- Comme l’adoption de l’open source, les LLM sont une technologie qui entraîne la transformation et parfois la disparition de certains métiers
- Les développeurs logiciels doivent eux aussi prendre conscience qu’ils sont, comme dans d’autres secteurs, des cibles de l’automatisation
- Il reste incertain de savoir si ce changement sera au final bénéfique ou nuisible, mais le changement lui-même est inévitable
Les questions de plagiat et de droit d’auteur
- L’IA représente une menace majeure pour les arts visuels
- En pratique, les LLM peuvent effectivement produire en masse des résultats répondant à une qualité de niveau industriel
- Il est difficile pour les développeurs logiciels de faire de la question du plagiat un véritable argument
- Historiquement, les développeurs ont eux aussi été peu sensibles au droit d’auteur, préférant le partage et la reproduction à la protection stricte de la propriété intellectuelle
- Les polémiques sur la réutilisation de fragments de code ne sont au fond qu’une justification opportuniste
Les usages récents des LLM et la vitesse du changement
- L’usage d’agents asynchrones fondés sur les LLM et le travail en parallèle améliorent fortement la productivité
- Même d’excellents développeurs utilisent les LLM pour relire et compléter du code, et constatent une utilité concrète dans un environnement non statique
- Les domaines liés à la confiance, comme l’accès à des infrastructures critiques, doivent toutefois continuer à être traités avec prudence
Conclusion : changement technologique et dépassement du scepticisme
- Contrairement aux sceptiques traditionnels de l’IA, l’auteur, tout en gardant une position prudente, ressent concrètement le changement en cours
- Le moment est venu pour les développeurs logiciels de dépasser les objections dépassées et d’accepter les transformations réelles
- Les LLM et la programmation assistée par l’IA devraient entraîner un changement structurel profond de l’industrie, comme l’ont fait le smartphone et Internet
4 commentaires
C’est clairement utile quand il faut écrire un petit script simple à usage unique. Cela fait gagner énormément de temps.
C’est aussi utile lorsqu’il faut résoudre un problème sans pouvoir y investir beaucoup de temps. En revanche, même si cela reste globalement utile pour l’instant, cela ne remplace pas complètement une personne. Je ne sais pas jusqu’où cela progressera par la suite, mais pour le moment, en tant qu’assistant, c’est à peu près utilisable.
Que l’on soit adepte de l’IA ou sceptique, dès qu’on tombe dans l’extrême, ça me donne envie de prendre mes distances.
Chaque fois que je les vois s’époumoner à crier que « la singularité arrive », ça me fatigue vraiment.
Avis Hacker News
Si vous avez essayé d’écrire du code avec des LLM il y a 6 mois et que ça a échoué, cela signifie simplement que vous ne faisiez pas comme la plupart des développeurs qui utilisent sérieusement les LLM. Mais pour ma part, j’ai toujours été sceptique face à ceux qui affirment que cette technologie est révolutionnaire. Il y a 6 mois déjà, on disait que si vous n’utilisiez pas les derniers LLM, vous étiez dépassé et vous ne saviez pas les employer correctement ; pourtant, aujourd’hui, tout le monde semble admettre que les anciens LLM n’étaient pas terribles. On dirait le phénomène du « garçon qui criait à l’IA » : toujours les mêmes excuses. Cette fois encore, on nous dit que la productivité explose, mais sur quoi se fonde l’idée que cette fois, c’est vrai ? Je parie que dans 6 mois on dira encore que les produits LLM d’aujourd’hui étaient médiocres.
Une courbe exponentielle a la même allure à chaque instant. Pendant longtemps, les ordinateurs se sont énormément améliorés chaque année, non pas parce que l’ordinateur acheté l’année précédente était une poubelle, mais parce que la technologie progressait réellement à toute vitesse. L’idée ici, c’est que cette fatigue face à une amélioration continue est justement le résultat d’un progrès vraiment révolutionnaire.
Si l’on demandait de l’aide à un être humain tous les 6 mois de 0 à 30 ans, à quel moment serait-on impressionné ? Cela dépend de la personne et du type de tâche, mais avec le temps, de plus en plus de gens finiraient forcément par admirer ses capacités. L’évolution des LLM ressemble un peu à celle d’un enfant qu’on voit grandir. Moi aussi, je n’utilisais pas les LLM avant, mais depuis o3 et Gemini 2.5 Pro, j’en fais constamment usage. Si vous avez essayé les tout derniers modèles et que vous n’êtes toujours pas impressionné, je suis convaincu que vous le serez dans les 3 ans.
tptacek ne tenait pas ce discours il y a 6 mois. Les LLM s’améliorent avec le temps et, parfois, ils franchissent même des blocages qu’ils n’arrivaient pas à dépasser auparavant. Ces 6 derniers mois, c’est justement le moment où « l’écriture de code basée sur des agents » a commencé à fonctionner pour de vrai. Adopter l’état d’esprit « comme on dit tous les 6 mois que ça s’est amélioré, je n’y prête plus attention » risque de nuire à votre capacité à évaluer correctement la technologie.
Selon un autre avis, le cœur du problème est le « point d’inflexion ». Certains se contentent de coller du code dans ChatGPT et se disent déçus, tandis que d’autres obtiennent de bien meilleurs résultats avec des agents capables de voir tout le contexte du code. Au final, ce n’est pas seulement le LLM qui compte, mais aussi la différence de workflow.
J’aime bien l’argument de Thomas, mais je pense qu’il contient aussi une erreur fondamentale que beaucoup de gens commettent. Les bons programmeurs doivent accumuler une longue expérience pour bien utiliser les LLM, et Thomas a lui aussi acquis cette expertise avec le temps. Mais nous sommes peut-être la dernière génération à avoir grandi sans assistance des LLM. Je me demande comment un débutant qui sort tout juste de l’école peut dépasser le « vibe coding » et développer de vraies compétences. Avant, on progressait en construisant les choses soi-même ; aujourd’hui, on risque de confier entièrement la conception globale et l’assemblage à des robots, sans jamais apprendre comment fonctionnent réellement les outils ni les matériaux. On finira par n’estimer la charge d’un toit qu’au « feeling ».
Un autre point de vue est que l’intérêt des agents IA apparaît clairement quand un expert est capable de lire, comprendre et intégrer le code produit par un LLM dans une base existante. Mais si tout le monde code avec l’IA, comment formera-t-on de véritables « éditeurs » capables de lire un code de plus en plus complexe, d’identifier les risques, de savoir quoi tester et comment, et de garder en tête la structure globale d’une codebase ? Aujourd’hui, ces compétences s’acquièrent en écrivant soi-même du code pendant longtemps. Si les débutants externalisent leur réflexion, ils n’auront pas l’occasion de développer ces capacités. D’où viendront alors les personnes expérimentées ? En tant qu’enseignant, je trouve amer de voir que les devoirs et les exercices passent déjà sans réflexion grâce aux LLM. Il nous faudra sans doute inventer une nouvelle manière de faire progresser ces compétences, mais je n’en vois pas encore la forme, et je me demande vraiment comment les débutants deviendront des experts dans un tel monde.
Réponse classique : si tout le monde n’utilise plus que des calculatrices, comment apprend-on encore les maths ? Il faudrait faire pratiquer suffisamment à la main aux étudiants et leur faire assimiler les bases avant d’introduire les LLM comme on introduit une calculatrice.
Cela rappelle la nouvelle d’Isaac Asimov « Profession ». La plupart des gens y reçoivent directement leurs compétences et leur métier d’un ordinateur ; ils accomplissent donc correctement leur travail, mais ne développent ni innovation ni créativité. Seule une minorité, incompatible avec ce système, apprend réellement, et devient le seul groupe capable de faire progresser les arts.
Dans mon expérience, les LLM ressemblent davantage à un pair programmer ; pour un débutant, c’est presque comme un ingénieur senior. Ils ne se contentent pas de produire du code : ils excellent aussi comme tuteurs capables d’expliquer les principes et les processus. Pour un senior, ils apportent divers avantages : revue de code, brainstorming d’idées, traitement du boilerplate, etc. Du point de vue d’un expert, on peut se concentrer sur les 10 % de tâches difficiles et déléguer le reste au LLM, ce qui fait gagner du temps. Si un débutant se contente de recopier du code sans curiosité ni intérêt, c’est son problème ; pour quelqu’un qui veut vraiment apprendre, les LLM sont une ressource pédagogique de premier ordre. De ce point de vue, c’est peut-être la meilleure époque pour être débutant.
Tout ce fil ressemble aux étapes psychologiques classiques : « le problème n’existe pas » – « bon, il existe, mais ce n’est pas grave » – « ah oui, il existe vraiment, adaptons-nous ». J’ai l’impression qu’on touche là à l’un des vrais problèmes centraux.
Je suis moi aussi d’accord avec l’idée qu’un débutant qui s’en remet entièrement aux LLM pour penser progressera difficilement. Cela dit, j’apprends constamment grâce aux LLM. Je leur soumets des problèmes sur des API que je connais vaguement, puis je lis les résultats pour assimiler les concepts ; en général, je modifie et refactorise ensuite le code. Il y a quelques jours encore, je voulais comprendre le fonctionnement interne de signaux, et le LLM m’a donné des exemples que nous avons ensuite analysés ensemble. Avec un minimum de curiosité, cela peut devenir un tuteur incroyable. Un junior ne doit pas forcément faire seulement du « vibe coding » : il doit adopter une attitude active d’apprentissage. Sinon, c’est sa responsabilité ; et dans une réalité désormais irréversible, il existe largement de quoi progresser à condition d’être curieux.
J’ai récemment essayé des choses comme l’agent Claude 4 sur différents cas : une grosse codebase en C (nouvelles fonctionnalités, corrections de bugs), un petit projet Rust, un petit front-end, un nouveau front-end avec une documentation d’API de base, etc. Dans tous les cas, ce fut un échec complet. Il produit de mauvais diffs, passe de mauvais arguments aux outils, échoue sur des fonctions élémentaires, refactorise de travers sur des centaines de lignes et laisse des refactors inachevés qui mettent la codebase sens dessus dessous. Même sur des frameworks JS riches en données comme Svelte ou solidJS, le résultat reste médiocre. Je ne vois pas quelle est la vraie force pratique de ces agents que tout le monde encense ; cela ressemble surtout à de l’exagération marketing.
Quelqu’un demande comment les prompts ont été formulés. En général, si l’on découpe une fonctionnalité en petites tâches plus précises à soumettre au LLM, cela fonctionne beaucoup mieux. Les tâches individuelles (dans une plage de 10 à 200 lignes) passent bien, mais au-delà, il faut des suivis et les déceptions s’enchaînent. À ce stade, leur autonomie ressemble à celle d’un stagiaire intelligent mais sans expérience. La conception d’ensemble et la planification des tâches complexes restent encore du ressort de l’humain.
Hypothèse : même ceux qui font la promotion des agents ne produisent en réalité que du code spaghetti, mais s’en moquent tant que leur productivité augmente. Il existe peu de cas concrets de réussite qui détaillent précisément les outils et les méthodes employés ; pourtant, l’IA pourrait aussi documenter cela, mais elle ne le fait pas.
Beaucoup de billets sur les agents ressemblent à des publireportages. Il y a trop d’argent dans le marché de l’IA, et cela inspire encore moins confiance quand on repense à d’anciens excès marketing. J’ai moi-même essayé de nombreux produits d’agents et j’y ai vu peu d’améliorations concrètes. Hacker News regorge déjà de pessimistes qui craignent l’IA, si bien que lorsqu’un débat devient vif, on finit même par créer une ambiance où le problème viendrait de l’utilisateur. Un intervenant affirme qu’« il faut vraiment dépenser 1000 dollars en IA pour comprendre », ce qui sent fortement la pub.
Si l’on limite les modifications du LLM à de petits morceaux de code, un fichier unique ou des unités de moins de 50 lignes, cela devient plus facile à gérer.
En tant que personne qui apprend à coder depuis les années 90, je trouve déjà merveilleux le simple fait de pouvoir donner à un ordinateur une entrée floue et ambiguë, et d’obtenir malgré tout un résultat utile. Le fait de recevoir une sortie claire et exploitable à partir d’une ambiguïté de niveau humain donne l’impression d’être dans de la science-fiction.
À l’inverse, il arrive souvent que même lorsqu’on donne une entrée très claire, l’ordinateur l’interprète de manière ambiguë pour la transformer en un problème plus facile à résoudre pour lui.
Pour ma part, je trouve justement que cette ambiguïté des LLM est très séduisante pour discuter avec de la documentation. Plus besoin de reformuler ses requêtes de recherche encore et encore pour trouver la bonne information ; au global, cela fait gagner beaucoup de temps.
Nous vivons vraiment une époque incroyable ; une ou deux fois par semaine, je suis encore frappé par l’étrangeté de tout cela.
J’étais fan de Star Trek: The Next Generation, et je me souviens avoir été fasciné en réfléchissant à la différence entre l’ordinateur de l’Enterprise et Data. L’ordinateur de l’Enterprise pouvait déjà organiser les connaissances, les résumer et exécuter des tâches, un peu comme l’IA actuelle, tandis que Data était présenté comme un robot doté d’une individualité. Le fait que Data ait des limites dans l’humour, l’art et les domaines émotionnels humains ressemble beaucoup à l’IA artistique d’aujourd’hui. Cela ravive aussi le souvenir des nuances de mise en place et de narration du début de la série.
Je suis entré dans ce secteur parce que j’aimais donner des instructions claires à une machine pour obtenir exactement ce que je voulais. Dijkstra insistait déjà autrefois sur l’ambiguïté du langage humain et sur l’importance des « langages formels » inventés pour la dépasser. Et voilà qu’en 2025, nous nous retrouvons dans une époque d’« ingénierie des prompts » et de « vibe coding » où l’on débat avec des ordinateurs pour corriger leur formulation : constat un peu amer. Recommandation de lecture : EWD667: The Humble Programmer.
Je me demande si ceux qui vantent les capacités illimitées de l’IA générative peuvent montrer des preuves concrètes. Si les GAI ou les agents étaient vraiment puissants, ils pourraient le démontrer en créant une entreprise avec de l’IA seule et en produisant rapidement un code d’une qualité exceptionnelle. Or, rien n’indique cela. Jusqu’ici, leur usage le plus utile semble surtout être la génération de texte ou d’art pouvant donner l’illusion de sens à des humains. D’après l’expérience de startups qui ont essayé de s’en servir au travail, cela n’a été utile qu’occasionnellement pour explorer une API ou retrouver commodément une information. Dans l’ensemble, c’était plutôt une perte de temps. On est arrivé au moment où, au lieu de simplement affirmer que « c’est bien », il faut montrer directement ce que l’IA a produit par elle-même.
Certains estiment qu’il s’agit surtout de points de vue divergents. Il a toujours existé un seuil entre les changements faisables (ceux dont l’effort se justifie par le gain) et les tâches qui restent indéfiniment dans le backlog ; les outils d’IA abaissent ce coût marginal et rendent davantage de travaux tentables. C’est pourquoi ceux qui parlent de « productivité multipliée par 5 » mettent en avant l’augmentation du volume de code traité, tandis que les sceptiques considèrent que la valeur business fondamentale a peu changé. Voir aussi le paradoxe de la productivité de l’IA.
Quelqu’un demande quel type de preuve concrète on veut voir : attend-on des capacités illimitées, ou simplement la preuve d’une utilité réaliste ? Tout le monde reconnaît en pratique qu’il ne s’agit pas d’un outil omnipotent, mais qu’il devient utile quand on en comprend bien les limites et les points forts. Comme exemple, il cite notamment l’historique de commits récent de cloudflare/workers-oauth-provider et demande si l’on ne peut pas au moins convenir que c’est « un peu utile ».
En réalité, tout le monde utilise déjà du code produit par des LLM. Certains partagent le fait que des PR générées avec l’aide de LLM partent en production depuis des mois. Si vous n’avez toujours pas trouvé d’utilité à ces outils, c’est peut-être aussi que vous n’avez pas encore appris à bien les exploiter.
Quand je vois des gens faire de la publicité au contraire pour expliquer que les LLM ne servent à rien, j’ai l’impression d’assister à un marketing qui fonctionne. Même des entreprises auxquelles je faisais confiance autrefois semblent aujourd’hui trop orientées vers la promotion de l’IA, ce qui me déçoit. S’il y a un vrai bénéfice, l’idée générale reste qu’il faut l’essayer soi-même.
Métaphore du « marchand de pioches pendant la ruée vers l’or » : au lieu de prouver l’efficacité réelle de l’outil, on se contente de convaincre les gens qu’il existe une mine d’or.
Critique de l’attitude qui consiste à ignorer les questions de licence du code sur GitHub. Certains développeurs disent qu’il ne faut pas se soucier du droit d’auteur, mais partir du principe que tous les programmeurs sont des criminels qui violent en permanence le copyright est une généralisation absurde. Beaucoup de développeurs, moi y compris, n’ont rien à voir avec le piratage de masse et s’efforcent au contraire de respecter l’esprit du copyleft et de l’open source. On peut considérer Sci-Hub comme un bien public tout en respectant le copyleft voulu par les développeurs concernés. Le droit d’auteur n’est pas une question simplement binaire, pour ou contre. C’est précisément le fait d’ignorer cette diversité et ce contexte, de tout mettre dans le même sac ou de justifier le mépris des licences, qui relève d’une paresse intellectuelle.
Les programmeurs comprennent souvent mal le droit, en particulier la common law à l’américaine. Les traditions juridiques reposent depuis longtemps sur l’idée qu’un humain devra interpréter raisonnablement les faits, et même si les outils d’IA sont conçus pour diluer ou esquiver la responsabilité, le droit finira tout de même par trouver quelqu’un à tenir pour responsable et à sanctionner. Une fois l’euphorie de l’IA retombée, le scénario sera probablement le suivant : 1) entreprises et États tentent de disperser la responsabilité ; 2) des incidents liés aux effets secondaires surviennent (accidents automobiles, algorithmes discriminatoires, fuites de données, etc.) ; 3) les tribunaux renvoient la responsabilité à des humains et infligent amendes ou sanctions ; 4) les autres entreprises prennent peur et limitent l’usage de l’IA. Dans cette dynamique, les outils d’IA sont condamnés à survivre à l’intérieur du cadre de la responsabilité humaine.
Cela fait plus de 25 ans que je développe du logiciel libre, et j’aime des licences très variées. Mon épouse est metteuse en scène et artiste visuelle, mais moi je ne touche à aucun contenu lié à l’IA et je considère cela comme des déchets. Je le dis clairement : je ne veux pas y être exposé.
Un défi comme le Konwinski Prize, qui promet 1 million de dollars à un LLM open source capable de résoudre plus de 90 % de nouveaux tickets GitHub, est intéressant. Voir le concours Konwinski Prize. À ce stade, même les meilleurs modèles n’atteignent pas 0,9 mais seulement 0,09, donc on est encore très loin d’un usage réel. Même si l’open source est légèrement moins performant que les modèles commerciaux, il reste que l’écriture de code autonome par les LLM est encore pratiquement impossible. Ils produisent beaucoup de déchets, mais peuvent quand même être utiles ne serait-ce que parce qu’il faut les évaluer et les encadrer.
Même si l’IA prend en charge les tâches répétitives de boilerplate, on se retrouve maintenant à faire la revue d’un code IA tout aussi répétitif, ce qui devient encore moins intéressant, demande un temps comparable et réduit la compréhension.
Ceux qui défendent le développement assisté par IA semblent au fond préférer la revue de code à l’écriture de code. C’est peut-être une question de goût, mais pour moi, c’est une activité pénible en soi.
Pour être précis, faire la revue d’un gros volume de code prend généralement moins de temps que de l’écrire soi-même, surtout quand les tests passent. Et comme les tests peuvent eux aussi être générés par un LLM, cela réduit encore la charge.
Claude, Gemini et autres vont bien plus vite que moi quand je code directement, et même après deux passages de revue, cela me prend toujours moins de temps que d’écrire le code moi-même.
Avant, on écrivait du code pour des tâches répétitives de type « yak shaving » ; maintenant, on passe son temps à revoir le rasage bâclé du « yak » par une IA.
Globalement, il faut s’attendre à des émissions d’énergie et de carbone plus élevées.
Discussion autour de la traduction automatique et de la reconnaissance vocale. En tant que personne presque sourde, j’utilise cette technologie toute la journée. Dans les années 80, je ne pouvais pas profiter de séries sans sous-titres, mais aujourd’hui, avec des LLM comme Whisper, je peux extraire des sous-titres depuis une vidéo : un miracle qui rend réel quelque chose que je n’osais autrefois qu’imaginer.
Les meilleurs systèmes SOTA en reconnaissance vocale et en traduction restent encore des modèles spécialisés dans une seule tâche, mais l’écart se réduit vite, tandis que les LLM peuvent faire beaucoup plus de choses. Voir par exemple le leaderboard de reconnaissance vocale ; les LLM ouvrent un champ de possibilités bien plus large.
Pendant des années, j’ai essayé toutes sortes de solutions de reconnaissance vocale, comme Dragon : c’était toujours impressionnant, mais peu pratique à l’usage. La combinaison Whisper + LLM a été le premier moment où j’ai constaté une utilité réelle. Ce n’est toujours pas parfait, mais le travail de correction manuelle a été divisé par dix ; pour mes notes personnelles, c’est devenu si pratique que je ne vérifie même plus.
Pour l’instant, je ne m’en remettrais toujours pas uniquement à la traduction par LLM pour des tâches vraiment à haut risque, par exemple un contrat de travail à l’étranger ou une déposition à la police. La conversion voix-texte existait déjà avant ; on sent bien le progrès, mais cela reste surtout adapté à des usages quotidiens et à faible risque, pas encore à des négociations interstellaires dignes d’un roman de SF.
Moi aussi, j’ai le sentiment que les progrès récents réalisent enfin les promesses de la SF de mon enfance. Il y a quelques jours, dans une ville inconnue, j’ai pris en photo un menu, extrait des caractères chinois manuscrits, obtenu une traduction immédiate en anglais, puis appris à prononcer le plat pour le commander. Je suis persuadé qu’une telle chose était impossible il y a encore 2 ans.
La traduction est justement, à mon avis, le domaine d’usage parfait des LLM. Ils peuvent intégrer des concepts sociaux, le contexte culturel, la pop culture, des références rares, et produire plusieurs variantes adaptées à différentes langues et cultures. Je suis convaincu qu’ils ont déjà largement dépassé la traduction traditionnelle.