How I Review AI Code - (Meta Senior Staff Engineer)

À retenir

1. 2:31 Sa réponse à « lisez-vous le code ? » est « ça dépend » : l'effort de relecture suit le risque de chaque changement, pas une règle unique.
2. 3:52 Il classe le code en tronc (points d'entrée, infrastructure) et feuilles (code isolé ou derrière un flag) ; le tronc non protégé est relu en profondeur.
3. 6:38 Chaque PR doit apporter des preuves : tests unitaires, logs, captures ou vidéo, niveau de confiance de l'agent. Elles permettent de lire moins de code.
4. 16:36 « Merge-ready » n'est pas « launch-ready » : il compte 20 % de travail humain restant, aussi long que les 80 % premiers, puis canaris ou A/B tests.

La vidéo en bref

• 0:00 John Kim présente deux camps : ceux qui ne relisent plus car les agents seraient meilleurs, et ceux qui jugent l'IA encore peu fiable. Il annonce sa méthode de relecture et se présente comme senior staff engineer chez Meta.
• 1:32 Il montre une petite application maison, où l'on vote si un contenu est IA ou non, qui sert de support à ses exemples. Il constate que l'IA fait exploser le volume de code, impossible à relire en entier.
• 2:31 Sa réponse est « ça dépend ». Il inclut les agents à chaque étape : planification, construction avec auto-validation, relecture, lancement avec feature gates et expériences.
• 3:52 Il compare la base de code à un arbre : le tronc (points d'entrée, infrastructure) pèse plus que les feuilles. La profondeur de relecture dépend de l'impact possible, par exemple le rendu d'images central.
• 5:11 Il recommande de planifier avec des feature gates dès le départ, même un simple booléen, ou LaunchDarkly. Il sépare les feuilles de l'intégration, qu'il protège par un gate.
• 6:38 Il demande aux agents des tests, des logs d'exécution, des captures ou vidéos et un niveau de confiance. Il montre un exemple de bouton de sauvegarde de carte et conseille de se méfier des tests inutiles.
• 9:00 Le code isolé ou gaté est survolé. Un reducer à état partagé modifié sans gate est relu longuement. Trois questions : que ne faut-il pas changer, quel dégât, peut-on revenir en arrière ?
• 10:20 Il laisse typage et lint aux outils automatiques et juge les débats de style dépassés. Il relit plus de code qu'avant, en réglant sa vigilance selon le risque.
• 12:31 Il juge l'IA meilleure que la plupart des humains en relecture. Il préconise un agent sans le contexte de l'écriture, un modèle de PR et la revue Codex sur GitHub, plus un « goal » pour surveiller une PR chaque heure.
• 16:20 Après la fusion, il estime n'être qu'à 80 %. Les 20 % restants (audit performance, sécurité, finitions) demandent autant de temps que le reste et du goût humain.
• 17:52 Il conseille des A/B tests ou déploiements canari, même avec peu d'utilisateurs, pour repérer vite bugs et alertes. Il vise un « jardin agentique » de tests et de validations, avec retour arrière par gating.
• 19:32 Il lit encore une partie du code, mais pense lire moins avec des modèles meilleurs. Connaître sa base de code aide à repérer les zones dangereuses face aux feuilles simples.

De quoi ça parle

John Kim, ingénieur chez Meta, explique comment il relit le code généré par IA : effort proportionnel au risque (tronc ou feuille), preuves dans les PR, agents relecteurs indépendants, feature gates et déploiement progressif.

Ce que la vidéo ne dit pas

• Le coût en jetons et en temps des agents relecteurs et de la surveillance horaire des PR n'est pas chiffré (seul « tout ça coûte de l'argent »).
• Aucun exemple d'échec : un bug que cette méthode aurait laissé passer ou un taux d'erreur des agents relecteurs.
• La relecture humaine sert aussi à partager le contexte et la responsabilité de l'équipe ; ce rôle n'est pas traité

Carte des affirmations

Intérêts en jeu

Aucun sponsor, lien affilié ni produit du créateur détecté dans la description ou la transcription.

Aucun intérêt commercial détecté : seule une newsletter gratuite (PushToProd) est promue en description. Le créateur y gagne des abonnés.