#agentic builder#Agentic Product Engineer#identité professionnelle#catégorisation occupationnelle#centralité identitaire#pendule de levier#oscillation amortie#produit vs ingénierie
Résumé
Donn Felker, responsable de la plateforme IA chez Polygon, ancien de Tinder et spécialiste Android pendant dix ans, publie le 14 septembre 2026 un essai sur la disparition du génie logiciel tel qu'il l'a pratiqué. Il date sa prise de conscience de juillet 2025, par trois faits. Il a construit un SaaS complet sans écrire une ligne de code. Chez Tinder, un prompt de deux mille mots a exécuté en dix minutes une migration de bibliothèque de threading qui prenait six à huit heures par instance, sans erreur. Enfin, il a vu des non-techniciens livrer des produits réels : un directeur financier a bâti son outil d'opérations financières avec l'application Claude, un gérant de salle de sport sa plateforme de coaching. Sa conclusion : il ne s'agissait jamais de coder mais d'exécuter, le code n'était qu'un péage.
L'essai explique ensuite l'anxiété des ingénieurs par deux notions de psychologie sociale. La catégorisation occupationnelle résume une personne à son métier ; la centralité identitaire professionnelle fait de ce métier le socle de sa valeur. Quand le travail quotidien passe à un agent, l'identité vacille : être distancé ou entraîner son remplaçant.
It was never about coding, it's about the ability to execute
— Donn Felker , donnfelker.substack.com
Felker propose l'image d'un pendule de levier entre produit et ingénierie. L'agent déplace le levier initial vers le produit, qui obtient un prototype en un après-midi. Mais la complexité et l'échelle ramènent le levier vers l'ingénierie : un CFO bloqué après deux mois dans une même session Claude Cowork sans savoir où vit son code, un photographe dont l'application Base44 stockait ses médias sur Google Drive à un coût de transfert intenable. L'ingénieur corrige, pose architecture et garde-fous, puis rend la main. Chaque oscillation s'amortit, jusqu'à la prochaine version de modèle.
Le rôle qui se dessine au point d'équilibre est celui de l'agentic builder, hybride d'ingénieur et de responsable produit. Les purs spécialistes des deux extrêmes sont donnés comme menacés. Le parcours proposé comporte deux étapes : codifier son savoir en skills et procédures exécutables par des agents, ce qui rend l'individu scalable et le fait passer d'opérateur à orchestrateur ; puis adopter une pensée de système, business pour l'ingénieur, ingénierie pour le non-technicien, avec une liste de six exigences à formuler à l'agent : architecture, garde-fous, sauvegardes, versionnement, gouvernance, observabilité.
L'auteur fixe un horizon de six mois pour opérer la transition et conclut sur la figure du bâtisseur capable de lire un bilan comptable et une trace d'exécution.
À retenir
Trois déclencheurs datés de juillet 2025. un SaaS complet sans écrire de code ; un prompt de 2 000 mots — « which we'd now call a Skill » — qui exécute en 10 minutes une migration de bibliothèque de threading que chaque instance coûtait 6 à 8 heures à un ingénieur, répétée des centaines de fois dans la base de code de Tinder ; des non-techniciens qui livrent des produits. Le récit de bascule rejoint celui de [[cherny-sequoia-coding-is-solved-loops-printing-press-2026-05]].
Formule centrale.« Coding was just a gatekeeper. » Ce qui sépare les rêveurs des faiseurs est la capacité d'exécution ; le code n'en était que le péage.
Le cadre identitaire. la catégorisation occupationnelle compresse une personne en un rôle (« Android Developer ») ; la centralité identitaire professionnelle en fait le socle de la valeur perçue. D'où le double bind formulé : ne pas utiliser l'IA, c'est être distancé ; l'utiliser, c'est entraîner son remplaçant.
Le pendule de levier. avant l'IA, l'ingénierie fixait le rythme et détenait le levier ; l'agent déplace le levier initial vers le produit (un MVP en un après-midi). La complexité, l'échelle et l'économie des systèmes le ramènent vers l'ingénierie, qui corrige, pose architecture et garde-fous, puis le rend au produit. Chaque retour est plus court — damped oscillation — mais une nouvelle version de modèle relance le mouvement.
Deux cas où le pendule revient. un CFO qui a construit son outil financier dans une seule session Claude Cowork pendant deux mois, jusqu'à saturation de l'environnement, sans savoir où vit son code (retrouvé dans un dépôt GitHub privé) ; un photographe qui a branché Google Drive comme stockage de médias dans une application Base44, choix que l'agent a suivi sans objection et que les frais de transfert rendaient intenable. L'agent « will follow your lead ».
Analogie de l'entraîneur. bouger suffit au début, puis on plafonne ou on se blesse ; l'ingénieur corrige la forme et fixe le programme, puis s'efface ; les visites suivantes sont plus courtes.
Le rôle qui émerge. ni ingénieur ni produit, mais les deux — « the engineer who thinks like a product person and the product person who thinks like an engineer ». Côté ingénierie, le titre proposé est Agentic Product Engineer. Les purs spécialistes des deux extrêmes sont donnés comme exposés ; les spécialistes profonds subsistent mais avec des compétences hors de leur domaine. Cette cartographie des rôles peut se lire avec [[ng-ai-engineering-skills-map-2026-08-14]].
Parcours en deux étapes, commun aux deux profils. (1) codifier son savoir en skills, templates et procédures exécutables par des humains ou des agents — « you're making yourself scalable », passage d'opérateur à orchestrateur ; (2) passer de la pensée de spécialiste à la pensée de système, ce que l'auteur nomme complexité cognitive.
Pour l'ingénieur. lâcher l'identité liée à un langage ou une plateforme (l'auteur n'a pas touché Android ni Kotlin depuis six mois), traiter chaque compétence comme une brique Lego, arbitrer build vs buy en tenant compte de la maintenance, penser ROI, acquisition, rétention. Position voisine de celle d'[[osmani-google-new-sdlc-vibe-coding-agentic-engineering-2026-05]] sur le passage à l'ingénierie agentique.
Pour le non-technicien. demander à l'agent à chaque blocage, et exiger six choses qu'il ne sait pas demander seul — architecture maintenable, garde-fous, sauvegardes, contrôle de version, gouvernance, observabilité. Recommande d'installer un Destructive Command Guard.
⚠️ Le délai de six mois est répété trois fois sans justification ; il fonctionne comme un ressort rhétorique, pas comme une prévision étayée.
Premier geste conseillé. lister ce qu'on fait manuellement et qu'on redoute, en choisir une chose, demander à Claude ou ChatGPT « help me turn this into a skill » et se laisser interviewer. Cinq minutes.
Chiffres clés
migration de bibliothèque de threading chez Tinder ramenée de 6-8 heures à 10 minutes par un prompt de 2 000 mots, juillet 2025