L’IA est en train de rendre les développeurs juniors inutiles

• Les outils d’IA ne créent chez les développeurs juniors qu’une compétence superficielle : ils produisent rapidement du code, mais il devient fréquent d’être incapable d’expliquer pourquoi cette approche a été choisie
• La vraie valeur des développeurs seniors ne réside pas dans la vitesse d’écriture du code, mais dans la reconnaissance des schémas d’échec accumulée au fil des années et des erreurs
• Même en utilisant l’IA, le processus de lutte volontaire consistant à analyser soi-même les erreurs, suivre le code et formuler des hypothèses reste indispensable
• Pour chaque ligne de code que l’on commit, il faut pouvoir expliquer soi-même pourquoi telle bibliothèque, tel pattern et quels sont les trade-offs ; sinon, ce n’est pas prêt pour la mise en production
• Il faut cesser d’utiliser l’IA comme simple générateur de réponses et l’employer comme tuteur, afin d’apprendre les avantages et inconvénients de plusieurs approches

---

La racine du problème : la compétence superficielle créée par l’IA

• L’usage des LLM a rendu possible l’implémentation et le déploiement rapides de fonctionnalités, mais on se retrouve parfois incapable d’expliquer pourquoi un certain code a été choisi
  • Lors des code reviews, le phénomène de compétence superficielle (shallow competence) se répand : certains ne savent pas répondre quand on leur demande pourquoi ils ont choisi une approche
  • Le schéma consistant à accepter tel quel le code proposé par l’IA se répète
• En apparence, la productivité semble élevée, mais la compréhension de l’intention de conception et des trade-offs reste insuffisante
• Avec le temps, ce problème pourrait conduire à une perte de confiance

Pourquoi les développeurs seniors ont de la valeur

• Si les développeurs expérimentés coûtent cher, ce n’est pas parce qu’ils écrivent du code rapidement, mais parce qu’ils ont appris au fil du temps ce qu’il ne faut pas faire
• Ce que les entreprises paient réellement, c’est cette reconnaissance des schémas d’échec née d’expériences comme prendre de mauvaises décisions d’architecture et vivre avec leurs conséquences, ou être réveillé à 2 heures du matin pour un incident en production
• Aujourd’hui, de nombreux développeurs juniors sautent précisément cette étape en s’appuyant sur l’IA

5 stratégies

• 1. Apprendre correctement les fondamentaux

  • Il faut savoir ce qu’est un bon code pour pouvoir évaluer ce que produit l’IA ; sinon, on finit par accepter ses sorties aveuglément
  • Livres recommandés : Head First Design Patterns (comprendre les patterns de code et les raisons de les choisir) et Designing Data-Intensive Applications (les principes de conception des systèmes orientés données)

• 2. Étudier des cas d’incident

  • Il est recommandé de lire les documents de post-mortem détaillés publiés lors d’incidents majeurs par Cloudflare, AWS, Azure, Google et d’autres grands services
    • On y trouve la cause, l’analyse de la cause racine, la méthode de correction et les mesures de prévention de récidive
  • Chez Amazon, on parle de COE (Correction of Errors), et la plupart des grandes entreprises tech, comme Facebook, ont aussi des documents internes comparables
  • Comprendre comment un système complexe s’est effondré marque bien plus durablement que la simple lecture de documentation

• 3. Provoquer volontairement la difficulté

  • Avant l’IA, résoudre soi-même les problèmes n’était pas une option mais la norme ; désormais, il existe une échappatoire disponible 24 h/24
  • Avant de coller une erreur dans l’IA, il faut d’abord lire la stack trace, suivre le code, vérifier les logs et formuler une hypothèse sur ce qui ne va pas
    • C’est ainsi que se construit un véritable instinct de débogage
    • On peut faire appel à l’IA ensuite
  • Participer à l’astreinte et prendre les tickets que personne ne veut traiter est la manière la plus efficace d’apprendre comment fonctionnent réellement les systèmes

• 4. Ne jamais mettre en production du code que l’on ne comprend pas

  • Si, en code review, on vous demande pourquoi vous avez choisi une certaine approche et que vous répondez « l’IA l’a suggérée », vous perdez immédiatement toute crédibilité
    • Le problème n’est pas d’avoir utilisé l’IA, mais de ne pas avoir fait l’effort de comprendre le code que l’on soumet
  • Pour chaque ligne que l’on commit, il faut pouvoir expliquer pourquoi cette bibliothèque, pourquoi ce pattern, et quels sont les trade-offs
  • Même si cela ralentit, la compréhension doit passer avant tout ; se forger une réputation de simple copieur-colleur est très difficile à rattraper

• 5. Prompter le « pourquoi » plutôt que la réponse

  • Au lieu de demander uniquement une solution à l’IA, il faut lui demander plusieurs approches et l’explication de leurs avantages et inconvénients respectifs
  • Cela produit deux effets :
    • on apprend réellement les trade-offs
    • comme l’IA déroule son raisonnement, sa recommandation elle-même peut changer, ce qui permet parfois d’obtenir une meilleure réponse

Un conseil réaliste face à la pression de la vitesse : équilibrer productivité et apprentissage

• La crainte de se faire distancer en ralentissant est réaliste, mais il n’est pas nécessaire d’arrêter complètement de produire
• Il faut pratiquer cet apprentissage volontaire et inconfortable pendant les temps calmes, les side projects ou les tickets moins exposés à la compétition
• Il faut distinguer consciemment le temps passé à construire de vraies compétences et le temps passé à simplement produire des sorties

Utiliser l’IA comme tuteur

• Nous disposons aujourd’hui d’un tuteur IA capable d’expliquer n’importe quoi au niveau de profondeur souhaité, ce que les générations précédentes de développeurs n’avaient pas
• Il ne faut pas seulement faire exécuter du travail à l’IA, mais l’utiliser de façon à demander des explications et la faire enseigner
• La valeur d’un développeur ne réside pas dans sa capacité à produire du code, mais dans sa capacité à regarder n’importe quel code et à juger s’il est bon ou non

• Que le code ait été généré ou non par l’IA, la compétence essentielle est la capacité à distinguer le bon du mauvais
• Seuls l’apprentissage délibéré et l’accumulation d’expériences d’échec peuvent forger une compétitivité durable à long terme