La revanche du développeur junior
(sourcegraph.com)Partie 1 : les six vagues du codage IA
- Le vibe coding est un surnom amusant donné à une manière conversationnelle de coder, où l’on demande à un LLM d’écrire du code, puis où l’on itère en donnant du feedback sur le résultat
- C’est un concept très différent du codage classique ou centré sur l’autocomplétion ; au départ, le terme était utilisé sans définition claire, puis il s’est rapidement diffusé après qu’Andrej Karpathy l’a baptisé "vibe coding"
- Aujourd’hui, le vibe coding se trouve simultanément dans trois états :
- 80 % de l’industrie ne sait même pas que le vibe coding existe, et beaucoup entendent pour la première fois parler d’"agents de codage"
- Il se propage de manière explosive dans les médias et sur les réseaux sociaux, et malgré les débats et les avis pour ou contre, beaucoup de développeurs le considèrent déjà comme une technologie d’avenir
- Le codage classique basé sur le chat est déjà vu comme une technologie d’un autre âge, et certains développeurs enthousiasmés par des approches plus rapides ne s’intéressent déjà plus au chat
- Cet article décrit l’évolution du codage basé sur l’IA en six vagues :
- codage traditionnel (2022)
- codage basé sur l’autocomplétion (2023)
- codage conversationnel (2024)
- agents de codage (premier semestre 2025)
- clusters d’agents (second semestre 2025)
- flotte d’agents (2026)
- Parmi elles, le codage traditionnel et le codage basé sur l’autocomplétion déclinent progressivement, tandis que les approches qui suivent se diffusent chacune plus vite que la précédente
- Le vibe coding apparaît séparément de ces vagues, sous forme de ligne pointillée
- le vibe coding coexiste avec toutes les approches ci-dessus et ne désigne pas une méthode particulière, mais un concept englobant toute situation où l’IA écrit l’essentiel du code
- Le prochain concept de cluster d’agents consiste à gérer plusieurs agents en parallèle, tandis que la flotte d’agents étend cela à une structure où un manager IA supervise des agents subordonnés
- L’organigramme FY26 illustre cette idée : un seul développeur pilote plusieurs groupes d’agents, chacun remplissant des rôles variés comme la correction de bugs, le développement de nouvelles fonctionnalités ou le refactoring d’architecture
- Aujourd’hui, l’humain doit encore intervenir directement quand un agent s’arrête ou part dans la mauvaise direction, mais bientôt ce rôle sera pris en charge par un agent superviseur
- Au final, il sera possible de piloter simultanément plusieurs dizaines d’agents, formant un système automatisé capable de traiter d’immenses bases de code legacy
- Ces flottes d’agents devraient apparaître de façon certaine d’ici début 2026, et la technologie nécessaire pour organiser efficacement le travail en parallèle est déjà prête
Partie 2 : où en êtes-vous aujourd’hui ?
- Si vous utilisez encore l’IA uniquement comme outil d’autocomplétion de code, ou si vous accordez une grande importance au Completion Acceptance Rate (CAR), vous appartenez à la courbe de programmation traditionnelle de la Figure 1
- cette courbe devrait avoir complètement disparu vers 2027
- l’autocomplétion était encore populaire il y a un an, mais ce n’est déjà plus une technologie centrale
- Si vous êtes plus avancé, vous utilisez peut-être des outils de codage basés sur le chat dans l’IDE comme Copilot, Cursor, Sourcegraph ou Windsurf
- dans ce cas, vous êtes dans une position correcte, avec une méthode bien plus productive que la simple autocomplétion
- le codage basé sur le chat reste largement utilisé, mais ce n’est plus la référence du dernier cri
- Les agents de codage récemment apparus (
Aider.chat, Claude Code, etc.) montrent qu’ils pourraient surpasser toutes ces approches- ils s’intégreront naturellement dans l’IDE et sont bien plus rapides et efficaces que les approches conversationnelles précédentes
- une fois qu’on a utilisé un agent, il est difficile de revenir aux anciennes méthodes
- Le codage basé sur les agents est lui aussi une forme de vibe coding
- le vibe coding signifie "toutes les façons dont l’IA écrit du code", et non une modalité technique particulière
- la différence, c’est que les agents peuvent avancer sans qu’il soit nécessaire de dialoguer souvent avec eux
- L’évolution des différentes méthodes de codage suit un schéma de multiplication de la productivité :
- le codage basé sur le chat est environ 5 fois plus productif que le travail manuel
- l’approche par agents peut à nouveau être 5 fois plus productive que le chat
- avec le temps, chaque vague pourrait atteindre un gain de productivité de 10x, mais la courbe s’aplatit parce que de nouvelles technologies apparaissent encore plus vite
- Nous nous trouvons aujourd’hui au milieu d’un immense océan IA, et il faut apprendre à surfer sur des vagues de plus en plus puissantes, c’est-à-dire de nouvelles technologies
- toutes les entreprises se situent sur au moins une des courbes d’adoption de la Figure 1
- il faut se demander honnêtement sur quelle courbe on se trouve soi-même
- Le vibe coding n’est pas une technique précise, mais une nouvelle philosophie du développement et une nouvelle réalité
- l’idée centrale est qu’on n’écrit plus directement le code soi-même
- on délègue l’écriture du code à l’IA, tandis que l’humain se concentre sur la revue et la coordination du résultat
- Dans la partie suivante, on examine l’impact financier de cette évolution technique
- les agents de codage ne sont pas magiques ; ils deviennent plus intelligents à mesure qu’on y brûle du budget
- si vous ne les avez pas encore essayés, il est important de le faire tout de suite, ou au moins d’observer quelqu’un qui les utilise
Partie 3 : mode d’emploi du nouveau chameau
- Les agents de codage les plus récents sont une technologie extrêmement nouvelle, apparue il y a seulement quelques semaines, et ils fonctionnent pour la plupart dans un terminal
- c’est un peu comme si, après avoir toujours marché à pied, on vous donnait soudain un chameau : c’est pratique, mais difficile à manier et coûteux à nourrir
- même un seul chameau vous fait aller bien plus vite qu’à pied, mais il peut aussi cracher, mordre et s’enfuir
- Beaucoup de développeurs restent encore sceptiques vis-à-vis du codage IA et veulent toujours écrire le code eux-mêmes
- certains affirment clairement : "Moi, je suis quelqu’un qui écrit du code !"
- mais cette façon de penser est désormais en retard sur la réalité
- Plus vous êtes sceptique, plus il est recommandé de télécharger et d’essayer immédiatement les tout derniers agents de codage (sortis après le 1er mars)
- il y a encore quelques semaines, l’auteur a lui-même constaté avec surprise à quel point ils avaient progressé
- Les agents reposent sur le même principe que le vibe coding, mais il n’est pas nécessaire que l’humain échange directement des prompts avec eux
- ils exécutent seuls des tâches complexes, puis reviennent vers l’utilisateur une fois le travail terminé ou lorsqu’un problème survient
- comme ils réalisent automatiquement 90 à 99 % de l’ensemble du travail, l’humain cesse d’être le goulot d’étranglement
- Ce qui les distingue d’une approche basée sur le chat :
- les agents peuvent traiter des unités de travail plus grandes en une seule fois
- pendant ce temps, le développeur peut librement faire autre chose (par exemple grignoter, ou lire Hacker News)
- Exemple : si on leur dit simplement "Résous ce ticket JIRA", alors ils vont :
- chercher la CLI JIRA, et demander son installation si nécessaire
- écrire un programme temporaire pour lire les champs du ticket
- analyser le code → trouver le bug → proposer une correction → écrire et exécuter les tests → répéter la boucle
- Au final, l’agent ressemble à un développeur humain travaillant à une vitesse éblouissante, mais avec un sens de l’orientation un peu défaillant
- Inconvénients :
- pour l’instant, il ne peut traiter de manière fiable que de petites unités de travail
- des attentes excessives mènent à l’échec, et la capacité de décomposition des tâches est indispensable
- si la tâche est trop grande, il ne l’exécutera pas correctement et finira par se perdre
- C’est pourquoi, à l’heure actuelle, le choix minutieux des problèmes et la supervision restent nécessaires, et il faut traiter l’agent comme un animal obstiné
- Mais cette situation va bientôt changer :
- les agents vont bientôt s’intégrer naturellement dans l’IDE et évoluer vers des outils plus faciles à utiliser et plus familiers
- du chameau, on passera au cheval sellé, puis bientôt au char
- Conclusion : c’est le moment idéal pour apprendre à travailler avec des agents,
- et davantage de fonctionnalités, de meilleures interfaces et des gains de productivité plus importants arriveront bientôt
Partie 4 : on m’avait dit qu’il n’y aurait pas de maths
- Cette section s’adresse aux CIO et aux responsables financiers
- Maintenant que le budget FY26 vient d’être finalisé, combien avez-vous prévu en coûts d’usage des LLM par développeur ?
- 25 $ par jour peut sembler audacieux, mais c’est en réalité proche d’un niveau approprié
- La réalité est encore plus sévère :
- les agents de codage sont très coûteux — ils consomment des tokens à hauteur de 10 à 12 $ de l’heure
- si une licence d’assistant de codage classique coûte environ 30 $ par mois, cela représente un écart de coût de plusieurs dizaines de fois
- Mais en termes de calcul, un agent de codage utilisé 8 à 10 heures par jour atteint une productivité comparable à l’embauche d’un développeur junior
- à 10 $ de l’heure, c’est extrêmement bon marché, et un développeur peut faire tourner deux agents en parallèle
- avec environ 100 $ dépensés par jour en LLM, la productivité d’un développeur peut plus que doubler
- Mais le vrai changement viendra bientôt avec les clusters d’agents (attendus au T3 2025)
- un développeur pourra faire fonctionner plusieurs agents en parallèle
- chaque agent pourra travailler indépendamment sur des tâches variées : correction de bugs, développement de nouvelles fonctionnalités, rédaction de documentation, etc.
- En conséquence, un seul développeur pourra remplir le rôle de plusieurs développeurs
- bien sûr, plus la personne est compétente, plus l’effet sera fort
- L’arrivée des clusters d’agents sera le déclencheur du basculement du développement logiciel vers le cloud
- impossible de gérer des dizaines ou des centaines d’agents sur un poste local
- l’environnement de développement cloud deviendra de facto le standard
- Il faut donc prévoir aussi un budget cloud supplémentaire
- Par exemple, si un développeur fait tourner 5 agents :
- 50 $ de l’heure → environ 100 000 $ de coût annuel (hors coûts cloud)
- ce n’est plus un « investissement peu coûteux », mais une dépense significative
- cependant, la productivité peut augmenter d’au moins 5x, ce qui laisse espérer un ROI élevé à long terme
- Le problème, c’est que la plupart des entreprises n’auront probablement pas intégré ces coûts LLM dans leur budget opérationnel 2026
- cela creusera l’écart entre les entreprises : celles qui ont le budget prendront l’avantage technologique, celles qui ne l’ont pas risquent de décrocher
- Conclusion :
- le développement logiciel est désormais un train à grande vitesse pay-to-play
- sans ticket, c’est-à-dire sans budget, le risque de se faire distancer est élevé
Partie 5 : la flotte d’agents arrive
- À partir d’ici, on aborde une vérité un peu dérangeante
- si vous n’êtes pas prêt à l’entendre, mieux vaut faire une pause avant de reprendre la lecture
- L’étape suivante après les clusters d’agents est la flotte d’agents, c’est-à-dire un environnement où un développeur pilote plus de 100 agents à la fois
- un agent superviseur apparaît alors au niveau supérieur pour gérer les groupes d’agents subordonnés, et l’humain n’intervient qu’en cas de problème
- Le rôle futur du développeur ne sera plus d’écrire du code, mais :
- d’exploiter et de superviser des tableaux de bord affichant des agents et des managers IA
- certains appelleront cela de manière sarcastique du "baby-sitting d’IA", mais c’est bien la forme que prendra bientôt le nouveau développement logiciel
- Du point de vue d’un CIO, l’ère de la flotte d’agents pourrait représenter plusieurs milliers de dollars par jour et par développeur en coûts LLM
- même si le coût de l’inférence baisse, l’augmentation de l’usage compense les économies, selon le paradoxe de Jevons
- exemple : il suffit de penser à l’ampleur sans fin de votre backlog de bugs
- Mais il ne s’agit pas d’un gaspillage : c’est un investissement d’une valeur énorme
- enfin, les organisations d’ingénierie pourront avancer au rythme voulu par la direction
- on entre dans une époque où l’on pourra surprendre et ravir les clients avec l’agilité d’une startup
- L’inconvénient, c’est que cela demandera énormément de budget
- certaines grandes entreprises ont déjà constitué un budget d’expérimentation LLM sous forme de slush fund, mais
- beaucoup n’ont probablement pas du tout pris cela en compte dans l’exercice budgétaire actuel
- certaines grandes entreprises ont déjà constitué un budget d’expérimentation LLM sous forme de slush fund, mais
- Si vous ne parvenez pas à dégager 50 000 $ de budget supplémentaire par développeur d’ici la fin de l’année, il se pourrait qu’il ne reste plus d’autre option que la restructuration
- ce changement pourrait au contraire favoriser les startups agiles
- on entre dans une époque où la disponibilité du budget, plus que l’écart technique, détermine la compétitivité des entreprises
- Et si vous ne pouvez pas trouver ce budget, il est évident de savoir quel est le seul département où couper
- la réponse est laissée au jugement du lecteur
- Heureusement, cette prédiction est peut-être un peu exagérée
- après en avoir discuté avec Claude (LLM), il pourrait être plus réaliste de décaler cette prévision d’environ six mois
- La bonne nouvelle, c’est que tout commence maintenant
- la mauvaise nouvelle est passée, et il ne reste plus qu’une chose : la douce revanche
Partie 6 : la revanche du développeur junior
- L’avenir n’est pas sombre. Au contraire, l’industrie du logiciel offrira encore beaucoup d’emplois
- en revanche, le rôle traditionnel du développeur qui écrit manuellement du code va disparaître
- L’un des schémas observés au cours de l’année écoulée, c’est que les développeurs juniors adoptent l’IA bien plus activement que les seniors
- certains craignent que l’IA prenne leur emploi, mais la plupart s’adaptent rapidement au changement
- ils étudient le livre AI Engineering d’O’Reilly et utilisent avec aisance le chat coding comme les agents de codage
- À l’inverse, les développeurs seniors ont souvent à peine utilisé des LLM, voire ne les connaissent qu’indirectement
- il existe même des cas de rejet frontal des technologies IA
- exemple : un développeur d’une entreprise connue a remis un PDF de slides affirmant qu’il fallait « abandonner l’IA et revenir au codage traditionnel »
- Ces réactions viennent de l’anxiété face à une technologie nouvelle et de la perte perçue de la valeur des connaissances accumulées
- apprendre un nouveau langage ou un nouvel outil s’accompagne fondamentalement de la peur de « devoir tout recommencer depuis zéro »
- Mais la réalité est claire :
- ceux qui ont ignoré l’IA sont déjà sortis de la partie
- les développeurs juniors coûtent moins cher, s’adaptent mieux et apprennent plus vite
- lorsque les entreprises devront ajuster leurs effectifs de développeurs, il sera évident de voir quels profils elles choisiront
"L’IA n’a pas besoin de prouver qu’elle est meilleure que vous. C’est vous qui devez savoir mieux l’utiliser."
- Autrement dit, le développeur junior est maintenant celui qui se tient sur la colline, sabre de lumière à la main,
- en criant aux développeurs seniors de s’adapter au changement
- La leçon à tirer de toute cette situation :
- qui que vous soyez, entreprise ou individu — agissez comme un junior
- c’est le moment d’adopter les technologies IA et de s’y adapter
- Sourcegraph analyse chaque jour cette évolution technologique,
- et connecter les agents de codage aux actifs de code d’entreprise est la prochaine stratégie clé
- De manière générale, à mesure que l’adoption de l’IA progresse, les emplois liés au logiciel augmenteront probablement eux aussi
- si les embauches stagnent aujourd’hui, c’est simplement parce que les entreprises restent prudentes faute de savoir encore comment réagir
- historiquement, à chaque transition technologique, la productivité explose et le PIB augmente lui aussi
- Ce qu’il faut donc faire maintenant :
- apprendre et maîtriser les agents de codage
- les PM et les autres métiers techniques ne font pas exception
- le développement basé sur les LLM ne se résume pas à écrire des prompts. Il va transformer le travail réel de développement : validation, tests, coordination, etc.
- Avertissement :
- les agents de codage sont puissants, mais ce sont des outils comparables à des tunneliers
- ils sont chers, peuvent s’arrêter et peuvent perdre leur direction
- un guidage continu et des attentes réalistes sont nécessaires
- Le vibe coding est, comme son nom l’indique, une façon de travailler plaisante
- le fait de ne plus avoir à écrire soi-même le code procure une sensation de liberté étonnamment forte
- L’idée de se dire « dans six mois ce sera meilleur, donc attendons pour l’instant » est dangereuse
- au final, on retarde le départ et on arrive en dernier
- Les agents arrivent. Et pas seulement les agents de codage :
- des centaines d’agents de tâches sont déjà en cours de déploiement à l’échelle de toute l’entreprise
- Consignes d’action finales :
- passer au chat
- abandonner l’autocomplétion
- réduire le codage manuel
- apprendre à valider, réviser et exécuter dans un environnement piloté par l’IA
- continuer à expérimenter et à appliquer au rythme des tendances technologiques les plus récentes
- Même si les agents de codage paraissent aujourd’hui difficiles et imparfaits, ils deviendront bientôt omniprésents
- ce sont des machines de productivité bien moins coûteuses que les humains, et le choix des entreprises est évident
- Fin 2025, le poste de “software engineer” n’impliquera presque plus de coder directement
- à la place, le cœur du travail sera l’exploitation des agents, leur coordination et la gestion de la validation
- Enfin : si vous ne savez pas quoi faire maintenant, allez demander de l’aide à un développeur junior
Cela fait déjà deux ans que "Cheating is all you need" a été écrit, et entre-temps tout a changé
Nous sommes maintenant au cœur même du changement, et c’est le moment de monter dans le train
23 commentaires
Ce qui est vraiment frustrant, c’est que
Avant : réflexion => code (lent) => débogage
IA : réflexion => rédaction d’un prompt précis => code (instantané) => débogage
Mais en général, aller plus vite en écrivant directement du code qu’en transformant ma pensée en prompt, non ? Sauf quand il s’agit de faire quelque chose de déjà très bien connu... Et quand la fiabilité est importante, de toute façon il faut relire la logique à l’œil après coup, donc on ne peut pas vraiment déléguer, et à partir du moment où on délègue, on perd aussi une forme de conscience professionnelle.
Je suis un manager issu du développement qui ne code plus vraiment, mais ces derniers temps, j’ai l’impression d’être redevenu junior et je me remets à tester toutes sortes de choses moi-même. Maintenant que je fais moi-même ce que je demandais à mes collègues, je suis un peu déconcerté de voir à quel point ça va vite. Ça me fait aussi penser qu’on pourrait faire davantage de choses, même dans une petite équipe. Merci pour ces bons outils et ces explications !
En ce moment, comme hobby, je développe en vibe coding le client, le serveur et l’admin d’un jeu web (je ne modifie même rien moi-même : je copie les parties à corriger, je demande une modification, puis j’applique tel quel le code généré). On est actuellement à environ 20 000 lignes. Ça m’énerve parfois, mais quand je pose mes questions en étant agacé, ça continue jusqu’ici à me sortir du code plutôt correct.
Je suis d’accord avec cet article à plus de 90 %.
Il semble désormais certain que nous sommes en train de vivre un moment où les compétences et les paradigmes du développement changent.
Je pense qu’il faut maintenant accorder davantage d’attention, du point de vue des capacités de pilotage, aux design patterns, aux méthodes de construction d’applications généralistes et aux méthodologies de résolution de problèmes.
Le développement d’algorithmes a depuis longtemps dépassé les limites humaines, et tout comme l’IA est déjà en train d’effectuer des optimisations algorithmiques que les humains ne peuvent pas comprendre, les développeurs de demain doivent désormais se concentrer sur un champ plus large et sur davantage de tendances.
Il est important d’apprendre l’IA, mais je pense qu’il n’est pas nécessaire de réagir de manière excessive chaque fois qu’une nouvelle technologie apparaît. Il est plus efficace d’investir davantage de temps dans les concepts fondamentaux qui ne changent pas, et comme l’IA est relativement facile à apprendre, je pense qu’on peut aussi l’aborder progressivement. Plutôt que de courir après chaque nouveauté, je pense qu’il est important de développer des compétences de fond.
Même maintenant, il ou elle est meilleur(e) que pas mal de gens. À force d’étudier le code des gourous de l’open source, quand on pose bien ses questions, on obtient une très bonne qualité de résultat haha.
On ne sait pas jusqu’à quel niveau les technologies d’IA fondamentales pourront progresser.
Au niveau actuel, on en est très loin.
Du point de vue de la baisse de valeur des connaissances ou de l’expérience acquises, il me semble que la frontière même entre senior et junior va devenir floue.
Et je pense aussi que cela va devenir un marché où une petite minorité rafle tout. À l’avenir, le recrutement de développeurs s’orientera probablement moins vers l’effort fourni ou l’expérience, et davantage vers la sélection de pilotes d’IA dotés dès le départ d’excellentes capacités de réflexion et de raisonnement.
Un agent superviseur, hein...
S’il y a grosso modo 4 étapes de développement (développement, débogage, QA et débogage, refactorisation), est-ce qu’il pourra vraiment rattraper toutes les hallucinations qui se produisent dans ces 4 couches...
Même aujourd’hui, même si on écrit précisément dans le prompt qu’on exige du débogage et des tests, il sort parfois encore des absurdités du genre qu’il ne sait pas où est le problème (Sonnet 3.7).
À moins que l’architecture Transformer elle-même ne change.
La raison pour laquelle il m’est difficile d’adhérer au vibe coding, c’est que les agents d’IA ne parviennent toujours pas à résoudre le fait qu’on doit continuer à travailler sur la base du code. Si les agents fonctionnaient de manière autonome, pourquoi aurait-on encore besoin de code, qui n’est pas pratique à interpréter pour les machines ?
Je pense que le moment où les agents d’IA transformeront réellement la manière de développer des logiciels, ce sera précisément quand ils auront totalement abstrait la couche du code pour l’utilisateur qui les dirige. Pour l’instant, on en est seulement au stade où ils génèrent rapidement des fragments de code (ce qui est déjà impressionnant, bien sûr).
Tant que le moment où les agents d’IA nous libéreront du code ne sera pas arrivé, même si le changement est impressionnant, j’ai du mal à adhérer à l’idée que cela transforme de façon spectaculaire les méthodes de travail de l’industrie du logiciel.
Je pense que c’est similaire à l’introduction de la méga-usine de Hyundai Motor.
Les travailleurs traditionnels évolueront sans doute vers des rôles de mise en place et de maintenance. (Cette partie me semble un peu plus compréhensible.)
En revanche, est-ce que cela ira aussi jusque dans le domaine de l’abstraction ?
Personnellement, je pense que c’est possible.
Je confonds encore parfois l’ordre alphabétique des lettres quand j’écris des paires de groupes de motifs encore un peu complexes... (pitié !!) J’ai pas envie de taper au clavier
À part la toute dernière partie sur les juniors, je suis globalement assez d’accord.
Il serait plus juste de dire que les seniors ou les entreprises existantes qui n’arrivent pas à adopter l’IA seront remplacés avec le renouvellement des générations.
Les réalisations de développement importantes d’une entreprise restent presque à 100 % privées sur Internet. Au niveau actuel de l’IA, il est impossible de produire une telle qualité. N’importe quoi.
S’il y a un niveau de connaissances et de compétences similaire, on obtiendra probablement des résultats similaires dans un environnement adapté.
Le développement, ce n’est pas seulement des applications web pour lesquelles relativement beaucoup de ressources sont publiques ; c’est extrêmement varié, des moteurs graphiques à l’embarqué, jusqu’à la conception de puces bas niveau. Il existe beaucoup de domaines où l’on part de zéro, ou presque. Moi aussi, dans mon domaine, il n’y a ni sur GitHub, ni dans la documentation, ni sur Internet de références vraiment exploitables. Il est donc normal que Grok ou Claude ne produisent pas non plus de résultats corrects. Le cas où l’on fournirait tout le code au modèle ou où l’on ferait du fine-tuning est hors sujet ici.
Vous n’avez probablement pas ce type de développement exigeant une telle expertise, ou bien vous n’avez pas d’actifs internes dont l’exposition est interdite ; il vaudrait donc mieux éviter d’être trop sûr de bien cerner la situation.
L’argument selon lequel l’IA ne pourrait pas empiéter si quelque chose n’est pas sur Internet ne vous paraît-il pas un peu étrange ? Je pensais qu’à mesure que la recherche sur les méthodes d’apprentissage progresse, l’IA développée en interne finirait par remplacer les développeurs internes.
Cela signifie qu’Internet n’est pas le problème, mais qu’il n’y a pas de données disponibles pour entraîner un modèle d’IA, non ? Alors pourquoi parle-t-on de recherche sur les méthodes d’apprentissage ? Moi, je parle de la réalité concrète. On ne pourra absolument pas créer une IA qui remplace tous les développeurs d’ici la fin 2025. À la base, ce n’est même pas un problème de performance.
Je crois que vous avez mal compris ce que je voulais dire : je parlais d’un scénario où l’entreprise entraîne une IA sur son propre code, puis l’utilise pour générer du code en interne.
Le superviseur doit bien s’y connaître… pour savoir si quelqu’un glande, travaille, fait n’importe quoi ou fait bien son boulot… Je croyais qu’un superviseur, c’était juste quelqu’un qui éteint et rallume le courant…
Si le travail d’un superviseur se résume à éteindre et rallumer le courant… alors c’est justement le genre de personne qu’on peut très bien remplacer par une IA.
Personnellement, je ne suis pas vraiment d’accord. Si un senior se fait dépasser par un junior qui travaille avec l’IA, alors à mes yeux, ce n’était pas un vrai senior au départ.
C’est dommage, j’ai l’impression que l’argumentation manque de fondements.
Le nom de Neo a-t-il été changé ?
Ce n’est pas un changement de nom ; il semblait simplement y avoir un doublon entre les mentions GN+ et neo, donc j’ai regroupé cela en une seule. Si vous cliquez, vous arriverez sur neo.