Le Vibe Coding en Prod est un Problème de Management, Pas un Problème de Code

Eric Schluntz, chercheur chez Anthropic qui a co-écrit Building Effective Agents avec Barry Zhang, a donné une courte conférence lors d’un évènement récent intitulée “How to Vibe Code in Prod Responsibly.” Je l’ai regardée deux fois. C’est la formulation la plus claire que j’ai entendue jusqu’ici de ce à quoi les deux prochaines années d’ingénierie logicielle vont réellement ressembler, et l’argument n’est pas celui que la plupart des gens attendent.

L’argument ne porte pas sur la qualité des prompts, le choix du modèle, ou quel IDE gagne. Il dit que le vibe coding en production est un problème de management, et que les ingénieurs logiciels sont le dernier groupe fonctionnel de l’entreprise à y être confrontés. Tous les autres managers du monde résolvent déjà ce problème. On est juste en retard.

C’est l’article que j’aurais aimé écrire moi-même. Puisque je ne l’ai pas fait, voici ce que Schluntz a dit, ce que j’en ai retenu, et comment ça s’intègre dans la stack agentique que je décris depuis six mois.

Ce Que Veut Vraiment Dire Vibe Coding

Schluntz ouvre avec un resserrement définitionnel qui compte. Beaucoup de gens, note-t-il, confondent vibe coding avec “utiliser beaucoup d’IA pour générer du code.” Les utilisateurs de Copilot. Les utilisateurs de Cursor. Les ingénieurs qui laissent Claude écrire la majeure partie du diff mais relisent quand même chaque ligne. Ce n’est pas du vibe coding.

La référence, c’est la définition originale d’Andrej Karpathy : tu te laisses complètement aller aux vibes, tu embrasses les exponentielles, et tu oublies que le code existe même. La clause opérante, c’est oublier que le code existe même. Si tu es encore dans une boucle de feedback serrée avec le modèle, en relisant chaque morceau qu’il produit, tu fais du codage assisté par IA supervisé, ce qui est très bien mais c’est autre chose.

Le vrai vibe coding, c’est ce qui se passe quand l’unité de sortie IA dépasse ce que tu peux raisonnablement relire. Et ça arrive, qu’on le veuille ou non.

L’Exponentielle EST Tout l’Argument

Le cadrage des enjeux par Schluntz est le plus serré que j’aie vu :

The length of tasks that AI can do is doubling every seven months. Right now we’re at about an hour. You don’t need to vibe code. You can have Cursor work for you, have Claude Code write a feature that would take an hour, and you can review all that code. But what happens next year? The year after? When the AI can generate an entire day’s or week’s worth of work for you at a time, there is no way we’re going to keep up with that if we still need to move in lockstep.

J’ai déjà fait une version de cet argument dans The Last Bottleneck, mais l’analogie du compilateur de Schluntz est meilleure que tout ce que j’ai pu trouver. Aux premiers temps des compilateurs, les développeurs les utilisaient mais lisaient quand même l’assembleur émis pour vérifier la sortie. Ça ne passe pas à l’échelle. À un moment donné, tu fais confiance au compilateur et tu travailles à l’abstraction supérieure, parce que l’alternative, c’est de rester sur de petits programmes pour toujours.

On est à la même transition avec le code. La question n’est pas de savoir si on va la franchir, mais si on la franchit de manière responsable.

Le Vieux Problème de Management

Voici le point que j’avais manqué jusqu’à ce que Schluntz le dise à voix haute : ce n’est pas un nouveau problème. Tous les managers du monde le résolvent depuis des centaines d’années.

Comment un CTO manage-t-il un expert dans un domaine où le CTO n’est pas expert ? Comment un PM valide-t-il une fonctionnalité dont il ne peut pas lire l’implémentation ? Comment un CEO vérifie-t-il le travail du comptable sans être CPA ?

Ils utilisent des couches d’abstraction qu’ils peuvent vérifier sans comprendre l’implémentation en dessous. Le CTO écrit des tests d’acceptance. Le PM utilise le produit et confirme qu’il correspond à la spec. Le CEO vérifie par sondage des chiffres qu’il comprend, dans des tranches de données assez petites pour être raisonnées, jusqu’à ce que le modèle plus large gagne sa confiance. Ce pattern est aussi vieux que la civilisation, et c’est ainsi que toute grande organisation gère un travail qu’aucune personne seule ne peut inspecter complètement.

Les ingénieurs logiciels sont le cas inhabituel ici. Jusqu’à présent, notre métier supposait que le contributeur individuel pouvait descendre toute la stack et comprendre personnellement chaque ligne. C’était un luxe que la plupart des autres professions n’ont jamais eu. L’exponentielle va nous le retirer, comme elle a retiré la maîtrise de l’assembleur à la plupart des développeurs il y a une génération.

Le défi que pose Schluntz : “How will we vibe code in prod and do it safely? My answer is that we will forget that the code exists but not that the product exists.” Cette dernière clause, c’est tout le jeu. Tu dois toujours connaître, vérifier et posséder le produit. Tu arrêtes simplement d’avoir besoin d’auditer personnellement le code qui l’implémente.

Le Bémol : la Dette Technique

Schluntz est honnête sur là où l’analogie se casse. La plupart des abstractions que les managers vérifient, ils peuvent les vérifier avec des preuves externes. Les livres du comptable se réconcilient. La fonctionnalité du produit marche. Le test d’acceptance passe.

La dette technique est l’exception. Pour l’instant, il n’y a pas de bon moyen de mesurer ou valider la dette technique sans lire le code toi-même. Tu peux passer tous les tests, livrer toutes les fonctionnalités, et quand même finir avec un codebase qui se calcifie silencieusement sous le capot, et aucun signal automatisé ne te le dira.

C’est la seule chose, pour l’instant, qui exige encore une inspection experte. Ce qui nous amène à l’idée actionnable la plus utile de la conférence.

Leaf Nodes et Troncs

Si tu ne peux pas vérifier la dette technique depuis l’extérieur du code, alors tu dois être malin sur les endroits où tu laisses la dette s’accumuler. La règle de Schluntz est simple :

Les leaf nodes (feuilles) sont les parties de ton système dont rien d’autre ne dépend. Les fonctionnalités de bout, le polish, le dernier kilomètre. Si la dette atterrit ici, elle est contenue. Ces endroits sont sûrs pour le vibe coding.
Les troncs et les branches sont l’architecture centrale - modules et interfaces sur lesquels beaucoup d’autres choses sont construites. La dette ici se compose. Ces endroits méritent encore une ingénierie humaine soigneuse.

C’est le conseil architectural le plus concret que j’ai retiré de la conférence. C’est aussi un bon moyen d’auditer rétroactivement un codebase : si tu dessines le graphe de dépendances et que tu ombres les feuilles, tu viens de cartographier où les agents peuvent avancer le plus vite avec le moins de risque. Tout ce qui est en amont d’un module bien utilisé est un endroit où tu ralentis, tu relis attentivement, et tu investis dans l’extensibilité.

Pour quiconque essaie de définir une politique à l’échelle d’une équipe sur “où peut-on s’appuyer pleinement sur Claude,” c’est la bonne forme de réponse. Pas “tests ou pas tests.” Pas “critique ou non critique.” La question, c’est où dans le graphe de dépendances ce code se trouve.

La PR de 22 000 Lignes

L’exemple concret le plus frappant de la conférence, c’était Schluntz montrant la capture d’écran d’une vraie PR GitHub : un changement de 22 000 lignes sur le codebase de reinforcement learning en production d’Anthropic, écrit en grande partie par Claude. Ils l’ont mergée.

Comment ça se passe de manière responsable ? Quatre ingrédients, chacun une application directe des principes ci-dessus :

Des jours de travail humain sur les exigences et la guidance avant qu’une ligne ne soit écrite. Schluntz et son équipe ont agi comme le product manager de Claude, pas comme son dactylo.
Concentration sur les leaf nodes. Le changement vivait dans des parties du système où la dette technique future était acceptable parce que rien n’allait être construit par-dessus.
Revue humaine lourde sur les parties extensibles. La petite tranche structurelle a reçu la rigueur d’une revue d’ingénierie normale.
Tests de stress et vérifiabilité conçue. Ils ont construit le système pour avoir des entrées et sorties vérifiables par un humain. La stabilité, leur plus grande préoccupation, était mesurée par des tests de stress tournant sur de longues durées, ce qui ne demandait aucune lecture de code pour être interprété.

Le résumé que Schluntz donne du résultat mérite d’être cité :

Ultimately by combining those things we were able to become just as confident in this change as any other change that we made to our codebase but deliver it in a tiny fraction of the time and effort.

Relis cette phrase. La barre qu’ils se sont imposée, c’était une confiance égale à un changement écrit par un humain. Pas moindre, pas “suffisamment bon pour une PR écrite par une IA.” La même confiance, via des mécanismes de vérification différents. Voilà à quoi ressemble le vibe coding responsable en prod, et c’est ce à quoi je veux que chaque équipe avec qui je travaille aspire.

L’Effet de Second Ordre

L’effet que Schluntz mentionne presque comme un aparté est celui qui va remodeler la façon dont les équipes planifient le travail :

Now suddenly when something costs one day of time instead of two weeks, you realize that you can go and make much bigger features and much bigger changes. The marginal cost of software is lower and it lets you consume and build more software.

C’est exactement la dynamique que je vois se jouer dans mon propre travail et dans les entreprises que je conseille. Une fois qu’une équipe a intériorisé qu’un changement qui aurait été un projet de deux semaines est maintenant un projet d’une journée, elle arrête de filtrer sa roadmap à travers l’ancien modèle de coût. Des choses qui n’étaient jamais sur la liste parce qu’elles n’en valaient pas la peine y sont soudainement.

C’est aussi pourquoi les entreprises qui apprennent à vibe coder en prod de manière responsable ne livreront pas juste plus vite que celles qui ne le font pas. Elles livreront des choses différentes. Des refactorings plus larges. Des outils internes que personne n’aurait construits. Des expériences qui étaient bloquées par le coût d’ingénierie.

La startup londonienne que je rejoins bientôt m’a beaucoup trotté dans la tête en écrivant ça. Le delta entre une équipe qui a ce muscle et une qui ne l’a pas se verra dans la surface produit en moins d’un an.

Sois le PM de Claude

Le conseil pratique de la conférence pour les ingénieurs individuels est capturé dans une ligne que je vais citer à des gens pendant longtemps :

Ask not what Claude can do for you, but what you can do for Claude.

Le changement de mentalité va du prompteur au product manager. Tu es le PM de Claude. Quelle guidance, quelles exigences, quel contexte et quelles contraintes un nouvel ingénieur capable dans ton équipe aurait-il besoin pour réussir cette tâche au premier jour ? Rassemble tout ça, passe-le-lui, et laisse Claude cuisiner.

Le propre pattern de travail de Schluntz est concret et mérite d’être imité :

15 à 20 minutes de collecte de contexte avant de laisser l’agent exécuter. Souvent c’est en soi une conversation avec Claude - explorer le codebase, trouver les fichiers, construire un plan ensemble, capturer le résultat comme un artefact unique.
Passer l’artefact à Claude dans un nouveau contexte ou comme un prompt explicite execute-this-plan.
Compacter le contexte aux points d’arrêt naturels, les mêmes moments où un humain s’arrêterait pour déjeuner.

Je reconnais ça parce que c’est essentiellement le workflow que j’ai décrit dans Agentic Development Patterns et The Perfect CLAUDE.md : traite l’agent comme un collègue qu’il faut onboarder, pas comme un moteur de recherche. Ce que Schluntz ajoute, c’est le cadrage - tu es le product manager, pas le codeur - et le vocabulaire de vérifiabilité qui va avec.

Où Ça s’Insère Dans Ma Stack

Si tu as suivi les articles de développement agentique sur ce site, tu peux voir comment le cadrage de Schluntz s’insère comme la méta-couche manquante :

Couche	Ce qu’elle régit	Articles
Pourquoi on fait ça	Le problème de management, les leaf nodes, la vérifiabilité	Cet article
La forme architecturale	Quand utiliser du code déterministe vs ML vs agents LLM	Three-Tier AI Architecture
La couche de discipline	Skills, progressive disclosure, anti-rationalization	The Skills Framework
Le workflow quotidien	Collecte de contexte, artefacts de plan, worktrees	Agentic Development Patterns
Le mécanisme de composition	Runs de nuit, agents parallèles, portes de revue	The Overnight Agent Factory

La conférence de Schluntz est le résumé exécutif de toute la stack. C’est celle que je passerais à un CTO ou à un head of engineering qui n’a pas suivi cet espace de près et qui me demande pourquoi tout ça compte pour son équipe.

Ce Que Je Retiens

Trois choses que je vais opérationnaliser immédiatement :

Audits de leaf nodes. Sur chaque codebase que je touche, je veux un graphe de dépendances grossier avec les feuilles ombrées. Cette carte devient le document de politique sur où mes agents ont un maximum de liberté et où ils ont un chaperon.
Design verifiability-first. Quand je scope une nouvelle fonctionnalité, je demande maintenant explicitement “comment vérifierons-nous ce changement sans lire son code ?” comme une contrainte de design, pas une arrière-pensée. Tests de stress, interfaces propres, invariants et contrats typés deviennent tous porteurs.
PM de Claude, c’est mon titre de poste. Pas métaphoriquement. Les 15 à 20 minutes de travail de contexte au début de chaque session d’agent, c’est l’activité à plus fort levier de ma journée. C’est aussi la partie que je suis le plus susceptible de bâcler quand je suis pressé. Je vais arrêter de faire ça.

Ce Qu’il Faut Retenir

L’industrie a passé les dix-huit premiers mois de l’ère des agents à débattre pour savoir si le vibe coding était de la vraie ingénierie. C’était le mauvais débat. Le cadrage original de Karpathy est une pratique de travail avec des limites réelles. L’extension de Schluntz - forget the code, not the product - est le pont vers du travail de niveau production.

Le plus dur n’est pas d’abandonner le contrôle de l’implémentation. Le plus dur, c’est de construire les abstractions et les couches de vérification qui te permettent de transférer le contrôle de manière responsable. C’est du management d’ingénierie appliqué à ton propre métier. Tous les CTO, PM et CEO du monde le font depuis toujours. Maintenant c’est notre tour.

Si la durée des tâches que l’IA peut accomplir double vraiment tous les sept mois, les ingénieurs qui insistent encore pour lire chaque ligne vont devenir le goulot d’étranglement dans leurs propres équipes. Ceux qui apprendront à vérifier sans lire, qui vibe coderont les feuilles et garderont les troncs, qui agiront comme le PM de Claude plutôt que comme son dactylo, construiront des choses que le premier groupe ne peut pas imaginer. C’est l’exponentielle dans le embrace-exponentials de Karpathy, et c’est le vrai sujet de la conférence de Schluntz.

Regarde-la si tu ne l’as pas fait. Elle fait seize minutes et elle recadre les deux prochaines années.

Références

Vibe Coding - Eric Schluntz, Anthropic Team - La conférence originale
Building Effective Agents - Le primer plus ancien de Schluntz et Zhang sur les patterns d’agents qui sous-tendent tout ça
Andrej Karpathy on vibe coding - Le cadrage original
The Last Bottleneck - Mon article précédent sur l’exponentielle et le goulot d’étranglement humain
Three-Tier AI Architecture - Quand utiliser du code déterministe, du ML ou des agents LLM
The Skills Framework - Progressive disclosure et anti-rationalization comme couche de discipline
Agentic Development Patterns - Le workflow quotidien
The Perfect CLAUDE.md - Onboarder Claude comme un nouvel équipier
The Overnight Agent Factory - Le mécanisme de composition par-dessus