Ingénieur logiciel expérimenté

Faire une modification dans une base de code vaste et ancienne où les contraintes ne sont pas documentées et vivent dans ce que des décisions antérieures ont déjà engagé.

Lire du code que vous n'avez pas écrit et pour lequel vous n'étiez pas là, et décider s'il est juste — à un volume qui monte à mesure que la génération devient moins chère.

Choisir une structure, et choisir quels modes de défaillance accepter — savoir ce qui se passe à trois heures du matin quand une dépendance est tombée et que la moitié des requêtes sont déjà en vol.

Être la personne qui dit que cela sort maintenant, avec ce risque connu, et qui en répond ensuite.

Une relecture qui enseigne, le travail en binôme, et la transmission délibérée du contexte — le mécanisme par lequel une équipe continue d'avoir des gens capables de juger.

Fixer ce qu'un agent de code automatisé peut faire sans surveillance, ce sur quoi il doit demander, et où sa production entre dans la branche — puis être le nom attaché à ce réglage.

Des mainteneurs expérimentés sur de grands dépôts matures qu'ils connaissent bien (environ 5 ans chacun) ; les outils étaient principalement Cursor Pro avec Claude 3.5/3.7 Sonnet. Les auteurs affirment explicitement ne pas prétendre que le résultat se généralise à la plupart des développeurs, ni au travail sur projet neuf ou de junior.

Un échec, un retour en arrière, une réglementation ou un coût freine l'adoption. Cela peut abaisser une appréciation ou élargir son incertitude.

Vous n'êtes pas encore sur cette page, et la route qui y mène est justement ce qui est sous pression — lisez d'abord la page du junior. Ce qui compte le plus ici est que la capacité que ce métier vend est un jugement sur un système précis, et cela s'acquiert en étant dedans, non en utilisant de meilleurs outils.

Le constat mesuré de cette page est que les outils ne vous ont pas accéléré sur votre propre base de code, et que vous avez peut-être cru le contraire. Prenez cela comme une raison de mesurer votre propre travail plutôt que comme une assurance : l'essai est petit et vieux d'un an, et la part du métier qui croît n'est pas la frappe — c'est relire ce qui arrive, et répondre de ce qu'un agent a eu le droit de faire.

Rester et se renforcer

Devenez la personne à qui l'on fait confiance pour dire non

À mesure que les modifications générées se multiplient, la contrainte passe à qui peut en refuser une avec une raison qui tient. Cette autorité se gagne en ayant raison en public, à répétition, sur un système précis.

Refaçonner le poste

Prenez la propriété de ce que les agents peuvent faire

Quelqu'un doit décider ce qu'une modification automatisée a le droit de toucher et où elle entre. Dans la plupart des équipes, personne n'a reçu cela, raison pour laquelle cela apparaît dans les rapports d'incident plutôt que dans les fiches de poste.

Mouvement latéral

Allez là où l'exactitude coûte cher par la loi

Paiements, systèmes critiques pour la sécurité, données réglementées — des endroits où une modification sans surveillance n'est pas permise, si bien que la relecture et la responsabilité sont financées plutôt que supposées.

Changement de secteur

Passez du côté du problème

Ingénierie de solutions, produit technique, expérience développeur — des postes où la valeur est de comprendre à la fois un système et ce que quelqu'un en attend, et où l'écriture n'a jamais été la partie rare.

Le seul essai randomisé que ce site détient a trouvé l'inverse, et le détail à retenir est l'écart entre la mesure et la perception : seize mainteneurs expérimentés de projets ouverts travaillant sur de vrais tickets dans des dépôts qu'ils connaissaient ont mis 19 % plus de temps avec des outils de 2025, tout en estimant avoir été 20 % plus rapides. Les auteurs ne prétendent pas que cela décrive la plupart des développeurs ni les projets neufs, et c'est vieux d'un an. Ce que cela établit, c'est que le gain de vitesse n'est pas automatique sur une base de code mûre, et que se le demander à soi-même ne tranche pas la question.

Personne ne peut répondre par un chiffre, et les réponses assurées des deux camps vendent quelque chose. Une question plus utile est quelle partie du métier, parce que les parties bougent à des vitesses différentes : écrire du code de routine est déjà largement fait par machine, relire ce qu'il a produit est devenu un métier à part entière, et décider ce qui part avec un risque connu n'a pas bougé parce que c'est de la responsabilité et non de la capacité. Surveillez plutôt un signal vérifiable par vous : quelle part de votre semaine consiste désormais à lire du code que vous n'avez pas écrit.

C'est exposé autrement, non plus sûr, et les deux sont liés d'une façon qui mérite d'être vue. L'emploi des 22 à 25 ans les plus exposés à l'IA a reculé d'environ 11 % entre fin 2022 et mi-2026, et plusieurs organisations qui ont coupé le recrutement de juniors ont dit publiquement avoir supprimé la voie par laquelle on devient senior. Une profession qui cesse de fabriquer des seniors a un problème d'approvisionnement plus tard, non une garantie de sécurité maintenant — et entre-temps le travail d'enseignement qui se répartissait sur une équipe retombe sur moins de personnes.

Ce site ne peut pas encore répondre, et le dire est plus utile que de deviner. Ces trois voies ont une exposition réellement différente, mais nous ne détenons aucune preuve qui les sépare — les enregistrements ici distinguent par séniorité, non par pile technique, parce que c'est ainsi que les études ont été conçues. Prenez tout classement assuré du frontal contre le serveur pour l'impression de quelqu'un. Ce que la preuve soutient, c'est de choisir selon le coût d'une erreur dans votre domaine, ce qui traverse les trois.

Relire du code que vous n'avez pas écrit, et savoir dire pourquoi vous avez rejeté quelque chose. Cette compétence a toujours été présente dans le métier et n'a jamais été ce sur quoi on recrutait ou évaluait ; c'est désormais le goulot, parce que la génération a déplacé le travail de produire vers juger. C'est aussi la capacité qui fait de vous la personne à qui l'on peut faire confiance pour dire non, soit la part de ce métier sans substitut en vue.