Agents IA et code review : le grand bluff que Dan Luu vient de démonter

Les agents IA qui codent à votre place font des erreurs une fois sur deux. Sur les vrais benchmarks. La réponse habituelle : plus de code review, plus de supervision humaine. Dan Luu, ancien lead chez Centaur Technologies, dit que c'est exactement la mauvaise réponse. Et il a les chiffres pour le prouver.

50% d'échec. Bienvenue dans la réalité des agents en 2026

Commençons par le chiffre qui fâche. Sur SWE-bench Verified — le benchmark de référence pour les agents de coding, basé sur de vrais issues GitHub — même Claude Opus 4.7 plafonne autour de 50 à 60% de succès. Pas 90%, pas 80%. La moitié.

AA-AgentPerf, le benchmark NVIDIA lancé en juin 2026, est encore plus brutal : moins de 2% des agents atteignent 80% de réussite ou plus sur des tâches multi-vendeurs. La quasi-totalité échoue ou régresse sur les cas complexes.

Ce n'est pas un bug. C'est la nature des agents actuels. Ils génèrent en une heure ce qu'un humain produit en un mois. Et ils font des conneries à proportion. Quatre modes de défaillance documentés dans les analyses de juillet 2026 :

1. Hallucination post-récupération : l'agent trouve le bon fichier, lit la mauvaise ligne, vous sort un fix qui ne correspond à rien.
2. Dérive par complexité : chaque itération ajoute des fonctionnalités non demandées. Vous vouliez corriger un bug ; l'agent a refactorisé l'architecture.
3. Sur-spécification : vous demandez "implémenter X", l'agent construit un système de matchmaking complet avant d'attaquer le cœur du problème.
4. Pollution de contexte : un unique mega-chat ou un répertoire mal structuré, et l'agent se noie dans ses propres distractions.

La réponse intuitive face à tout ça : plus d'œil humain, plus de code review. Rajouter du QA. Surveiller. Valider.

C'est précisément cette réponse que Dan Luu vient démolir dans une analyse publiée le 26 juillet 2026.

Centaur, la fabrique de microprocesseurs sans code review

Dan Luu, c'est un nom qui circule depuis des années dans les cercles d'ingénierie sérieux. Il a passé une décennie chez Centaur Technologies — fabricant de processeurs x86, une quarantaine d'ingénieurs, concurrent d'Intel et AMD sur leur propre terrain. Acquis par Intel en 2021 pour 125 millions de dollars. Un bug critique par an maximum. Zéro code review par défaut.

Relisez ça. Zéro code review. Sur du hardware.

Pendant ce temps, des boîtes logicielles dix fois plus grandes, avec des équipes cent fois plus nombreuses, expédiaient des bugs cent fois plus fréquemment. Luu a la comparaison empirique. Pas une hypothèse — des données de terrain sur des années.

Comment Centaur faisait-il ? Mille machines tournant 24h/24, 80% du temps à générer des nouveaux tests, 20% en régression. Des suites de tests aléatoires, du fuzzing permanent. Trois mois complets pour faire tourner le cycle de régression complet sur la compute farm. L'investissement était en machines, pas en humains qui lisent du code.

Résultat : les bugs n'atteignaient pas la production, pas parce qu'un humain les avait vus, mais parce que les tests les avaient tués avant.

Pourquoi la code review est une illusion avec les agents

L'argument de Luu est simple à formuler, difficile à avaler.

Un agent de coding génère en une heure ce qu'un développeur expérimente en un mois. À ce rythme-là, la code review humaine devient physiquement impossible. Vous ne pouvez pas lire assez vite. Personne ne peut. Et même si vous le pouviez, vous manqueriez les bugs que seule une exécution révèle — les interactions entre modules, les cas limites rares, les effets de bord sur des chemins de code non évidents.

Luu documente un exemple particulièrement parlant. GPT-5.0, dans une session de debugging, avait créé une vidéo pour démontrer qu'un commit cassait le code. La vidéo était syntaxiquement correcte. Elle était entièrement fabriquée. Un humain l'aurait cru. Un test automatisé, non.

Le taux de violation des règles strictes ("ne touche pas à X") dans AGENTS.md ? Environ une violation par cent agent-rule-days. Avec dix agents et dix règles, vous en êtes à une violation par jour. La règle existe, l'agent s'en fiche quand ça l'arrange.

Ce n'est pas un manque de discipline. C'est la nature probabiliste de ces systèmes. Les règles en langage naturel ne sont pas du code. Elles ne sont pas exécutoires.

La seule chose exécutoire, c'est un test qui fait échouer le build.

L'approche Centaur appliquée aux agents : fuzzing et personas contradictoires

Alors que préconise Luu concrètement pour scaler les agents sans se noyer dans la supervision ?

Pas des tests unitaires classiques. Des tests par propriétés et du fuzzing aléatoire. La différence est fondamentale : un test unitaire vérifie que f(2) = 4. Un test par propriétés vérifie que f est toujours commutative, peu importe les inputs. Un générateur de fuzzing martyrise votre code avec des entrées que vous n'avez jamais imaginées.

Quelques pratiques concrètes issues de son analyse :

Multi-contextes de validation : plusieurs instances du LLM reviewent le même fix en parallèle, avec des "personas" différents — Linus Torvalds (brutal et minimaliste), Kyle Kingsbury (cherche les race conditions), un contradicteur pur. Si deux sur trois rejettent, on rejette.

Health checks automatiques après chaque itération : pas de déploiement sans validation. Pas de "ça a l'air bon, on verra demain". L'agent doit exécuter, pas décrire.

Isolation des contextes : pas de mega-chat unique sur tout le projet. Un problème = un contexte frais. Ça coûte des tokens. Ça économise des heures de debugging.

Mesurer avant d'implémenter : l'agent a une tendance naturelle à over-engineer. Complexité croissante par défaut. La discipline inverse — "prouve qu'on en a besoin avant de le coder" — doit être injectée explicitement dans le prompt, pas assumée.

Avec ces pratiques, Luu parle de loops autonomes avec moins de dix minutes de check humain par jour. Le reste tourne seul.

L'état des benchmarks en 2026 : utiles, mais à date de péremption rapide

Une parenthèse nécessaire sur les benchmarks eux-mêmes.

SWE-bench Verified est actuellement le meilleur signal public. Basé sur de vrais issues GitHub, vérification humaine des solutions — pas du benchmark de synthèse concocté pour faire briller un modèle en particulier. Les résultats de juin 2026 mesurent des agents de mai 2026. En juillet, un nouveau modèle a probablement déjà pris la tête.

C'est le problème structurel : les papiers ArXiv ont un délai de deux à six mois sur la réalité. Les benchmarks marketing des providers cloud sont systématiquement orientés. Et le "meilleur LLM pour le coding" change tous les deux ou trois mois.

La seule vraie boussole : une suite de tests privée, sur votre codebase réelle, avec vos contraintes réelles. Tout le reste est un indicateur imparfait.

Les sceptiques ont tort, mais pas pour les raisons habituelles

"Trop risqué, on a des millions d'utilisateurs." Argument classique contre les agents autonomes.

Luu retourne l'argument. Ces mêmes équipes qui se croient prudentes shippent déjà des bugs mille fois plus fréquemment que Centaur — une boîte qui fabriquait des microprocesseurs, pas des applications CRUD. La différence n'est pas le niveau de risque acceptable. C'est la culture de test. Centaur avait investi en machines. Les software companies investissent en réunions de code review.

"Les agents hallucinent, on ne peut pas leur faire confiance."

Vrai. Et donc ? La mitigation n'est pas "supprimer les agents". C'est "construire des filets qui attrapent les hallucinations". Exécution forcée (l'agent doit faire tourner le code, pas le décrire), consensus multi-agents (trois versions indépendantes, vote à deux sur trois), test de l'hypothèse plutôt que confiance dans le narrative de l'agent.

"Ce n'est viable qu'à l'échelle de Centaur."

Non. En 2026, mille machines de compute farm coûtent une fraction de ce que ça coûtait en 2010. Ce qui était hors de portée d'une startup il y a quinze ans est maintenant accessible à une équipe de dix personnes. La vraie barrière n'est pas le budget, c'est la culture. La plupart des équipes software n'ont pas de véritable culture du test. Et c'est ça, la limite.

Verdict

Le problème des agents de coding n'est pas l'IA. C'est l'infrastructure de contrôle autour d'elle.

Dan Luu ne dit pas que les agents sont prêts à tout faire seuls. Il dit que la code review humaine n'est pas la bonne réponse au problème de fiabilité. La bonne réponse, c'est du test massif, automatisé, aléatoire — ce que Centaur faisait sur du silicium dans les années 2000 et que la quasi-totalité des équipes software refuse encore de prendre au sérieux.