Comment devenir un ingénieur IA 30x doté de goût

• À l’ère où l’IA génère du code en masse, la compétence clé qui distingue la valeur d’un ingénieur n’est ni la vitesse, ni le savoir, ni l’expérience, mais le « goût » (taste), c’est-à-dire la capacité de jugement sur ce qu’il faut construire
• Les membres de l’équipe OpenAI Codex sont parvenus indépendamment à la même conclusion, et toute personne dotée d’un bon goût logiciel peut devenir un ingénieur 10x
• Le goût se divise en trois formes — reconnaissance (recognition)·boussole (compass)·vision (vision) — qui convergent toutes vers un même mécanisme : la qualité de la fonction d’évaluation interne
• La valeur se concentre dans cinq domaines : choix du problème, architecture système, jugement de qualité, empathie utilisateur, communication
• Maintenant que l’écriture de code est devenue une commodité, le jugement et la réflexion constituent la véritable compétence de fond, qu’il faut cultiver intentionnellement

---

Le monde a changé, mais la plupart des ingénieurs ne l’ont pas remarqué

• En mars 2025, le CEO d’Anthropic, Dario Amodei, a prédit que l’IA écrirait 90 % du code en quelques mois ; à l’époque, cela paraissait absurde
• Boris Cherny, créateur de Claude Code, a indiqué qu’en décembre 100 % du code qu’il avait commit était écrit par l’IA, et qu’il n’avait pas ouvert son IDE une seule fois
• Andrej Karpathy, qui qualifiait les outils de coding IA de « slop », a complètement inversé sa position en décembre
  • « Je ne me suis jamais senti aussi dépassé comme programmeur, et le métier est en train d’être radicalement restructuré »
  • DHH, créateur de Ruby on Rails, a reconnu que sa résistance venait du fait que « les modèles n’étaient pas encore assez bons », et que la situation s’était désormais inversée
  • Le CTO de Vercel, Malte Ubl, a déclaré que « le coût de production du logiciel converge vers 0 »
• Entre novembre et décembre 2025, Opus 4.5, GPT-5.2 et Gemini 3 ont franchi un seuil de capacité invisible, permettant à l’IA d’atteindre le niveau d’ingénieurs expérimentés sur un large éventail de tâches, avec un temps réduit de plusieurs heures à quelques minutes
• Quand la génération de code devient une commodité, ce qui reste, c’est le software engineering (décomposition des problèmes, décision sur ce qu’il faut construire, conception des tests, de la fiabilité et de la montée en charge, arbitrage des trade-offs) — autrement dit, le goût

Qu’est-ce que le goût, concrètement ?

• Le goût tel qu’en parlent les meilleures équipes d’ingénierie a trois définitions, qui sont en réalité trois angles sur une même capacité

• Le goût comme reconnaissance (Recognition)

  • La capacité à sentir laquelle de deux implémentations est meilleure avant même de pouvoir expliquer pourquoi
  • Emma Tang : savoir si un système est réellement propre, extensible, sans redondance et simple à comprendre relève du goût
  • Comme un chef qui goûte une sauce et sait qu’il manque de l’acidité avant même de l’identifier consciemment, le pattern matching agit plus vite que le raisonnement conscient
  • Exemple de l’équipe Codex qui a choisi Rust plutôt que TypeScript pour sa CLI
    • Les deux fonctionnent, mais ils ont perçu que les contraintes de Rust (typage fort, gestion explicite de la mémoire, dépendances minimales) produisaient, au-delà des avantages techniques, un effet sur la culture d’ingénierie
    • Le jugement n’était pas « le langage techniquement supérieur », mais « le langage qui façonne les comportements souhaités dans l’équipe »
  • Mauvais goût : choisir Rust parce que c’est à la mode ou parce qu’un blog dit que c’est rapide, sans comprendre les effets de second ordre

• Le goût comme boussole (Compass)

  • La forme évoquée par Tibo quand il dit qu’un ingénieur doit avoir « sa propre boussole » : non pas évaluer ce qui existe déjà, mais savoir quoi construire ensuite
  • L’ingénieur qui dit « ce n’est pas la bonne fonctionnalité » avant d’écrire une seule ligne de code
  • Exemple de Boris Cherny qui a réalisé en deux jours environ 20 prototypes de la fonctionnalité de todo list de Claude Code
    • Il a testé des todo inline, une UI en drawer, une pill interactive, un affichage en bas d’écran, etc., puis a convergé vers une forme qui semblait non pas arbitraire mais inévitable
    • Après coup, il pouvait expliquer pourquoi la version finale était meilleure, mais cette insatisfaction initiale envers les versions intermédiaires était déjà un goût faisant office de boussole
  • Le goût-boussole est plus rare que le goût-reconnaissance, car il opère plus en amont que l’exécution

• Le goût comme vision (Vision)

  • Exprimé par la formule de SQ Mah selon laquelle « l’humain définit l’évolution », c’est la forme la plus difficile : savoir non pas ce qui est bon maintenant, mais ce qui deviendra important dans deux ans
  • Peter Steinberger, créateur d’OpenClaw, fait tourner 5 à 10 agents en parallèle et consacre l’essentiel de son temps à l’architecture et à la conception système
    • Il explique que « la majeure partie du code n’est qu’une transformation de données ennuyeuse » et qu’il faut concentrer son énergie sur la conception des systèmes
  • La prochaine priorité de l’équipe Codex est la planification fondée sur un contexte riche, nécessitant des informations hors du codebase comme les objectifs business, la dynamique du marché ou les priorités d’équipe
    • Ce n’est pas la vision appliquée à un meilleur générateur de code, mais à une stratégie produit orientée vers un futur où le modèle comprend pourquoi le logiciel existe

• Définition unifiée

  • Les trois formes convergent vers un même mécanisme : le goût est la qualité de la fonction d’évaluation interne
  • Dans la reconnaissance, la fonction d’évaluation s’applique au résultat final ; dans la boussole, aux possibilités et à la direction ; dans la vision, au futur et à la trajectoire
  • Dans un monde où l’IA génère le code, le travail humain devient l’évaluation (décider quoi construire, juger si le résultat est suffisant, détecter le moment où l’architecture doit changer), et cette évaluation devient le métier lui-même

Pourquoi certains ingénieurs gagnent-ils beaucoup plus que d’autres ?

• Avant l’IA, les écarts de rémunération s’expliquaient par trois facteurs : l’entreprise, l’ancienneté et la spécialité ; l’IA est en train de brouiller ces trois variables
• Dans les startups, l’écart entre un excellent ingénieur et un ingénieur moyen est passé de 3x à 10x, car le premier utilise l’IA pour produire l’équivalent d’une petite équipe
• L’axe de l’ancienneté se déplace : l’expérience d’écriture de code compte moins que l’expérience du bon jugement
  • La valeur de « connaître React » diminue, tandis que celle de « savoir concevoir un système fiable sous charge » augmente
• Les ingénieurs qui créent les plus grands écarts ont en commun de prendre des décisions qui s’accumulent avec un effet composé
  • Une bonne décision d’architecture peut économiser plusieurs mois de travail sur une année
  • Une bonne décision produit peut déterminer si une fonctionnalité sera réellement adoptée ou non
• Même en travaillant plus dur, on peut produire deux fois moins de valeur qu’une personne au goût supérieur ; faire tourner 2 agents sur le bon problème crée plus de valeur que d’en faire tourner 8 sur le mauvais
• Dans le cas d’OpenAI, les ingénieurs les plus productifs ne généraient pas simplement plus de code : ils réorientaient leur temps vers les échanges avec les utilisateurs, la direction produit et l’empathie
  • Certains sont toutefois revenus à l’autocomplétion par onglet en disant qu’ils « perdaient leur sens du codebase » ; les deux réactions sont valables

Là où la valeur est réellement créée

• Il existe cinq domaines où le goût crée une valeur disproportionnée, alors que la plupart des ingénieurs ne sont compétitifs que dans un ou deux domaines

• Zone 1 : choix des problèmes

  • Choisir quoi faire est la décision de goût au plus fort effet de levier, mais la plupart y réfléchissent à peine
  • Les ingénieurs qui ont du goût se demandent : « Si je résous bien ce problème, est-ce que cinq autres disparaissent ? »
  • Peter Steinberger échange longuement avec l’agent pour affiner le plan, le challenger et le contredire, puis ne lance l’agent que lorsqu’il est satisfait ; le plan est le travail, l’exécution est déléguée
  • Dans le système d’autorisations de Claude Code, au lieu d’un RBAC complexe et de politiques granulaires, ils ont choisi l’approche la plus simple (demander l’autorisation puis mémoriser la réponse) afin de lancer vite et de façon intuitive

• Zone 2 : architecture système

  • C’est la manière dont les pièces s’emboîtent, le domaine où la demi-vie du goût est la plus longue : une bonne décision rapporte encore deux ans plus tard, une mauvaise s’accumule en dette technique qui impose une réécriture
  • La décision de construire la boucle d’agent de Codex comme une machine à états, celle de Claude Code d’écrire « le moins de logique métier possible », ainsi que l’obsession d’OpenClaw pour l’extensibilité modulaire, sont toutes des décisions de goût architectural
  • Boris Cherny : « À chaque nouveau modèle, on supprime plein de code et on garde le moins de code possible autour du modèle »
    • La plupart des équipes ajoutent du code à chaque release, mais l’équipe Claude Code en retire ; le modèle est le produit et tout autour doit rester aussi fin que possible

• Zone 3 : jugement de qualité

  • C’est savoir si c’est assez bon pour sortir ou s’il faut encore travailler, un domaine où l’IA ne peut pas aider (car elle ne sait pas ce que veut dire « assez » dans un contexte donné)
  • Revue de code hiérarchisée chez Codex : le code non critique est relu uniquement par l’IA, tandis que le code critique de l’agent exige une revue humaine
    • Le goût consiste à savoir quel code est important : le système d’autorisations a besoin d’yeux humains, pas une mise à jour du README
  • L’équipe Codex écrit presque tout le code avec des prompts, alors que d’autres départements internes tournent plutôt autour de 70 % ; les 30 % écrits à la main sont les parties où le jugement de qualité compte le plus (« règle des 30/70 »)

• Zone 4 : empathie utilisateur

  • Comprendre ce dont l’autre humain a réellement besoin est le domaine où l’IA est la plus faible
  • Les messages de chargement contextuels de Claude Code conçus par Boris (qui montrent ce que fait le modèle au lieu d’une simple animation) n’avaient été demandés par personne, mais ont été créés pour marquer la différence entre une attente sans information et une attente informée
  • Les valeurs par défaut du sandbox de Codex relèvent aussi de l’empathie utilisateur ; Tibo : « Même si cela nuit au taux d’adoption, on ne recommande pas par défaut quelque chose qui pourrait ne pas être sûr »
    • Cela suppose de comprendre que beaucoup d’utilisateurs « ne sont pas si techniques » et peuvent faire par erreur quelque chose d’irréversible ; ils ont choisi la sécurité plutôt que la commodité

• Zone 5 : communication et storytelling

  • C’est la manière de cadrer ce qu’on a construit, un domaine que les ingénieurs sous-estiment constamment alors que le marché le récompense
  • L’OpenClaw de Peter Steinberger a enregistré davantage de recherches Google pendant sa semaine virale que Claude Code et Codex réunis
    • Un nom clair, une démo convaincante et le récit « une seule personne produit autant qu’une équipe » ont porté sa diffusion
  • Le fichier AGENTS.md de Codex (un README destiné aux agents IA, pas aux humains) montre qu’ils ont compris que le lecteur de la documentation avait changé et ont adapté le format en conséquence

Exemples de goût (et de son absence)

• Choix de la stack technique

  • Sans goût : « TypeScript, parce que c’est le plus populaire et que tout le monde le connaît », justification par habitude
  • Avec goût : Boris a choisi TypeScript parce qu’il est « on distribution » pour les modèles Claude (le modèle le maîtrise déjà bien), optimisant pour les forces du modèle plutôt que pour le confort de l’équipe
    • Codex a choisi Rust parce qu’il voulait un minimum de dépendances « qui oblige à réfléchir aux standards d’ingénierie qu’on a fixés » et qu’on peut inspecter directement ; même décision au fond, mais dans les deux cas fondée sur des contraintes concrètes, pas sur une préférence générale

• Gérer du code qu’on ne comprend pas complètement

  • Sans goût : « Ça a été généré par l’IA et les tests passent, donc on met en production », sans réflexion sur la suffisance des tests ni sur la maintenabilité
  • Avec goût : Peter met en production du code qu’il n’a pas lu, mais pas de manière négligente ; « je connais l’emplacement et la structure des composants, ainsi que l’architecture globale du système, et c’est généralement suffisant »
    • Tests, linting et CI locale servent de couches de validation ; d’un côté c’est un pari, de l’autre un système qui garantit structurellement la justesse

• Répondre aux demandes de fonctionnalités

  • Sans goût : implémenter selon le ticket, livrer, puis passer au suivant
  • Avec goût : Boris a créé 20 prototypes en deux jours avant le lancement ; ce n’est pas de la lenteur, mais une expérimentation rapide pour naviguer vers la bonne solution, et le sentiment d’inévitabilité est l’empreinte du goût

• Concevoir pour les agents IA

  • Sans goût : un README classique avec guide de configuration et endpoints API
  • Avec goût : Codex rédige un AGENTS.md qui explique à l’IA comment explorer la codebase, quelles commandes de test lancer et comment respecter les standards, en structurant la codebase de façon inévitablement favorable à la réussite du modèle

• Faire face à un afflux de PR

  • Sans goût : laisser le même processus de revue alors que les PR générées par l’IA affluent, ce qui surcharge les reviewers et fait baisser la qualité
  • Avec goût : l’équipe d’Emma Tang exige que les PR incluent le prompt ; sinon, elle demande sur Slack : « c’était quoi le prompt ? »
    • Dans un monde piloté par l’IA, il est plus utile de relire l’intention que le code ; Peter appelle les PR des « prompt requests » et s’intéresse davantage au prompt de génération qu’au code lui-même, car si l’unité de génération change, l’unité de revue doit changer aussi

Plan pour cultiver son goût (pas seulement l’admirer)

• Le conseil « accumule plus d’expérience » est aussi inutile que « fais plus de sport » ; voici plutôt un plan sur 90 jours, structuré en trois formes

• Mois 1 : construire un goût de la perception par exposition structurée

  • Le mécanisme consiste en une forte exposition à des variations de qualité, suivie d’une réflexion délibérée
  • Semaines 1 à 2 : étudier 10 outils de développement que vous admirez
    • Installez Codex CLI, Claude Code, Linear, Supabase, le dashboard Stripe, Vercel, Tailwind, Railway, Resend, ainsi qu’un produit non logiciel (une exposition de musée bien conçue ou le menu d’un restaurant)
    • Pour chacun, écrivez pendant 15 minutes : qu’avez-vous remarqué dans les 60 premières secondes, qu’est-ce qui vous a plu, qu’est-ce qui vous a troublé, quelle décision aimeriez-vous reprendre
    • Les bons outils montrent le résultat dans les 30 premières secondes avant d’expliquer le processus ; les mauvais expliquent l’architecture avant de montrer pourquoi il faudrait s’y intéresser
  • Semaines 3 à 4 : étudier 10 articles de recherche, non pour les découvertes mais pour la méthodologie
    • Le papier original sur le score BLEU, l’article d’Anthropic sur Constitutional AI, l’article de Google sur PageRank, le compte rendu du Netflix Prize, les articles sur les Scaling Laws
    • Écrivez : ce qui rend la méthodologie élégante, l’intuition unique qui la fait fonctionner, et comment l’appliquer à votre domaine
    • Vous constaterez que des principes structurels reviennent d’un domaine à l’autre : critères d’évaluation clairs, exposition honnête des limites, formulations simples plutôt que complexité

• Mois 2 : construire un goût-boussole par discernement actif

  • Exercice hebdomadaire « Side-by-Side » : trouver deux exemples de même nature et écrire 500 mots sur pourquoi l’un est meilleur que l’autre (deux documentations d’API, deux blogs techniques, deux diagrammes d’architecture, deux frameworks d’évaluation)
    • Interdiction de dire « je préfère » ; il faut toujours préciser un mécanisme concret avec « c’est meilleur parce que… »
    • Exemple : la documentation Stripe est meilleure parce qu’elle est structurée autour de ce que le développeur veut faire (envoyer un paiement, gérer les erreurs), et non autour de l’architecture interne
  • Exercice quotidien « Practice Noticing » : chaque fois que vous regardez un outil, un article ou du code, choisissez une décision du créateur et notez en une phrase : « pourquoi ça plutôt que l’alternative évidente ? » ; au bout de 30 jours, les motifs qui émergent dans ces 30 observations forment un goût en développement

• Mois 3 : construire un goût de la vision par application générative

  • Semaine 9 : repenser quelque chose qui vous appartient (flux d’onboarding de l’équipe, README d’un projet, developer experience d’un pipeline d’évaluation) à partir de ce que vous avez appris
  • Semaine 10 : écrire le texte le plus précis que vous ayez jamais produit, non pas le plus long ni le plus exhaustif, mais un texte où chaque paragraphe fait sa part et change la manière de penser du lecteur
  • Semaine 11 : concevoir un système depuis zéro et expliquer chaque décision non par habitude mais par premiers principes (« microservices parce que c’est une bonne pratique » non, mais plutôt « équipe de 4 personnes, trafic prévisible, simplicité de déploiement plus importante que des bénéfices de scalabilité inutiles avant 18 mois, donc monolithe »)
  • Semaine 12 : partager votre goût, enseigner la différence entre deux approches et écrire un AGENTS.md pour votre propre codebase ; la capacité à encoder le goût dans les systèmes et la documentation distingue le talent individuel de la capacité organisationnelle

Cinq projets pour développer rapidement son goût

• 1. Construire un framework d’évaluation pour le code généré par l’IA

  • Non pas un linter ou un test runner, mais un framework qui répond à la question « ce code IA est-il suffisamment prêt pour la production ? », avec une définition de sa propre grille d’évaluation (exactitude, maintenabilité, efficacité, sécurité, style)
  • L’appliquer et le noter sur 50 PR réellement générées par l’IA, recalibrer la grille à partir des scores surprenants, publier les résultats, et développer le goût de la Zone 3 (jugement de qualité)

• 2. Repenser l’onboarding d’un projet open source

  • Forker un outil dont on respecte la technique mais dont l’onboarding est frustrant, repenser les 5 premières minutes de l’expérience développeur, rédiger le README et le guide de démarrage, et structurer le tout pour qu’un nouveau contributeur puisse soumettre une PR dès le premier jour
  • Construire simultanément la Zone 4 (empathie utilisateur) et la Zone 5 (communication)

• 3. Construire un « test de goût » pour l’équipe

  • Rédiger 10 paires d’approches d’implémentation, où dans chaque paire l’une reflète un meilleur goût, puis demander à 5 ingénieurs laquelle est meilleure et pourquoi
  • Le résultat intéressant n’est pas la bonne réponse, mais le désaccord d’opinion : c’est dans les écarts de standards que naissent bugs, dette technique et retouches ; on construit ainsi le goût organisationnel au plus fort effet de levier

• 4. Lancer un produit avec une contrainte de 48 heures

  • Non pas un prototype, mais un produit fonctionnel que d’autres peuvent utiliser ; la contrainte de temps force en permanence des décisions de goût (ce qu’il faut inclure et ce qu’il faut couper)
  • Si l’on passe 6 heures sur une mauvaise fonctionnalité, on brûle un quart du temps disponible ; les conséquences des mauvaises décisions sont donc immédiates

• 5. Écrire un blog technique qui change la façon de penser

  • Non pas un tutoriel ou un guide pratique, mais un texte qui recompose un concept familier pour que le lecteur le voie ensuite différemment (comprendre que le goût est en soi une évaluation, ou considérer que supprimer du code à chaque sortie de modèle n’est pas une habitude mais une philosophie d’architecture)
  • Construire la Zone 5 (communication et storytelling), car un point de vue authentique est le fondement de tout goût

Optimiser sa carrière autour du goût

• Arrêter la compétition sur la vitesse

  • Si l’IA écrit du code à vitesse machine, la compétition sur la vitesse de codage est un jeu perdu d’avance ; une personne qui réfléchit 30 minutes aux 50 lignes réellement nécessaires a plus de valeur qu’une autre qui en génère 500 par heure
  • La vitesse d’implémentation est devenue une commodité ; ce qui ne l’est pas, c’est le jugement sur ce qu’il faut implémenter et comment

• Investir dans les « compétences adjacentes » dont le goût a besoin

  • Le point commun des meilleurs ingénieurs est qu’ils ne sont pas de simples codeurs : Boris est fondateur de startup, Emma a dirigé l’infrastructure de données chez Stripe pendant 4 ans, Peter a fait de PSPDFKit un business mondial
  • Le goût a besoin de matière première : réflexion produit, sens du design, compréhension business et capacité de communication sont les matériaux qui rendent le goût possible

• Choisir des rôles où le goût est récompensé

  • Les rôles qui consistent à implémenter des spécifications bien définies récompensent la vitesse, tandis que ceux où l’on décide quoi construire, comment le construire et quand c’est suffisant récompensent directement le goût
  • Rôles où le goût est particulièrement récompensé : ingénieur fondateur en startup early-stage, tech lead en entreprise produit, ingénieur plateforme ou infrastructure qui conçoit les systèmes sur lesquels s’appuient les autres ingénieurs, ingénieur developer experience, ingénieur staff+ traitant des décisions d’architecture transverses

• Construire des réalisations publiques qui incarnent le goût

  • À l’ère de l’IA, le portfolio compte plus que le CV ; la preuve réside dans les réalisations (un projet open source bien conçu, un blog technique avec un point de vue cohérent, un produit que des gens utilisent réellement)
  • OpenClaw de Peter parle plus fort que n’importe quel CV, et les prototypes Claude Code de Boris démontrent bien mieux son goût que n’importe quelle réponse en entretien comportemental

La vérité inconfortable

• Le goût est inégalement réparti et le restera ; certains ont cultivé, à travers des milliers de décisions sur 15 ans, une avance au départ qu’un plan sur 90 jours ne peut pas rattraper
  • L’équipe Codex travaille dans une entreprise qui construit des modèles avec un accès illimité aux tokens, et Peter a un point de départ atypique avec 20 ans d’expérience et une entreprise revendue
• Cependant, l’écart entre « pas de goût » et « un peu de goût » a un impact énorme sur une carrière, et peut être comblé ; le saut d’une personne qui reçoit des tickets et implémente à une autre qui propose quoi construire à partir de recherche utilisateur, puis le fait implémenter par l’IA jusqu’aux tests et à l’architecture, c’est précisément cela, le goût
• L’aveu honnête de Gergely Orosz : « J’ai l’impression qu’on m’arrache soudain quelque chose de précieux ; il m’a fallu beaucoup d’efforts pour bien coder, et mes meilleurs souvenirs restent ces moments d’immersion à taper des idées »
  • Le sentiment de perte face au recul du hand-coding est réel, mais la capacité à savoir quel code doit exister, comment il doit être structuré et à quel moment c’est suffisant a toujours été la vraie compétence
• Les ingénieurs qui prospéreront ensuite sont ceux qui l’auront compris : le goût a toujours fait partie du métier, il était simplement caché dans le code, et l’IA, en prenant en charge la saisie, le met désormais en lumière

[clastneo]

Eh ben, maintenant 10x ne suffit même plus, il faut réfléchir au 30x lol

[channprj]

Moi aussi, j’aimerais bien ne plus voir ce genre d’expressions un peu exagérées comme les ingénieurs « x fois meilleurs »… T_T
Ça se donne des airs de quantitatif, mais au fond c’est aussi une manière qualitative d’exprimer les choses.