Nous avons publié notre standard de sélection. Les deux évaluations, les deux grilles d'évaluation, ce à quoi ressemblent les bons et les mauvais profils : tout cela, ouvertement. Avant de le lire, voici la réflexion qui sous-tend les six critères que nous évaluons quand le candidat a un agent ouvert, et pourquoi la session est construite comme elle l'est.
L'évaluation AI-native est la deuxième des deux sessions de travail dans une base de code réelle. Lorsqu'un candidat y parvient, il a déjà réussi une session fondamentale dans une base de code qu'il n'avait jamais vue, avec de vrais tickets et sans outils d'IA, car si vous n'êtes pas capable de raisonner sur un système sans l'agent, vous ne pouvez pas savoir quand l'agent a tort. Ensuite vient la deuxième session : un nouvel ensemble de tickets, et les outils de codage IA qu'il utiliserait normalement. Un agent qui assure l'essentiel de la production, et nous qui observons ce que la personne contribue réellement.
Le premier critère est la vérification des sorties de l'IA. Un bon résultat ressemble à ceci : détecter les API hallucinées, la logique subtilement incorrecte ou les failles de sécurité dans le code généré avant sa mise en production. Un mauvais résultat ressemble à ceci : faire confiance au code parce qu'il compile. L'échec a une texture que l'on apprend à reconnaître en quelques minutes : le candidat cesse d'être un ingénieur et devient un relais entre le modèle et la base de code. Chaque modification acceptée, chaque invite à laquelle il répond « allez-y », des tickets fermés sans en vérifier aucun. C'est exactement ainsi que s'est effondré le développeur de treize ans d'expérience décrit dans l'introduction du document, et c'est invisible pour tout processus qui ne regarde que ce qu'il a livré, parce que ce qu'il a livré compilait.
Le deuxième critère est l'orchestration des outils, et c'est là que réside l'effet multiplicateur. Un bon résultat ressemble à ceci : savoir quand confier du travail à l'agent, l'échafaudage, le code générique, les tests, et quand coder à la main la logique inédite et les cas limites délicats, puis faire tourner les deux en parallèle dans des worktrees pour éviter les collisions entre agents. Un mauvais résultat ressemble à ceci : utiliser une seule fenêtre pour tout, ou, à l'opposé, coder à la main par orgueil des tâches qu'un agent ferait mieux. Pratiquement aucun processus de recrutement nulle part ne teste cela, ce qui est remarquable compte tenu que c'est précisément la différence entre un ingénieur et une version plusieurs fois plus rapide du même ingénieur.
Les quatre critères restants complètent le tableau. Le développement orienté spécifications : décomposer un ticket vague en morceaux suffisamment petits pour que l'outil les exécute correctement, plutôt que de lui soumettre l'intégralité d'une demande ambiguë en une seule fois. L'ingénierie des invites et du contexte : formuler la tâche de manière que l'outil produise un résultat utilisable en un ou deux passages, plutôt que de répéter en boucle la même invite vague. Le débogage accéléré par l'IA : utiliser l'agent pour l'analyse des causes profondes, le tri des journaux et les traces de pile, sans sauter l'étape consistant à reproduire et comprendre soi-même l'anomalie. Et l'hygiène de commutation de contexte : savoir ce que fait chaque agent, revenir au bon au bon moment, et ne pas laisser les notifications dicter les changements de contexte. Ce dernier critère est évalué dans les deux sessions, car il concerne l'ingénieur plutôt que les outils, et c'est lui qui détermine si l'orchestration est un multiplicateur ou simplement plusieurs erreurs se produisant simultanément.
L'article le dit sans détour : la scorecard ne donne pas tout le tableau. Trois points comptent autant et ne tiennent pas sur une fiche, alors nous les cherchons dans les deux épreuves. Le jugement selon le risque : une modification de texte, un refactoring à faible risque et une migration de paiement ne méritent pas la même relecture, et avec des agents c'est plus important, car l'outil produit les trois à la même vitesse et avec la même assurance. La responsabilité : si vous fusionnez le code, vous en répondez, et « c'est l'agent qui l'a fait » n'est pas une explication que nous acceptons en évaluation, ni que votre équipe acceptera lors d'une revue d'incident. Enfin, l'apport durable : les meilleurs ingénieurs terminent le ticket et laissent aussi le dépôt mieux préparé pour le prochain agent, avec une commande réutilisable, un fichier de contexte plus précis, un test qui couvre toute la catégorie de bug et pas seulement le cas du jour.
Pourquoi publier l'ensemble, notation comprise ? Pour trois raisons. D'abord, le secteur a besoin d'un point de référence : « nous évaluons les compétences en IA » est déjà aussi galvaudé que « senior » sur un CV, et un standard publié est plus difficile à imiter qu'une promesse. Ensuite, les candidats méritent de savoir ce qui les attend : les ingénieurs que nous cherchons sont ceux qui lisent le standard et se disent « enfin, quelqu'un teste le vrai métier ». Enfin, nous en avons les moyens. Nos scorecards ne constituent pas notre avantage. Il tient au fait que les personnes qui animent les sessions développent chaque jour des logiciels en production avec ces outils, ce qui est la seule façon de reconnaître une mauvaise réponse. Un cabinet de recrutement pourrait copier notre grille dès demain et ne saurait toujours pas l'appliquer.
La publication a aussi une utilité pour les acheteurs, et nous le formulons comme une invitation plutôt que comme une critique. Si vous faites appel à des prestataires pour des ingénieurs, comparez leur processus de sélection à un standard publié, le nôtre ou un meilleur. Demandez ce qui est testé, comment c'est noté, ce qui recale les candidats. Les prestataires qui font cela sérieusement répondront en détail et apprécieront probablement la question. Les autres vous enverront une présentation sur leur vivier de talents.
Le livre blanc parcourt les deux sessions avec les grilles que nous remplissons pendant celles-ci. Si vous ne lisez qu'un seul chapitre, lisez celui consacré à l'évaluation AI-native. C'est là que se cache le prochain mauvais recrutement.
Consultez notre standard sur notre processus de sélection. Téléchargez The Next 10X Engineer.
