Pendant quarante ans, l'ingénieur 10X a été un argument, pas une observation. Des études ont mis en évidence des écarts dix fois supérieurs entre programmeurs sur la même tâche, la méthodologie a été contestée pendant des décennies, et l'expression est surtout devenue une façon de dire « recrutez des gens comme moi ». Tout le monde débattait de l'existence de cette personne, mais tout le monde s'accordait sur ce qu'il fallait mesurer : la production.
Placez trois ingénieurs sur le même backlog aujourd'hui et observez-les pendant une matinée. Le premier n'utilise pas du tout l'IA. Bon ingénieur, lit tout, code tout. Le deuxième a un agent ouvert dans une fenêtre : invite, attente, lecture, nouvelle invite. Le troisième a quatre git worktrees ouverts avec un agent dans chacun, l'un sur une fonctionnalité, un autre sur un bogue, un troisième en train de revoir une pull request, un quatrième en train d'écrire des tests de bout en bout, et passe de l'un à l'autre en vérifiant ce que chacun a produit. À l'heure du déjeuner, le troisième a accompli ce que le premier finira jeudi.
Le prochain ingénieur 10X est le troisième. Ce qu'il fait, c'est prendre un ticket vague, le transformer en une modification livrée dont il peut répondre, et utiliser des agents pour comprimer la partie qui consistait autrefois à taper. Deux ensembles de compétences rendent cela possible : les fondamentaux qui ont toujours existé, et les compétences agent qui n'existaient pas il y a trois ans.
Il faut aussi énoncer l'évidence, et le livre blanc dont s'inspire cet article le dit clairement : l'IA a rendu certains ingénieurs moins compétents. Le deuxième ingénieur de la scène matinale produit plus qu'il y a deux ans et en comprend parfois moins.
Les chiffres qui sous-tendent tout cela proviennent de nos propres livraisons. Sur les projets Miyagami, 80 à 90 % du code de production est désormais écrit par un modèle, et un projet qui nécessitait dix ingénieurs en 2024 fonctionne aujourd'hui avec quatre. Nous n'y sommes pas arrivés par un projet pilote ; c'est ce vers quoi ont convergé deux ans de travail pour des clients, et c'est pourquoi recruter les bons ingénieurs compte aujourd'hui plus que jamais. Quand quatre personnes portent ce que dix portaient, un mauvais recrutement cesse d'être une erreur d'arrondi.
À quoi ressemble le travail quand les lignes de code sont peu coûteuses ? Il y a trois ans, la journée d'un ingénieur senior consistait à choisir un ticket, écrire le code, écrire un test, ouvrir une PR, passer au ticket suivant, et la plupart des heures étaient consacrées à écrire du code à la main. Désormais, les tickets sont découpés en un plan, le plan en morceaux suffisamment petits pour que chaque PR soit lisible en une seule session, et ces morceaux sont confiés à des agents en parallèle. Les heures vont à décider ce qu'il faut construire, à fournir le bon contexte à l'agent, et à s'assurer que le résultat est sûr à livrer. Un agent construit ce qu'on lui soumet, si bien qu'une lacune dans les entrées apparaît dans les sorties dans l'heure : une exigence floue revient sous la forme de quelque chose d'assuré, de plausible et fondé sur une supposition ; un contexte manquant revient sous la forme d'hypothèses erronées sur votre système ; des tests insuffisants laissent passer du code généré tout en ignorant silencieusement le comportement qu'ils n'ont jamais couvert.
Ce recadrage explique pourquoi le deuxième ingénieur de la scène matinale n'est pas non plus la réponse, et la distinction mérite d'être précisée. Un AI-native engineer, tel que nous utilisons ce terme, est un développeur full-stack doté de solides fondamentaux en qualité de code, en conception de systèmes et en sécurité, qui dirige des agents de codage sur la manière de produire des sorties et valide ces sorties avant leur mise en production. Les fondamentaux viennent en premier dans cette phrase pour une raison : si vous ne pouvez pas raisonner sur le système sans l'agent, vous ne pouvez pas savoir quand l'agent a tort. Et si vous ne pouvez pas revoir le code correctement, l'agent ne vous rend pas senior. Il vous rend plus rapide à produire des choses que vous ne comprenez pas. Un AI-native engineer n'est pas un prompteur, quelqu'un qui utilise un agent comme on utiliserait un moteur de recherche, une fenêtre, une requête à la fois, on accepte et on passe à l'invite suivante.
Ce qui est gênant pour les responsables techniques, c'est que cette différence est invisible là où le recrutement cherche habituellement. Elle n'est pas dans le CV, car tout le monde a « AI » sur son CV désormais. Elle n'est pas dans le test à faire chez soi, car les deux rendus ont été écrits par un modèle et paraissent identiques à l'écran. Elle n'est pas dans une conversation sur les outils, car la personne qui utilise des prompts a lu les mêmes articles que vous. La différence devient visible en quelques minutes en regardant quelqu'un travailler dans une vraie base de code, et c'est précisément ce que la plupart des processus de recrutement ne font jamais.
Nous avons écrit The Next 10X Engineer parce que nous avions cette conversation en tête-à-tête avec un CTO après l'autre. Le document explique en quoi consiste le métier aujourd'hui, ce que signifie AI-native et ce que cela ne signifie pas, pourquoi l'ancien processus de recrutement a cessé de fonctionner, et les deux sessions de travail qui l'ont remplacé : l'une testant les fondamentaux sans IA dans la salle, l'autre testant les compétences en mode agent avec les outils activés, chacune accompagnée de la grille d'évaluation que nous remplissons pendant la session. C'est le processus que chaque ingénieur que nous plaçons doit suivre, conçu et toujours animé par notre CTO.
La question que cela pose à un responsable est simple : si le multiplicateur est désormais quelque chose que vous pouvez observer, et que votre processus n'a jamais une seule fois regardé un candidat travailler avec un agent, que mesure réellement votre recrutement ?
Téléchargez The Next 10X Engineer pour accéder à l'argumentation complète, aux deux évaluations et aux deux grilles d'évaluation.
