- « Ne pas lire le code » signifie s’appuyer sur les spécifications, les tests, l’analyse statique et les signaux de production plutôt que sur une revue ligne par ligne, avec possibilité d’escalade vers une revue de code dans certaines zones à risque
- Les cas de Harness Engineering chez OpenAI et d’OpenClaw montrent une approche centrée, non sur le code, mais sur les tests, l’observabilité et l’infrastructure de validation automatisée
- En réponse au scepticisme autour de la boîte noire, de la sécurité ou de l’accumulation de bugs, l’auteur souligne le schéma historique des couches d’abstraction et l’importance des outils de validation automatisée
- Il ne s’agit pas d’exclure totalement la lecture du code, mais d’adopter une position équilibrée selon laquelle un examen direct reste nécessaire pour la sécurité, la sûreté et les décisions d’architecture
- Le code devient de plus en plus un détail d’implémentation, et il faut miser sur une trajectoire où les couches de spécification, d’architecture et de validation deviennent les livrables essentiels
Le sens exact de « ne pas lire le code »
- La phrase « Je ne lis plus le code » dans un billet précédent a déclenché plus de 200 commentaires passionnés sur Hacker News
- Le sens exact est que, pour la majorité du code produit, la revue ligne par ligne n’est plus le mode de validation par défaut
- Les spécifications, les tests, l’examen ciblé des diff modifiés et les signaux de production restent vérifiés, avec possibilité d’escalader vers une lecture du code dans certaines zones à risque
- Si l’auteur ne lit pas le code, ce n’est pas parce qu’il serait moins important, mais parce que, surtout à grande échelle, une lecture ligne par ligne n’est pas le moyen le plus efficace de garantir la justesse
Exemples à l’appui
-
Harness Engineering chez OpenAI
- OpenAI explique dans son billet Harness Engineering que le rôle central des équipes d’ingénierie logicielle s’est déplacé de l’écriture du code vers la conception de l’environnement, la spécification de l’intention et la mise en place de boucles de feedback
- Trois ingénieurs ont généré un million de lignes de code avec les seuls agents Codex pour construire un produit utilisé par des centaines d’utilisateurs internes
- L’investissement s’est concentré non sur le code lui-même, mais sur le harness qui l’entoure — documentation, règles de dépendances, linters, infrastructure de tests, systèmes d’observabilité
- Aucun investissement particulier n’a été consacré à la revue de code ligne par ligne
-
OpenClaw
- OpenClaw, créé seul sans équipe, est devenu l’un des projets open source à la croissance la plus rapide de ces derniers mois, avec plus de 100 000 étoiles sur GitHub
- L’architecture fait tourner 5 à 10 agents en parallèle, conçue et opérée par un ingénieur expérimenté, non par un débutant
- Dans une interview intitulée « Je déploie du code que je ne lis pas », il explique investir dans le refactoring, l’architecture, les tests et le harness autour du développement assisté par IA
-
De Coder à Orchestrator
- L’ingénieur expérimenté à l’origine d’ESLint et auteur de plusieurs ouvrages chez O’Reilly estime dans un billet récent que l’avenir de l’ingénierie logicielle sera centré non sur l’écriture du code, mais sur l’orchestration d’agents IA
- Les compétences clés se déplacent de la syntaxe et de l’implémentation vers la conception d’architecture, la rédaction de spécifications et la conception de boucles de feedback
Réponses au scepticisme
-
Critique de la boîte noire
- À la critique demandant s’il existe des cas où l’on choisit volontairement une approche de type boîte noire, l’auteur rappelle que le résultat du code, ce n’est pas le code lui-même mais le produit
- L’analogie est moins celle d’un photographe qui ne regarderait pas ses photos que celle de quelqu’un qui n’inspecte pas la structure interne de l’appareil photo qui les produit
- Construire des systèmes au-dessus de couches d’abstraction que l’on n’inspecte pas directement est déjà une pratique courante dans de nombreux domaines d’ingénierie, y compris le logiciel
-
Inquiétudes de sécurité
- Face à la crainte que du code généré par IA puisse contenir des backdoors, l’enjeu n’est pas « chaque ligne doit être lue par un humain », mais l’outillage et les mécanismes de validation
- L’analyse statique, le dependency scanning et les security linters existent aussi parce que les humains écrivent eux-mêmes du code vulnérable, et la réponse consiste à renforcer les systèmes de validation automatisée, soit exactement l’approche centrée sur le harness
- Cela dit, les zones particulièrement sensibles sur le plan de la sécurité exigent encore une revue humaine
-
Le problème de l’accumulation des bugs
- La critique la plus fréquente est la suivante : « Quand le code échoue, l’argent des gens disparaît, les avions s’arrêtent et les voitures tombent en panne. Lisez le code. »
- Selon les données de CodeRabbit, le code généré par IA produit 1,7 fois plus de défauts sur l’ensemble de la qualité logicielle
- Mais les façons de coder avec l’IA sont variées, et un développement centré sur le harness avec spécifications, tests hiérarchisés et contraintes d’architecture diffère fondamentalement du simple vibe coding
- Une approche proposée dans un commentaire : s’appuyer sur les spécifications, les tests et l’analyse statique, maintenir plus de 85 % de couverture de tests, construire des testing ladders — des tests d’intégration qui élargissent progressivement leur périmètre — et exposer tôt les erreurs grâce au benchmarking et à un dogfooding intensif
- La vraie question n’est pas « le code IA contient-il en moyenne plus de bugs ? », mais « dans un harness bien conçu, à vitesse de développement égale, produit-il plus de bugs que les alternatives ? »
- Greg Brockman, cofondateur d’OpenAI, défend lui aussi l’idée qu’il faut appliquer les mêmes critères qu’au code écrit par des humains
Comment les systèmes sont réellement construits
- L’auteur écrit du code depuis la majeure partie de sa carrière, principalement pour des outils internes, mais aussi pour des systèmes dont de vrais utilisateurs dépendent
- Il comprend la forme et la structure du code, mais choisit délibérément de ne pas le lire directement
-
Workflow basé sur les spécifications
- Avant qu’un agent n’écrive du code, il rédige d’abord avec l’IA des spécifications très précises et détaillées
- La structure permet une traçabilité depuis la spécification produit jusqu’au plan d’exécution via des ID d’exigences
- Toutes les tâches du plan d’exécution incluent des critères d’acceptation précisant le mode de validation
- Les tests automatisés sont marqués (TEST)
- Les vérifications visuelles sont marquées (BROWSER:DOM)
- (MANUAL) n’est utilisé qu’en dernier recours et, même dans ce cas, on tente d’abord de générer autant que possible des contrôles automatisés via curl ou bash
- Toute tâche dépourvue de métadonnées de validation explicites est bloquée par une compétence d’audit avant le début du travail
-
AI Coding Toolkit (le harness)
- Le toolkit, composé de prompts, de skills, de hooks et de scripts, contraint la manière de travailler des agents et comprend plus de 35 skills, des instructions structurées pour agents et une infrastructure de validation hiérarchisée
- Les instructions aux agents sont gérées comme une infrastructure
- AGENTS.md sert de recueil principal de règles : modifications conservatrices, maintien des interfaces existantes, respect du TDD, interdiction de conjecturer, interdiction de réécrire l’historique git
- VISION.md définit les limites stratégiques
- Un système de validation hiérarchisé est exploité
- À la fin de chaque étape, une compétence de checkpoint exécute des portes de contrôle multicouches incluant type checking, linting, tests, build, mutation testing et security scans
- Si les outils navigateur sont disponibles, une validation automatique dans le navigateur est effectuée
- Les diff modifiés sont transmis à un autre modèle IA (Codex CLI) pour une revue de second avis
- La validation croisée entre modèles compense les angles morts d’un modèle unique
- Il arrive encore que l’auteur lise directement le code, mais uniquement dans des situations exceptionnelles
- Quand tous les tests passent mais que le comportement du produit paraît étrange
- Quand une décision d’architecture majeure doit être prise
- Quand il faut déboguer un incident que plusieurs agents n’ont pas réussi à résoudre
- Même dans ces cas, le but n’est pas d’analyser le code en soi, mais d’identifier quelle faille du harness a permis le problème afin d’éviter sa répétition
Quand il faut lire le code
- Pour les systèmes directement critiques pour la sûreté, les services sensibles du point de vue de la sécurité et les décisions d’architecture majeures, l’ingénierie logicielle reste de l’ingénierie au sens fort, et à une époque où le code est généré en masse, son importance devient même encore plus grande
- La métaphore aéronautique de « Children of the Magenta » désigne le phénomène par lequel les pilotes en viennent à trop dépendre de la trajectoire magenta affichée par les écrans de navigation
- La leçon n’est pas « n’utilisez pas l’autopilote », mais conservez la capacité d’intervenir quand c’est nécessaire
- En cas de problème, il faut pouvoir réduire le niveau d’automatisation et revenir aux fondamentaux, mais exiger que tous les vols soient toujours effectués manuellement serait inefficace et plus risqué
- L’essentiel est de trouver l’équilibre entre usage de l’automatisation et conservation de la capacité d’intervention
Miser sur la trajectoire
- Toutes les couches d’abstraction de l’informatique ont rencontré de la résistance à leur apparition, et le cas de la réécriture d’Unix en C par Dennis Ritchie et Ken Thompson en 1973 en est un exemple emblématique
- À l’époque, on craignait une baisse de performance, une perte de contrôle sur le matériel et une complexité rendant la maintenance plus difficile, mais l’abstraction apportée par C a permis à Unix de devenir un système d’exploitation hautement portable et très influent
- Le schéma récurrent est que les personnes expertes de la couche en cours d’abstraction insistent sur l’importance de comprendre cette couche ; cet argument est valable dans certains cas, mais la plupart du temps, l’effort se déplace vers la pensée et la conception à des niveaux d’abstraction supérieurs
- Le choix de ne pas lire le code n’est pas une déclaration selon laquelle les outils seraient parfaits, mais un jugement selon lequel, pour de nombreux cas d’usage, ils sont déjà suffisamment valides et progressent rapidement
- Le code ne disparaît pas : il devient de plus en plus un détail d’implémentation, tandis que les couches de spécification, d’architecture et de validation émergent comme les livrables essentiels
3 commentaires
J’ai l’impression que la programmation par IA se rapproche moins de l’abstraction ou de l’automatisation que d’une forme d’externalisation/sous-traitance.
Et que la conception et la validation sont introduites moins comme des éléments de sophistication et de précision que comme une sorte de réglementation qui maintient tant bien que mal à flot une société à faible confiance.
C’est une analyse pertinente.
Il me semble important de souligner que la programmation avec l’IA est fondamentalement probabiliste.
Je crée une bibliothèque avec l’IA, et j’ai l’impression qu’il faut aussi faire tourner l’IA pour le refactoring, l’amélioration de la qualité du code et la vérification des défauts.