Ingénieur full-stack

Vous livrez des fonctionnalités de bout en bout. L'agent écrit le code ; vous concevez l'architecture, vous spécifiez, vous validez et vous portez le résultat. Vous bougez vite sur toute la pile parce que l'agent n'a pas de préférences de pile, et vous avez cessé d'en avoir aussi.

Elevationprimary Convergencesecondary Emergencepartial

Famille

Ingénierie

Rôle hérité équivalent

Ingénieur full-stack, Senior Software Engineer, Staff Engineer (filière IC)

Relève de

Tech Lead, Engineering Manager, ou Directeur de l'ingénierie

Collabore avec

Tech Lead · Designer produit · Chef de produit · Superviseur d'agents

Le travail

Vous livrez des fonctionnalités. Bout en bout signifie bout en bout : couche de données, API, front-end, tests, déploiement, observabilité. Pas parce que vous faites tout personnellement, mais parce que vous portez le résultat et que l'agent gère la couche dont le travail a besoin.

Au quotidien, vous :

Spécifiez complètement les fonctionnalités. Critères d'acceptation, cas limites, implications de données, comportement UX, classification de risque, points de validation. La spécification est l'artefact qui permet à l'agent d'exécuter sans supervision en temps réel.
Menez des dialogues de clarification avec l'agent avant l'exécution. Vous répondez aux questions qui résolvent une véritable ambiguïté, reportez celles auxquelles on doit répondre pendant l'implémentation, et rejetez celles qui signalent une spécification vague.
Concevez l'architecture au niveau de la fonctionnalité. Décisions de modèle de données, forme de l'API, frontières de composants, choix de dépendances : à vous de les faire, à l'agent de les implémenter.
Examinez les PR produites par l'agent. Au Niveau 2, ligne par ligne. Au Niveau 3, au niveau du diff et du comportement. Vous cherchez le cas manquant, la mauvaise abstraction, la rupture silencieuse, pas les coquilles.
Validez à des points de validation gradués par le risque. Échantillonnage pour les changements réversibles. Approbation directe pour les irréversibles. Vous concevez les points de validation pour vos fonctionnalités au moment de les spécifier.
Recalibrez quand les histoires bloquent. Les mauvaises implémentations sont habituellement un symptôme d'une mauvaise spécification ou d'un mauvais contexte. Vous diagnostiquez, re-spécifiez et reprenez, au lieu de déboguer la sortie de l'agent.
Maintenez le contexte de la base de code. Modèles de prompts partagés, fichiers de contexte, guides de style maison, bibliothèques de scénarios. Ce sont des artefacts de premier ordre ; vous y contribuez et les utilisez.
Portez l'observabilité de ce que vous livrez. Télémétrie, alertes, budgets d'erreur. Vous les concevez dans la spécification ; l'agent les implémente ; vous vérifiez que le signal est réel.
Pairez avec des ingénieurs adjacents sur les décisions transversales. L'agent absorbe une grande partie de ce qui demandait des transferts entre spécialistes, mais le jugement humain reste meilleur à deux.

À quoi ressemble le succès

Résultats concrets à ce niveau :

Débit. Vous livrez des fonctionnalités en jours, pas en sprints. Les histoires se complètent (spec → implémente → revue → fusion) en heures à jours pour le travail typique.
Qualité. Les défauts en production de vos fonctionnalités sont rares et orientés à la baisse. Le réviseur agent attrape ce que vous auriez attrapé manuellement ; vos interventions attrapent le reste.
Discipline de coût. La dépense en tokens par PR fusionnée est suivie. Le coût par résultat s'améliore au fil du temps, pas seulement le débit absolu.
Travail transversal. Vous livrez des fonctionnalités qui touchent front-end, back-end et infrastructure dans la même semaine. L'agent gère la couche ; vous gérez le jugement.
Santé de la base de code. Le refactorage se fait, la dette technique se paie, la base de code vieillit bien plutôt que de s'ossifier.

Ce qui ne compte pas comme succès : lignes de code livrées, nombre de PR, heures consignées, points de vélocité de sprint qui ne se traduisent pas en résultats utilisateur.

Ce qui rend ce travail intéressant

L'intéressant n'est pas la vitesse : c'est ce qui devient possible à cette vitesse.

Vous livrez plus vite que vous ne le pensiez possible. Ce qui vous prenait un sprint prend un jour. La fonctionnalité que vous avez spécifiée mardi matin est en production mercredi après-midi. La boucle de rétroaction avec l'utilisateur se ferme dans la semaine, et vous la sentez.

Le full-stack devient naturel. Vous cessez d'avoir des préférences de pile parce que l'agent n'en a pas. Vous bougez fluidement entre les décisions de modèle de données, la conception d'API et le comportement UX parce que la friction du changement de contexte sur la pile est tombée près de zéro. La récompense est une véritable largeur de portée.

Vous concevez plus, vous tapez moins. La majeure partie de votre métier vit maintenant dans la spécification et les décisions d'architecture, pas dans la frappe. Pour les ingénieurs qui sont entrés dans le métier parce qu'ils aimaient la partie conception plus que la partie frappe, c'est un retour à ce qui était amusant.

Les problèmes difficiles sont les satisfaisants. Câbler un nouvel endpoint CRUD prend des minutes. Les problèmes qui vous restent sont ceux qui demandent du jugement : bien faire une machine à états, choisir la frontière entre deux domaines, décider quoi tester et quoi faire confiance. Ce sont les problèmes qui distinguent l'ingénierie sénior de l'ingénierie junior, et c'est l'essentiel de ce qui reste.

Vous collaborez avec un autre agent, pas seulement d'autres humains. Travailler avec un agent capable est une compétence en soi, différente de la programmation en pair, différente du travail solo. Les dialogues de clarification sont intéressants en eux-mêmes. Les sessions de recalibrage aussi.

Vous voyez votre travail dans le monde rapidement. Des fonctionnalités en production en heures après la spécification signifie que votre sens d'agence dans le rôle est plus fort qu'il ne l'a été depuis des années pour la plupart des ingénieurs séniors. Le délai entre la pensée et l'impact s'est compressé.

Ce qui peut ne pas plaire. Vous écrivez moins de code à la main. L'état de flux des heures de codage profondément concentré arrive moins souvent, et quand ça arrive, c'est dans des endroits inhabituels (sessions de recalibrage, travail d'infrastructure que l'agent ne fait pas encore bien). Les frontières entre « votre travail » et celui de l'agent s'estompent ; si votre identité d'artisan est enracinée dans la production personnelle de l'artefact, cette identité devra migrer. Certains ingénieurs trouvent une version plus profonde de la satisfaction dans le nouveau travail ; d'autres non. Soyez honnête avec vous-même sur le genre d'ingénieur que vous êtes.

Qui s'épanouit dans ce rôle

Les aptitudes qui comptent le plus au Niveau 3 sont différentes de celles qui définissaient l'ingénierie sénior avant l'IA.

Vous pensez avant de taper. La vitesse de frappe a cessé de compter ; la qualité de pensée en amont compte beaucoup. Vous vous arrêtez pour considérer les cas limites avant de spécifier ; vous ne faites pas de correspondance de patron pour plonger.

Vous écrivez clairement. Les spécifications sont d'abord de l'écriture, ensuite du codage. Les gens dont le raisonnement écrit est flou écrivent des spécifications floues et obtiennent des sorties floues.

Vous êtes à l'aise d'être responsable de résultats que vous n'avez pas personnellement produits. L'agent a écrit le code ; vous avez signé ; s'il échoue, vous le portez. Les gens qui peuvent tenir cette responsabilité sans microgérer l'agent s'épanouissent.

Vous gérez bien le diagnostic désordonné. Quand une histoire bloque, la cause est habituellement dans la spécification ou le contexte, pas dans le code. Le travail de détective (comprendre quelle hypothèse a cassé) fait partie du métier maintenant. Les gens qui aiment ça trouvent le travail riche ; ceux qui veulent des problèmes propres avec des réponses propres peinent.

Vous avez du goût. Quand l'agent produit trois implémentations plausibles, vous savez laquelle est la bonne pour cette base de code. Le goût est difficile à interviewer et plus difficile à enseigner, mais c'est l'avantage le plus durable au Niveau 3.

Vous tenez aux systèmes, pas seulement aux fonctionnalités. Les fonctionnalités s'enchaînent. Les ingénieurs qui s'épanouissent dans la durée sont ceux qui font attention à comment la base de code vieillit, quels patrons reviennent, ce que la prochaine décision architecturale doit anticiper.

Moins essentiel qu'avant : vitesse brute de codage, trivia d'algorithmes, pédantisme de langage, capacité à garder cinq fichiers en tête. C'étaient les marqueurs de l'ingénierie sénior avant l'IA. Ils aident encore. Ils ne sont plus ce qui différencie le rôle.

Compétences à développer pour y arriver

Les aptitudes ci-dessus décrivent la disposition. Les compétences ci-dessous sont ce que vous construisez activement.

Ingénierie de spécification. Écrire des spécifications qu'un agent peut exécuter de bout en bout. Critères d'acceptation, cas limites, classification de risque, points de validation. Comment pratiquer : écrivez la spécification avant tout code, même pour les petites tâches. Relisez vos spécifications un mois plus tard ; celles qui ont mal vieilli sont votre matériel d'apprentissage. Voir le Guide de spécification.

Jugement de revue au niveau du diff. Lire la sortie de l'agent pour repérer le cas manquant, la mauvaise abstraction, la rupture silencieuse, sans lire chaque ligne. Comment pratiquer : révisez les PR générées par l'IA de votre équipe. Articulez pourquoi vous repousseriez. Suivez les retours qui se sont avérés faux ; c'est là que votre jugement est mal calibré.

Diagnostic recalibrage vs débogage. Quand le travail bloque, savoir si le problème est dans la spécification, le contexte ou l'implémentation. Comment pratiquer : tenez un court journal des histoires bloquées. Classifiez chaque post-mortem comme recalibrage (problème de spec ou de contexte) ou débogage (problème d'implémentation). Suivez quelles interventions ont réellement débloqué.

Classification de risque. Distinguer le travail réversible de l'irréversible et assigner le bon point de validation. Comment pratiquer : pour chaque histoire que vous spécifiez, nommez les points explicitement. Justifiez pourquoi. Ajustez à mesure que vous apprenez des mauvaises classifications. Voir Standards d'exécution IA.

Jugement transversal. Prendre de bonnes décisions hors de votre spécialité historique. La convergence au Niveau 3 signifie qu'un ingénieur sénior avec une formation back-end peut maintenant porter des fonctionnalités face à l'utilisateur de bout en bout. Comment pratiquer : lisez les PR dans les domaines adjacents (front-end, infra, données). Remarquez ce qui vous semble confus ; l'écart est votre surface d'apprentissage. Pairez avec la personne dont c'était la spécialité.

Métier du dialogue de clarification. Q&R productive avec l'agent avant l'exécution. Savoir auxquelles répondre pleinement, lesquelles reporter, lesquelles signalent une spécification floue. Comment pratiquer : remarquez les questions qu'un agent pose avant d'implémenter. Catégorisez-les. La catégorisation vous montrera où vos spécifications ont besoin de travail.

Tri des contexte. Maintenir les modèles de prompts partagés, fichiers de contexte et bibliothèques de scénarios dans lesquels les agents de l'équipe puisent. Comment pratiquer : contribuez une amélioration par sprint. Les artefacts composent ; les petites contributions comptent.

Choisissez une compétence, pratiquez-la pendant deux semaines sur du vrai travail, et remarquez comment votre relation au rôle bouge. Tenter de développer les sept à la fois est le mode d'échec le plus courant.

En quoi ce rôle diffère du Senior Engineer hérité

Senior Engineer hérité (avant l'IA)	Senior Engineer (IA-natif)
Écrit du code complexe vous-même ; révise celui des autres	Écrit des spécifications ; révise la sortie de l'agent à des points de validation gradués par le risque
Se spécialise en front-end, back-end ou infrastructure	Opère sur toute la pile parce que l'agent le fait
Passe 50 à 70 % du temps à coder	Passe moins de 20 % du temps à coder
Débit limité par les heures de concentration individuelles	Débit limité par la qualité de spécification et le jugement de revue
Transferts vers les spécialistes pour le travail transversal	Pair avec des spécialistes sur le jugement, livre seul sur toute la pile
Les meilleurs ingénieurs sont les producteurs les plus rapides et prolifiques	Les meilleurs ingénieurs sont les spécificateurs les plus clairs et les réviseurs les plus discernants
Tests écrits ligne par ligne par les humains	Scénarios de test spécifiés par les humains, écrits par l'agent, revus par les humains

Le rôle n'est pas un « sénior » renommé. Le quotidien est structurellement différent.

Quels patrons d'évolution des rôles sont à l'œuvre

Élévation (principal). Le centre de gravité du rôle se déplace de l'exécution vers la spécification et la validation. La valeur migre de la vitesse de frappe vers la qualité de spécification et le jugement de revue.
Convergence (secondaire). Les frontières entre front-end, back-end et infrastructure s'estompent. Un ingénieur sénior au jugement solide peut diriger l'agent sur toute la pile pour une fonctionnalité qui exigeait auparavant la coordination de trois spécialistes.
Émergence (partiel). Certaines responsabilités sont véritablement nouvelles : dialogues de clarification avec les agents, sessions de recalibrage, contributions à la configuration du réviseur agent.

Spécialisation et absorption ne s'appliquent pas significativement : le rôle s'étend plutôt que de se resserrer, et ne se contracte ni ne disparaît.