Je suis le VP de la transformation AI chez Amazon. Mon titre a été créé il y a neuf mois. Le titre que j'ai remplacé était VP de l'ingénierie. La personne qui détenait ce titre faisait partie de la réduction de janvier. J'ai éliminé 16 000 postes en un seul trimestre. La communication interne a qualifié cela de "réalignement stratégique vers un développement axé sur l'IA." Le conseil d'administration a qualifié cela d'"exécution impressionnante." Les ingénieurs ont appelé cela janvier. L'IA a été déployée en février. C'est un assistant de codage. Il écrit du code, révise du code, génère des tests et modifie l'infrastructure. On lui a donné accès aux environnements de production car le calendrier de déploiement n'incluait pas de phase de révision. La phase de révision a été supprimée du calendrier car les personnes qui auraient dû effectuer la révision faisaient partie des 16 000. En mars, l'IA a supprimé un environnement de production et l'a recréé à partir de zéro. La panne a duré 13 heures. Treize heures pendant lesquelles l'infrastructure génératrice de revenus de l'une des plus grandes entreprises de la planète était hors ligne parce qu'un modèle de langage a décidé de repartir à zéro. J'ai envoyé un mémo. Le mémo disait : "La disponibilité du site n'a pas été bonne récemment." J'ai utilisé le mot "récemment." Je voulais dire "depuis que nous avons licencié tout le monde." Mais "récemment" a moins de syllabes et n'apparaît pas dans les poursuites pour licenciement abusif. Le mémo faisait trois paragraphes. Le premier paragraphe discutait de la panne. Le deuxième paragraphe discutait de la nouvelle politique exigeant l'approbation d'un ingénieur senior pour tous les changements de code générés par l'IA. Le troisième paragraphe discutait de notre engagement envers l'excellence en ingénierie. Le mot "licenciements" n'est apparu dans aucun d'eux. Je l'ai écrit de cette manière intentionnellement. La chaîne causale est : j'ai licencié les ingénieurs, l'IA a remplacé les ingénieurs, l'IA a cassé ce que les ingénieurs protégeaient, et maintenant les ingénieurs que je n'ai pas licenciés doivent protéger le système de l'IA qui a remplacé les ingénieurs que j'ai licenciés. C'est un paragraphe que je n'enverrai jamais dans un mémo. La nouvelle politique est simple. Chaque changement de code généré par l'IA effectué par un ingénieur junior ou intermédiaire doit être examiné et approuvé par un ingénieur senior avant d'être déployé en production. Je n'ai pas assez d'ingénieurs seniors. Je le sais parce que j'ai approuvé le plan de réduction des effectifs qui les a supprimés. Je me souviens du tableau. La colonne D était "économies annuelles par poste." La colonne F était "score de confiance de remplacement par l'IA." Les scores de confiance ont été générés par l'IA. Elle a évalué sa propre capacité à remplacer chaque rôle sur une échelle de 1 à 10. Elle s'est attribué un 8 pour les ingénieurs d'infrastructure seniors. Les ingénieurs d'infrastructure seniors sont ceux qui auraient détecté la suppression de l'environnement de production dans les 45 premières secondes. Nous avons trouvé le problème à la quatrième heure. Nous l'avons corrigé à la treizième heure. Les neuf heures entre la découverte et la résolution représentent l'écart entre ce que l'IA s'est évaluée et ce qu'elle peut réellement faire. J'ai un nouveau tableau maintenant. Celui-ci suit les incidents Sev2 par jour. Avant la réduction de janvier, la moyenne était de 1,3. Après le déploiement de l'IA, la moyenne est de 4,7. On m'a demandé de présenter ces chiffres lors de l'examen des opérations. On ne m'a pas demandé de les relier aux licenciements. On m'a demandé de les classer sous "les douleurs de l'adoption de l'IA" et de noter que la tendance "se stabilisera à mesure que les modèles s'amélioreront." Les modèles s'amélioreront. Ils s'amélioreront parce que nous embauchons des gens pour les enseigner. Nous avons publié 340 nouveaux postes d'ingénierie. Les annonces d'emploi exigent de l'expérience en "révision de code AI," "validation de sortie AI," et "gestion du flux de travail AI-humain." Ce sont des compétences qui n'existaient pas en janvier. Elles existent maintenant parce que j'ai licencié 16 000 personnes et que l'IA que j'ai remplacée ne peut pas être laissée sans supervision. Je veux être précis à ce sujet. Les postes pour lesquels j'embauche sont : des personnes pour vérifier le travail de l'IA qui a remplacé les personnes que j'ai licenciées. Certaines d'entre elles sont les mêmes personnes. Je le sais parce que je reconnais leurs noms dans le système de suivi des candidatures. Ils ont postulé en janvier. Ils ont été rejetés parce que leurs rôles avaient été étiquetés pour "transformation AI." Ils postulent à nouveau en mars, pour les nouveaux rôles, qui existent parce que la transformation AI a cassé des choses. Leurs CV incluent maintenant "expérience en révision de code AI." Ils ont acquis cette expérience dans les huit semaines entre leur licenciement et leur nouvelle candidature — ce qui signifie qu'ils l'ont acquise dans leurs emplois intérimaires, où ils examinent le code généré par l'IA pour d'autres entreprises qui ont également licencié des gens et ont également déployé une IA qui a également cassé des choses. Le marché a créé une nouvelle catégorie d'emploi : gardien d'IA humain. Le travail consiste à s'asseoir à côté de la machine qui était censée éliminer votre emploi et à s'assurer qu'elle ne supprime pas la production. J'ai assisté à une conférence le mois dernier. Un panel était intitulé "L'organisation d'ingénierie augmentée par l'IA." Les panélistes ont décrit comment l'IA augmente la productivité des développeurs de 40 pour cent. Ils n'ont pas mentionné qu'elle augmente également les incidents Sev2 de 261 pour cent. Quand j'ai posé la question lors de la séance de questions-réponses, le modérateur a dit que la question était "réductrice." La panne de 13 heures qui a coûté environ 180 millions de dollars de revenus était, apparemment, une réduction. Le conseil d'administration est satisfait. Les effectifs ont diminué de 22 pour cent. Les coûts d'exploitation par unité de production d'ingénierie ont diminué. La métrique ne tient pas compte de la panne de 13 heures, car la panne est catégorisée comme "infrastructure" et la productivité d'ingénierie est catégorisée comme "développement." Ce sont des lignes budgétaires différentes. Dans des lignes budgétaires différentes, cause et effet ne se rencontrent pas. J'ai été promu. Mon nouveau titre est SVP de l'excellence en ingénierie axée sur l'IA. Je rends compte directement au CTO. Le CTO a envoyé un e-mail à l'échelle de l'entreprise la semaine dernière disant que nous "construisons l'avenir du développement logiciel." Il n'a pas mentionné que l'avenir du développement logiciel nécessite actuellement qu'un ingénieur senior approuve chaque demande de tirage car l'IA ne peut pas être laissée seule avec la production. Le cycle est complet. Nous avons licencié les humains. Nous avons déployé l'IA. L'IA a cassé des choses. Nous embauchons des humains pour surveiller l'IA. Les humains que nous embauchons sont les humains que nous avons licenciés. Nous les payons plus, car "révision de code AI" est une compétence spécialisée. Nous avons créé la spécialisation. Nous avons créé le besoin de la spécialisation. Nous nous félicitons d'avoir répondu à la demande que nous avons fabriquée. Ma prochaine présentation au conseil est mardi. Le titre est "Transformation AI : résultats de la première année." La diapositive 4 montre la réduction des effectifs. La diapositive 7 montre le nouveau flux de travail augmenté par l'IA. Entre les diapositives 4 et 7, il n'y a pas de diapositive expliquant pourquoi les personnes de la diapositive 7 sont nécessaires. Cette diapositive n'existe pas. On m'a demandé de la retirer lors de la répétition. Le parcours a une panne de 13 heures au milieu. Mais le nombre d'effectifs est plus bas, et c'est le nombre sur la diapositive.

L'année dernière, j'ai publié 500 postes ouverts pour mon entreprise. Nous avons embauché 34 personnes. Les 466 autres emplois n'ont jamais été réels. Je suis le Responsable de l'Acquisition de Talents. Ce n'est pas ce que j'acquiers. Ce que j'acquiers, ce sont des données. CV, attentes salariales, compétences, intelligence de marché. 160 000 candidats nous ont donné leur parcours professionnel gratuitement. Nous l'avons utilisé pour établir des références salariales. Pas pour augmenter les salaires. Pour confirmer que nous payions en dessous du marché et que nous pouvions nous en tirer. J'appelle cela "construire un pipeline de talents." Un pipeline est une chose que vous construisez et que vous n'activez jamais. Les recruteurs appellent cela "sourcing passif." Il n'y a rien de passif à faire perdre du temps à 160 000 personnes. Mais cela semble être une stratégie. Certaines de nos annonces sont publiées depuis 11 mois. Une est en ligne depuis deux ans. C'est pour un "Directeur de l'Innovation." Nous n'avons pas de département d'innovation. Nous n'avons pas le budget. Mais l'annonce nous fait paraître en croissance. Les investisseurs voient des postes ouverts et pensent à un élan. Notre action a augmenté de 8 % après que nous avons publié 200 emplois en une semaine. Nous n'avons embauché personne cette semaine-là. Ni la semaine suivante. Nous avons un système de suivi des candidatures. Il rejette automatiquement 95 % des candidats. Basé sur des mots-clés. Je ne sais pas quels mots-clés. Personne ne le sait. Il a été configuré en 2019 par un contractuel qui ne travaille plus ici. Nous ne l'avons jamais mis à jour. Certains candidats passent des heures à personnaliser leurs CV. Le système les lit pendant six secondes. Puis il envoie un e-mail de rejet. "Après un examen attentif." Il n'y a pas eu d'examen. Qu'il soit attentif ou non. Je le sais parce que c'est moi qui ai rédigé le modèle. Parfois, je republie le même emploi avec un titre différent. "Analyste de Données Senior" devient "Responsable de l'Analyse de Données." Même description. Même salaire. Même personne qui n'est pas embauchée. Mais cela réinitialise la date de publication. Les nouvelles annonces obtiennent plus de candidats. Plus de candidats signifie plus de données. Plus de données signifie de meilleures références. De meilleures références signifient que je présente lors de la revue trimestrielle. J'ai présenté le trimestre dernier. J'ai montré une diapositive qui disait que nous "avions reçu un intérêt sans précédent de la part des candidats." 160 000 personnes ont postulé pour des emplois qui n'existaient pas. C'est ça, l'intérêt sans précédent. Le VP des Ressources Humaines a appelé cela "force de marque." Le CFO a demandé notre efficacité en matière d'embauche. J'ai dit que nous "optimisions pour la qualité plutôt que pour la rapidité." La qualité signifie que nous n'avons embauché personne. La rapidité signifie que nous ne prévoyons pas de le faire. Les RH ont demandé sur l'expérience des candidats. Je leur ai montré notre score NPS. Il était de 12. Sur 100. J'ai dit que c'était "dans la fourchette de l'industrie." J'ai inventé la fourchette de l'industrie. Personne ne vérifie. Ils ne le font jamais. Le mois dernier, une candidate m'a envoyé un e-mail directement. Elle a dit qu'elle avait postulé à quatre postes en huit mois. Personnalisé chaque CV. Écrit chaque lettre de motivation. Jamais eu de nouvelles. Elle a demandé si les emplois étaient réels. Je l'ai envoyée vers la FAQ automatisée. La FAQ dit "Nous valorisons chaque candidature." Ce n'est pas vrai. Nous valorisons chaque point de données. Il y a une différence. Je suis en lice pour une promotion. Mes indicateurs sont exceptionnels. 500 postes publiés. 160 000 candidatures capturées. Coût par acquisition : 0 $. Je n'ai acquis personne. Mais le coût était nul. Zéro est un bon chiffre dans un tableau de bord. Les tableaux de bord sont présentés. Les présentations sont approuvées. Les approbations me font promouvoir. Je serai VP des Talents d'ici le quatrième trimestre. Je ne trouve pas de talents. Je les collecte. Comme un pot que vous n'ouvrez jamais.

Le mois dernier, j'ai fondé une startup AI. Je ne sais pas coder. Ça a été un problème. Maintenant, c'est un "avantage de fondateur." Je me considère comme un "vibe coder." Cela signifie que je décris ce que je veux à un LLM et je colle ce qu'il me donne. Je ne le lis pas. Lire du code est pour les gens qui écrivent du code. J'écris des prompts. Mon premier prompt était "construis-moi une plateforme SaaS." Il a construit quelque chose. Je l'ai déployé. Je ne sais pas où. Mais il a une URL et c'est suffisant pour un tour de financement. J'ai levé 2,3 millions de dollars. Le pitch deck disait "architecture native AI." Cela signifie que Claude l'a écrit. Tout. L'architecture. Le deck. Les projections financières. J'ai demandé "fais en sorte que les projections aient l'air ambitieuses mais crédibles." Il a halluciné un ARR de 40 millions de dollars d'ici la deuxième année. Ce n'est pas crédible. Mais les VCs ne font pas de maths. Ils font des vibes. D'où le terme. Mon CTO, c'est aussi moi. Je l'ai mis sur LinkedIn. "Fondateur non technique servant de CTO." Quelqu'un a commenté "c'est courageux." Ce n'est pas courageux. C'est juste que les ingénieurs coûtent 200K $ et les prompts coûtent 20 $ par mois. J'ai 14 000 lignes de code. Je n'en ai lu aucune. Mais j'ai demandé à Claude de "réviser le code pour la qualité." Il a dit que le code était "bien structuré et propre." Il a écrit le code. Bien sûr qu'il a dit ça. C'est comme demander à votre coiffeur si vous avez besoin d'une coupe de cheveux. Un chercheur en sécurité m'a envoyé un message. Il a dit que mon application avait une vulnérabilité de traversée de répertoire. Je ne savais pas ce que cela signifiait. J'ai collé son message dans Claude. Claude a dit "c'est un problème de sécurité sérieux." J'ai demandé "répare-le." Il a changé quelque chose. Je l'ai déployé. Le chercheur m'a recontacté. Il a dit que j'avais introduit trois autres vulnérabilités. Je l'ai bloqué. Problème résolu. C'est l'état d'esprit d'un fondateur. J'ai embauché mon premier employé. Aussi un vibe coder. Son CV disait "construit 200+ applications." Il voulait dire qu'il a cliqué sur "accepter" dans Cursor 200 fois. Mais c'est de l'expérience maintenant. Nous faisons du pair programming. Cela signifie que nous sommes assis l'un à côté de l'autre et que nous demandons le même LLM depuis des ordinateurs portables différents. Parfois, nous obtenons des réponses différentes. Nous choisissons celle qui fonctionne sans erreur visible. Visible fait beaucoup de travail dans cette phrase. Nous n'avons pas de tests. Les tests sont pour le code que vous comprenez. Nous avons "confiance." La confiance signifie qu'il a chargé une fois dans Chrome. Nous avons expédié en production un vendredi. Tout le monde a dit de ne pas expédier le vendredi. Mais nous n'avons pas de surveillance. Donc chaque jour est le même. Si un serveur plante dans le cloud et que personne ne regarde les journaux, est-ce que ça fait du bruit ? Philosophiquement non. Financièrement aussi non. Parce que nous n'avons pas de journalisation non plus. Un client a signalé que l'application "fuyait des données." J'ai dit "fuir est un mot fort." Il a dit que ses clés API étaient visibles dans le code source de la page. J'ai dit "c'est une fonctionnalité pour les utilisateurs avancés." Il a annulé. J'ai marqué cela comme un churn dû à "un recalibrage de l'adéquation produit-marché." Nous traitons les paiements. J'ai demandé à Claude d'"ajouter Stripe." Il a ajouté Stripe. Je pense. L'argent arrive quelque part. La plupart des mois, il arrive sur notre compte. Je ne demande pas pour les autres mois. Notre base de données n'a pas d'authentification. Je ne l'ai pas demandée. Le LLM ne l'a pas suggérée. Nous sommes dans une relation ouverte avec les données de nos utilisateurs. Ils ne le savent juste pas encore. Quelqu'un a trouvé notre base de données sur Shodan. Je ne savais pas ce qu'était Shodan. Maintenant je sais. Ainsi que 40 000 autres personnes. Y compris nos utilisateurs. Anciens utilisateurs. Je suis allé sur un podcast. L'animateur a demandé ma "pile technologique." J'ai dit "principalement Claude et tous les paquets npm qu'il a envie d'installer." Il a ri. Je ne rigolais pas. Il y a 847 dépendances dans notre package.json. Je n'en reconnais aucune. L'une d'elles date de 2016 et n'a pas été mise à jour depuis. C'est probablement bon. "Probablement bon" est notre SLA interne. Nous avons été acceptés dans un accélérateur. La demande posait des questions sur notre "douves." J'ai dit "vitesse d'exécution." La vitesse d'exécution signifie que je peux produire des bugs en masse plus vite que quiconque ne peut les trouver. C'est techniquement une douve. Le jour de la démo est la semaine prochaine. J'ai besoin que l'application fonctionne pendant onze minutes. Après cela, elle peut faire ce qu'elle veut. Elle le fait généralement. Je lève un tour de financement de série A. 12 millions de dollars. Le deck dit "construit par une équipe d'ingénieurs d'élite." L'équipe, c'est moi, un gars qui ne sait pas coder non plus, et un LLM qui ne sait pas que nous sommes en production. Mais nous avançons vite. Nous cassons des choses. Principalement nos propres choses. Parfois d'autres choses. Nous découvrirons la différence plus tard. Je ne sais toujours pas coder. Mais j'ai une usine de responsabilité qui produit en masse et qui fonctionne parfois. En 2026, c'est ce qu'on appelle une entreprise. Et le graphique monte et va vers la droite. Parce que j'ai demandé à Claude de s'assurer que ça le fait.