Pourquoi la mode du « développeur remplacé » se répète-t-elle ?

 (alonso.network)
46 points par GN⁺ 2025-05-28 | 19 commentaires | Partager sur WhatsApp
  • Du NoCode à l'IA, les technologies prétendant remplacer les développeurs réapparaissent sans cesse, mais dans les faits, les rôles se transforment au gré des évolutions techniques
  • Le NoCode n'a pas supprimé les développeurs ; il a fait émerger des spécialistes du NoCode et des profils d'intégration, tandis que le cloud a créé le métier pointu d'ingénieur DevOps
  • Les outils de développement IA suivent aujourd'hui une trajectoire similaire, et même à l'ère où l'IA écrit du code, la capacité à concevoir l'architecture d'un système reste centrale
  • L'IA excelle dans l'optimisation locale, mais reste faible sur la conception d'ensemble, avec le risque de figer rapidement des erreurs structurelles à cause de sa vitesse de génération
  • Le remplacement des développeurs n'est au fond qu'une évolution et une montée en sophistication liées au changement de stack technique ; le rôle de fond demeure indispensable

From NoCode to AI-Assisted

  • Tous les quelques années, une nouvelle technologie censée remplacer les développeurs logiciels fait son apparition
  • Des titres du même genre reviennent en boucle, avec des attentes exagérées comme « la fin du code », « désormais tout le monde peut créer une app » ou « même les enfants codent »
  • Les dirigeants et les consultants se focalisent sur cette tendance, et l'on voit les budgets se déplacer en conséquence
  • Mais dans la réalité, il ne s'est jamais agi de « remplacement », plutôt de transformation
    • On a vu à plusieurs reprises apparaître de nouveaux rôles et des métiers plus spécialisés pour gérer une technologie devenue plus complexe, avec une hausse des niveaux de salaire
  • Le NoCode a nourri l'idée qu'on pourrait créer des applications sans spécialistes techniques, mais des problèmes complexes de modélisation de données, d'intégration et de maintenance ont fini par émerger, ce qui a donné naissance à de nouveaux métiers pour les résoudre
  • Le cloud a laissé penser qu'on pourrait se passer d'administrateurs systèmes, mais il a en réalité accru le besoin d'une expertise avancée d'ingénierie DevOps, avec des salaires en hausse
  • L'IA suit la même logique : on pourrait croire qu'elle va écrire le code à la place des développeurs, mais dans les faits l'importance des développeurs expérimentés capables de piloter et d'orchestrer l'IA ne fait que grandir

Le carrousel sans fin des promesses de remplacement (The Endless Carousel of Replacement Promises)

Révolution NoCode/LowCode

  • La révolution NoCode/LowCode a promis qu'avec des interfaces intuitives, n'importe quel utilisateur pourrait créer des applications
  • Mais sur le terrain, de nouveaux problèmes sont apparus : conception du modèle de données, intégration avec les systèmes existants et les bases de données, gestion des exceptions, maintenance, etc.
  • Il a donc fallu non plus de simples développeurs, mais des spécialistes NoCode capables de comprendre à la fois le métier et les limites techniques
  • Ces profils touchent des salaires plus élevés que les développeurs classiques

Révolution du cloud

  • Le passage au cloud a fait naître l'espoir qu'il ne serait plus nécessaire d'avoir des administrateurs systèmes
  • Mais la complexité et les besoins en expertise de gestion du cloud ont au contraire augmenté
  • Les anciens administrateurs systèmes se sont transformés en ingénieurs DevOps, mieux rémunérés, avec un niveau d'exigence plus élevé autour de l'automatisation de l'infrastructure, des pipelines de déploiement et de la gestion des systèmes distribués
  • Le travail n'a pas disparu ; il a évolué vers une nouvelle forme
  • Le passage aux microservices a lui aussi accru la complexité, montrant au final à quel point le rôle des experts capables de gérer fondamentalement les systèmes reste essentiel

Vague du développement offshore

  • L'idée s'est imposée que l'externalisation à l'étranger permettrait de réduire les coûts, mais des difficultés sont apparues en raison de problèmes de communication, d'une baisse de qualité et d'un manque de connaissance métier
  • Les stratégies ont finalement évolué vers des structures d'équipes distribuées, une propriété claire et une architecture solide, avec pour résultat un coût total plus élevé que ce qu'on espérait au départ

Révolution des assistants de code IA

  • Désormais, la grande promesse est celle d'une IA capable de générer automatiquement du code
  • Dans la réalité actuelle, le code produit par l'IA contient souvent des erreurs subtiles et des problèmes de cohérence
  • Les ingénieurs seniors passent beaucoup de temps à relire et corriger les résultats de l'IA, et plus un développeur est expérimenté, plus il crée de valeur
  • Les systèmes construits principalement avec l'aide de l'IA souffrent souvent d'une absence d'architecture cohérente
  • En d'autres termes, la technologie ne remplace pas le technicien ; elle hisse son expertise vers un niveau d'abstraction supérieur

Pourquoi ce cycle-ci est particulier

  • Le point clé que beaucoup négligent : le code n'est pas un actif, c'est une dette
  • Plus on produit du code rapidement et facilement, plus la charge de maintenance, de sécurité et de refactorisation augmente
  • L'IA peut optimiser à l'échelle de la fonction, mais elle reste faible en conception globale du système
  • Plus la vitesse d'implémentation augmente, plus le risque de figer rapidement des erreurs structurelles grandit
  • En fin de compte, à l'ère de l'IA, le véritable actif reste la capacité à concevoir l'architecture d'un système, et celle-ci doit être renforcée, non remplacée
  • L'affirmation selon laquelle « l'IA remplacera les développeurs » repose sur les malentendus fondamentaux suivants
    • Le code n'est pas un actif, mais une dette
    • Le code exige en permanence maintenance, vérification, gestion de la sécurité et remplacement, et la dette augmente avec chaque ligne écrite
  • Dire que l'IA produit du code plus vite revient simplement à dire qu'elle produit de la dette plus vite
  • Autrement dit, l'IA est performante en optimisation locale (fonctions, fonctionnalités partielles), mais faible pour les décisions globales de conception et d'architecture
  • Plus la vitesse d'implémentation augmente, plus le risque qu'une mauvaise conception se "fige" dans tout le système devient élevé
  • Cela peut convenir à un site ponctuel de courte durée, mais c'est critique pour un système amené à évoluer sur le long terme
  • Le schéma des innovations technologiques reste inchangé
    • Les administrateurs systèmes deviennent des ingénieurs DevOps, et les développeurs back-end deviennent des architectes cloud
  • Mais l'IA accélère tout. La compétence qui permet de survivre et de progresser n'est pas l'écriture de code
  • C'est la conception des systèmes (Architecting systems). Et c'est précisément la seule chose que l'IA ne sait pas faire

À lire aussi

19 commentaires

 
aer0700 2025-05-31

Je travaille de façon plutôt prudente, donc je n’ai jamais introduit d’outils d’IA dans des tâches importantes ; au mieux, j’ai simplement remplacé les recherches que je faisais sur Google ou Stack Overflow par des questions posées à Gemini ou à ChatGPT. Je les utilise, certes, mais…
Quand je demande à une IA de me fabriquer quelque chose, je me dis que ça peut aller si je l’utilise au niveau d’une fonction — en lui demandant de créer une fonction qui prend tel input et renvoie tel output — puis si j’écris moi-même au moins la logique pour vérifier que la valeur de retour produite par cette fonction créée par l’IA est correcte.
 
dbs0829 2025-05-30

Je suis sceptique face à la question de savoir s’il est possible d’organiser tout le contexte dans un format que l’IA puisse parfaitement comprendre. Les humains ne disposent pas seulement du contexte superficiel immédiatement nécessaire au développement en cours, mais aussi d’un contexte latent, et ils développent en tenant compte de ces éléments. Or, je ne pense pas encore que les humains soient capables de formaliser correctement ce contexte dans une expression bien structurée. À mon avis, c’est moins un problème de l’IA qu’une limite humaine. En particulier, je trouve que, de nos jours, les compétences rédactionnelles des gens ne sont pas si bonnes que ça.
 
geirdev 2025-05-29

Ce qui fait peur, ce n’est pas l’instant présent, mais plutôt la tendance...
 
hey23 2025-05-29

C’est aujourd’hui complètement différent.

L’avenir où tous les métiers seront remplacés est tout proche, et les développeurs n’en sont qu’un parmi d’autres.

Ce genre de chose n’a jamais été une mode.
 
kaykim 2025-05-29

Il n’y a sans doute jamais eu de changement exactement identique.

Mais c’est une évolution que beaucoup de professions ont déjà traversée il y a longtemps, à l’époque moderne. Par exemple, les artistes avec l’arrivée de la photographie, ou les artisans avec les usines automatisées. Le code ne me semble pas y échapper.

Je pense que, si l’innovation devient une réalité du quotidien, on aura au final besoin de plus d’ingénieurs qu’aujourd’hui. Les exigences des utilisateurs vont augmenter, et il faudra construire des choses plus grandes et plus complexes. Un peu comme le dit l’hypothèse de la Reine rouge.

Bien sûr, il est très probable que la nature du travail change, ou que certaines tâches disparaissent. Comme les typographes qui ont fini par disparaître sans qu’on s’en rende compte. Dans ce contexte, concevoir des systèmes sera sans doute une métaphore ou un exemple d’un niveau d’abstraction encore plus élevé.
 
pcj9024 2025-05-29

Je pense que c’est surtout parce que tout le monde veut remplacer les développeurs par quelque chose d’autre.
Il semble aussi qu’un nombre considérable de gens pensent qu’ils sont très bien payés alors qu’ils n’ont pas grand-chose à faire.
 
draupnir 2025-05-29

Je pense que, qu’ils soient réellement remplacés ou non, si ce genre de discours revient sans cesse, c’est parce qu’il est sensationnaliste.
La plupart du temps, quand on sort ce type de gros titre bien accrocheur, ce n’est pas le résultat d’une réflexion approfondie sur la réalité de la situation ni sur la manière dont on pourrait définir ce qu’est un « remplacement ».
À l’inverse, une analyse sérieuse traite plutôt de ce que l’IA ou d’autres outils peuvent faire aujourd’hui, et de la direction dans laquelle ils progressent. Mais ce genre de titre sans relief, le grand public ne clique pas dessus.
 
fanotify 2025-05-29

Il y a beaucoup de titres sensationnalistes..
 
kimjoin2 2025-05-29

Je pense qu’il faut voir les choses comme un remplacement progressif.
Il est vrai que le nombre de personnes nécessaires pour obtenir le même résultat sur une tâche donnée est en train de diminuer.

Même pour « concevoir un système », si ce que faisaient 10 personnes peut être réalisé par 8 personnes avec l’assistance de l’IA,
alors 2 personnes ont déjà été remplacées.
 
callakrsos 2025-05-29

Du point de vue de la conception système
N’est-ce pas parce qu’on l’ajoute sans vraiment le prendre en compte dans le prompting ?
 
ahwjdekf 2025-05-28

Le problème, c’est qu’on gère mal les conséquences du vibe coding.
 
tkddls8848 2025-05-30

Je suis d’accord avec cet avis d’après mon expérience personnelle. L’IA reste au fond un outil, donc elle est vraiment rapide et performante de 1 à 99, mais j’ai toujours l’impression qu’il manque le dernier 1.
 
ethanhur 2025-05-28

Je suis d’accord, mais il me semble que l’essentiel n’est pas tant la « conception de systèmes » que la « résolution de problèmes complexes par la conception de systèmes ».

Je pense que les tâches faciles deviennent encore plus faciles, tandis que les tâches difficiles continuent de devenir plus difficiles.
 
ididid393939 2025-05-28

Haha haha
 
GN⁺ 2025-05-28
Avis Hacker News

  • Après avoir récemment retouché en freelance des choses comme des « landing pages marketing jetables », constat que les clients très contrôlants ajoutent toujours des exigences bizarres que l’IA ne gère pas correctement, et qu’au final c’est encore lui qui doit rattraper la situation ; même si l’IA devient très intelligente, le vrai problème du logiciel n’est pas technique, mais le fait que les humains continuent eux-mêmes à produire de la « complexité inutile » ; au fond, la plus grande arme du développeur, c’est de savoir dire « non », avec l’inquiétude que si des IA se mettent en concurrence, il y en aura toujours au moins une pour dire oui, comme un humain le ferait

    • Le logiciel peut être implémenté parfaitement, mais si les exigences ne reflètent pas la réalité technique, on finit forcément dans la confusion : c’est la vieille idée du « bug de spécification » ; l’IA sait désormais gérer aussi des limites concrètes de format ou de prise en charge (par ex. gif ne prend pas en charge la transparence), mais des demandes absurdes du type « faites un logo carré dont chaque point est à égale distance du centre », les humains continueront à en écrire ; la faute de frappe sur jpg est aussi évoquée avec humour

    • Entre « non » et « oui », il existe 50 nuances de gris du type « est-ce vraiment ce qu’il faut » ; exemple d’un client qui voulait une page web permettant de « télécharger la base de données », alors qu’en réalité il parlait d’un simple export csv, ce qui montre l’importance de l’interprétation du contexte ; interrogation sur la capacité de chatgpt à saisir correctement ce genre de nuance

    • Dire « non » est vraiment la partie la plus difficile et la plus éprouvante du travail de développeur ; beaucoup de développeurs n’aiment pas réellement ce rôle, ou considèrent que ce n’est pas leur métier ; au final, la réussite réelle d’un projet dépend moins de la technique que d’une communication « d’humain à humain » avec les parties prenantes, d’où la conviction qu’on aura toujours besoin de développeurs qui font aussi, de fait, un travail de PM

    • Tout cela est très bien décrit dans le livre dit « Peopleware » ; il aime la formule « que tous vos problèmes soient techniques » ; dans la réalité, les problèmes qu’on résout réellement par le code n’ont presque jamais été si difficiles, sauf dans une petite poignée d’edge cases

    • Avis disant que c’est un bon point, et que l’IA pourrait devenir de plus en plus excellente pour estimer la complexité potentielle et lancer des alertes ; comparaison avec les échecs, où l’IA montre déjà des capacités d’évaluation et de jugement bien supérieures à celles des humains ; ici, l’IA ne se limite pas aux LLM, même si leurs progrès sont reconnus

  • Désaccord avec l’affirmation de l’article selon laquelle « l’IA ne peut pas architecturer un système » ; en réalité, l’IA progresse déjà dans ce domaine, et on assiste selon lui à un déplacement constant du débat par redéfinition des prérequis ; en revanche, l’IA ne peut pas décider à notre place ce qu’elle doit vouloir, ni quelles sont les motivations de l’utilisateur (même si elle peut suggérer des idées) ; à l’avenir aussi, il faudra toujours que quelqu’un se mette en mouvement et veuille résoudre les problèmes pour que la société fonctionne ; le rôle des développeurs changera, mais la résolution des problèmes restera humaine

    • On dit que le sens de « développeur » change, mais selon lui le fond a toujours été le même : programmer consiste essentiellement à transformer des exigences floues en code clair ; les moyens ont évolué, du code machine et des cartes perforées jusqu’aux frameworks, aux GUI et aux outils visuels, mais si écrire du code reste la méthode la plus efficace, c’est pour sa clarté et sa capacité de transmission ; les LLM sont forts pour reproduire l’existant, mais dès qu’on tente quelque chose de vraiment original ou qu’on essaie d’expliquer en langage naturel, la frustration est grande ; le marché est au sommet du hype, mais c’est au fond un motif qui se répète partiellement à chaque nouvelle technologie

    • Observation que des entreprises réduisent déjà les recrutements juniors à cause de l’IA ; si l’IA fait tout sauf l’architecting, on aboutit malgré tout à une structure où moins d’ingénieurs sont nécessaires

    • Affirmation catégorique que l’IA ne sait toujours pas faire d’architecture ; distinction entre architecture et planning : le planning consiste à répartir contraintes, solutions et ressources, et à prévoir ; on est encore loin d’un niveau où l’IA saurait le faire efficacement ; la vraie architecture implique une conception coopérative et concurrente sur plusieurs couches ; si l’IA se trompe à un niveau, tout l’ensemble peut dérailler, et seuls des humains peuvent concevoir et superviser ce type de système en sécurité

    • Avis selon lequel, avec assez de contexte, l’IA peut assez bien comprendre ce qu’on veut ; ce point rejoint en fait un avertissement sur la vie privée ; si une organisation maîtrise des systèmes puissants de compréhension contextuelle, le plus inquiétant est que l’IA pourra alors prédire « suffisamment bien » vos désirs et même vos prochaines actions

    • Remarque franche selon laquelle l’IA ne fait pas de l’architecture mais seulement de la simulation, et que souvent elle ne sait même pas coder correctement

  • L’idée même que le business valorise la qualité serait erronée : les entreprises ne regardent que la rentabilité, et ne fournissent de la haute qualité que si le client la demande ; honnêtement, les clients préfèrent eux aussi le « meilleur rapport qualité-prix » à la qualité réelle, achetant sur Amazon l’outil le moins cher et reproduisant encore et encore du code bancal du même genre (vibe code) ; au fond, les seuls à vraiment valoriser la qualité seraient les ingénieurs, donc les prédictions d’avenir fondées sur l’importance de la qualité du point de vue des ingénieurs peuvent être écartées sans hésiter

    • Réponse disant que la qualité peut être un facteur de différenciation ; à la sortie de l’iPhone, il existait déjà quantité de concurrents bourrés de fonctionnalités, mais c’est en proposant une UI plus fluide et plus raffinée qu’Apple a fini par dominer le marché

    • Présentation de Fractal Audio comme entreprise orientée qualité préférée de l’intervenant : une petite société qui fabrique des modéliseurs matériels pour guitare (simulateurs d’ampli et de pedalboard), avec des mises à jour innovantes à répétition et un CEO obsédé par les performances du modélisme analogique ; qualité très supérieure à celle des grands groupes ; positionnement sans commission, sans abonnement, sans marketing de célébrité, uniquement via vente directe et mises à jour d’algorithmes gratuites ; exemple vivant d’une part de marché gagnée par la qualité, et argument que toutes les entreprises ne se livrent pas forcément à une simple course au plus bas prix et à la plus basse qualité

    • Rejet de l’idée que les clients se moquent de la qualité : si la qualité n’avait aucun sens, toutes les startups auraient simplement sorti des produits incomplets et bon marché tout en réalisant des revenus énormes et un grand succès

    • Énumération de logiciels réellement couronnés de succès qui étaient, pour la plupart, d’excellente qualité : Google, iPhone, Stripe, Notion, etc. ; les produits qui ont duré sur le marché n’étaient ni lents ni truffés de bugs ; au contraire, la qualité a été un facteur de réussite ; il dit n’avoir jamais entendu de contre-exemple convaincant

    • Inquiétude que la qualité puisse s’éroder jusqu’à un certain point à cause de la modularisation, de l’abonnement et de la dépendance au réseau, puis que tout s’effondre brutalement : appareils transformés en briques, exécution en 12 secondes même pour un site simple, infrastructures sociales et systèmes publics devenant instables malgré des milliards investis, et conversations quotidiennes remplacées par des échanges avec des LLM

  • Retour sur la révolution organisationnelle passée fondée sur UML, avec des « architectes qui écrivent les spécifications et des développeurs qui remplissent les blancs », qui a surtout produit des systèmes trop complexes et fait perdre en agilité ; puis sur l’« agile », mal compris, qui a mené à davantage de micro-management des développeurs, de défiance et de culture d’entreprise non créative ; au final, les équipes qui réussissaient avaient en commun, indépendamment des outils ou des processus, que les non-développeurs s’intéressaient sincèrement au travail des développeurs et résolvaient les problèmes avec eux ; à l’inverse, les tentatives de réduction de la complexité auraient toujours échoué

  • À l’affirmation selon laquelle « l’architecture est la compétence la plus précieuse mais aussi celle que l’IA ne peut pas remplacer », réponse qu’en demandant explicitement à une IA de concevoir une architecture système, on obtient souvent de meilleurs résultats que ceux d’au moins 30 % des architectes rencontrés dans la réalité ; selon lui, c’est surtout parce que les utilisateurs d’IA ne formulent pas souvent ce type de demande

    • Les LLM actuels sont surtout entraînés sur beaucoup de réponses de niveau intermédiaire (best practice), donc ils produisent naturellement des résultats meilleurs que ceux du tiers inférieur des architectes humains, avec des conceptions de bon sens et « convenables » ; en revanche, dans des domaines entièrement nouveaux ou des industries exigeant de très hautes performances, où les données d’entraînement manquent, la pensée humaine fondée sur les premiers principes reste plus nécessaire ; un noyau de base de données conçu par LLM resterait probablement basique plutôt qu’innovant

    • Critique du style de l’article, perçu comme typiquement écrit avec ChatGPT : phrases courtes, tournures répétitives, formules du genre « non pas X mais X+1 », « non pas X mais anti-X », etc. ; étonnement de voir ce type de texte récolter autant d’upvotes sur HN

    • Interprétation selon laquelle l’auteur se livre en fait à une forme de pensée magique, ou de vanité, en imaginant que sa propre compétence (l’architecting) est immuable et irremplaçable ; s’il avait excellé dans une autre capacité, il l’aurait probablement décrite elle aussi comme irremplaçable

    • Résumé : l’essence du rôle d’architecte, c’est la capacité à comprendre précisément les exigences et les contraintes et à les refléter dans le système ; autrement dit, savoir écrire de bons prompts, lire correctement les réponses et, si nécessaire, savoir les contester fermement

    • Dans la réalité, une part importante des « architectes » rencontrés manquait de compétence réelle en infrastructure IT et pensait qu’il suffisait de manier un outil de diagrammes ou Excel ; ils ressemblent à des managers, mais en pratique seule une minorité sait faire le vrai travail de fond

  • Avis selon lequel les entreprises qui dépendent « excessivement » de l’IA s’exposent davantage aux vagues de rupture ; à l’ère de l’IA, l’enjeu central n’est plus la productivité brute du code, mais le contrôle de la qualité du code, alors que le marché se focalise trop sur la génération automatique ; mention de la déclaration de Satya Nadella selon laquelle « 30 % du code de Microsoft est écrit par l’IA », et du fait que GitHub connaît en moyenne plus de 20 incidents par mois (source : githubstatus.com/history) ; prévision que des entreprises obsédées par l’efficacité paieront ensuite le prix d’une dégradation de qualité, surtout les PME plus vulnérables que des géants comme Microsoft

    • Contre-avis disant que ce sont plutôt les entreprises qui ignorent l’IA qui auront du mal

    • Affirmation que « les entreprises qui abusent de l’IA finissent au contraire par porter des coûts plus élevés sur le long terme », avec partage de cet article lié : AI: Accelerated Incompetence

  • Accord à 100 % avec l’idée que « le code n’est pas un actif mais une dette » ; l’objectif est d’atteindre le résultat avec le minimum de code ; l’IA risque au contraire d’alourdir fortement la dette logicielle, justement parce qu’elle permet de produire du code trop facilement

    • Partage d’un lien Wikipédia sur le paradoxe de la productivité technologique, où les gains de productivité sont compensés par l’augmentation de la complexité des systèmes : Productivity paradox

    • Comparaison entre l’ère actuelle de génération de code par l’IA et l’époque où l’on fabriquait des sites web avec MS FrontPage, quand le HTML était rempli à 90 % de code inutile : une nouvelle « ère du cruft »

    • Contre-idée : si le code devient facilement remplaçable, la notion même de dette ne perd-elle pas de son sens ? À l’avenir, en cas d’erreur, le programmeur demandera simplement à l’IA de réécrire le code, ce qui pourrait alléger la charge

    • L’intervenant dit aussi voir le code comme une forme d’expression créative et artistique, partageant l’expérience de ressentir immédiatement la beauté d’un code élégant, lisible et raffiné

  • Partage d’un lien rappelant qu’aux débuts de FORTRAN (1954), le slogan était déjà que « Fortran éliminera le codage et le débogage eux-mêmes » : BackusEtAl-Preliminary Report

    • Partage aussi de l’anecdote de la « turkey illusion » — l’idée qu’on peut se tromper longtemps avant d’avoir soudain faux pour de bon — par exemple la dinde nourrie chaque jour qui s’imagine en sécurité jusqu’au jour de l’abattage : Turkey illusion

  • Hypothèse de fond dans toutes ces discussions : l’idée que le progrès technique atteindra bientôt une limite ; si cette hypothèse est fausse, rien n’empêche qu’un jour l’IA comprenne et conçoive aussi l’ensemble d’un business en s’appuyant sur toute l’infrastructure, les logs, la finance et la documentation ; les modèles continuent de croître, deviennent plus performants et moins chers, ce qui pousse à penser qu’ils finiront peut-être par atteindre le cœur même de ce qui est aujourd’hui considéré comme irremplaçable

    • Mais dans ce cas, les systèmes conçus par l’IA risquent de devenir de plus en plus opaques, presque « extraterrestres », et l’écosystème de développement centré sur l’humain pourrait être réduit au minimum ; un contrôle social resterait indispensable, avec des experts chargés de surveiller et d’orienter la trajectoire d’ingénierie logicielle prise par l’IA ; cette transition s’annonce longue et complexe

  • Point de vue selon lequel les licenciements de développeurs ne viennent pas du progrès technique, mais de mesures de suivi liées à l’incertitude ; invoquer la technologie ou l’IA ne serait qu’une justification a posteriori ; il rappelle qu’il y a seulement cinq ans, les entreprises augmentaient encore leurs effectifs d’ingénieurs logiciel malgré le coût, dans l’espoir d’améliorer la productivité ; selon lui, le coût n’est donc pas la cause fondamentale

    • Réponse : « cette productivité supplémentaire n’apparaît dans aucun indicateur économique » ; si la productivité avait réellement augmenté, cela devrait se voir à l’échelle de l’économie, ce qui alimente le doute
 
click 2025-05-28

Je cherche quelqu’un pour relire du vibe coding IA. Tout est déjà fait, il faudrait juste corriger légèrement les erreurs qui apparaissent. Ce type de demande de prestation existe déjà, alors qu’il est plus rapide de repartir de zéro.
 
aer0700 2025-05-31

Je l’ai vécu moi aussi, et c’était horrible...
 
mentee313 2025-05-29

Je ne sais pas si ce sont des gens qui ne comprennent pas, ou des gens que ça n’intéresse pas, mais il y en a vraiment beaucoup...
C’est pareil pour la traduction aussi... L’IA peut être utile ? Mais on dirait qu’elle complique la vie de beaucoup de gens...
À première vue, ça semble plausible, mais du point de vue de celui qui doit corriger, le travail augmente encore davantage, snif snif
 
heim2 2025-05-28

Frissons mdr