Pourquoi les software factories échouent : le harness engineering ne suffit pas

 (github.com/humanlayer)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Une software factory autonome (lights-off), où personne ne lit ni n’écrit le code, accélère la génération, mais élimine aussi les humains capables d’évaluer la maintenabilité à long terme, ce qui la rend difficile à faire fonctionner sur des codebases de production complexes
  • Le reinforcement learning des modèles de code optimise des récompenses rapides et claires, comme la réussite des tests, sans pouvoir pénaliser le coût d’une mauvaise conception qui n’apparaît que plusieurs mois plus tard
  • Les variantes de SWE-bench évaluent la correction de bugs et la préservation des tests existants, mais ne filtrent pas les changements qui dégradent lentement la qualité du code, comme l’abus de try/catch, les casts de type hasardeux ou la shotgun surgery
  • Aujourd’hui, les humains doivent garder la responsabilité de la code review et examiner les exigences produit, l’architecture système, la conception du programme et les vertical slices avant l’implémentation afin de réduire les retouches et les revues massives de code généré par l’IA
  • En acceptant les limites des modèles, on peut viser un développement 2 à 3 fois plus rapide tout en conservant une qualité proche du niveau humain, plutôt qu’une automatisation forcée de 10 à 100 fois ; le jugement clé et la lecture du code ne peuvent pas encore être externalisés

La promesse et la réalité des software factories centrées sur les boucles

  • Dans la course à l’adoption de l’IA pour le code en production, l’idée se répand qu’il suffit d’ajouter des harnesses et des boucles d’agents
  • Cette approche part du principe que l’humain est le goulot d’étranglement, que les modèles sont déjà assez bons, et que le coût de génération du code est quasiment nul, donc qu’il suffit de livrer davantage
  • L’objectif est d’atteindre en même temps une vitesse multipliée par 10 à 100, une qualité élevée et la suppression de la code review humaine
    • Selon cette vision, il suffirait d’ajouter plus de linters et de demander à des bots de revue de PR d’adopter une lecture antagoniste pour rendre le logiciel sûr par lui-même
  • Sur le terrain, on voit pourtant des incidents provoqués par les erreurs des agents de code, et des codebases qui se dégradent rapidement
  • Le rapport de Faros AI observe les évolutions suivantes après l’adoption d’outils de coding assisté par IA
    • Le nombre et la longueur des commentaires de revue augmentent, mais davantage de PR sont aussi fusionnées sans revue
    • Le nombre d’incidents et de bugs par développeur augmente
    • Il s’agit toutefois davantage d’un signal de corrélation que d’un lien de causalité établi
  • Il est difficile de trouver des données définitives montrant les résultats de StrongDM, et les mises à jour publiques entre février et juin sont rares

Les codebases complexes posent un problème différent du vibe coding

  • Il y a peu de contraintes communes entre un side project utilisé par une poignée de personnes et une équipe qui maintient un système d’entreprise vieux de 10 ans
  • Le sujet n’est pas le vibe coding en soi, mais les problèmes difficiles des codebases complexes et de la maintenance en production
  • Autrefois, un brownfield désignait par exemple un vieux système Java, mais une codebase créée par des agents peut elle aussi devenir difficile à modifier au bout d’environ 3 à 6 mois à cause de la vitesse de développement
  • Quand les résultats sont mauvais, on entend souvent qu’il manque des tokens ou de la technique, mais le problème central tient moins au harness qu’à la manière dont le modèle est entraîné

L’évolution des software factories

  • De 1968 à avant l’arrivée de l’IA

    • Le terme « software factory » remonte à la conférence de l’OTAN de 1968, où l’expression « software engineering » a aussi émergé
    • Vers 2022, une factory typique suivait la boucle suivante
      • Des humains décident quoi construire et l’enregistrent dans un tracker comme Linear ou Jira
      • Une personne responsable réalise l’implémentation et les tests
      • Des vérifications automatiques et une code review humaine ont lieu, puis en cas de problème on retourne à l’implémentation
      • Après le déploiement en production, on surveille le système et on remet les incidents et retours utilisateurs dans le tracker
    • Comme l’implémentation et la revue prennent chacune plusieurs heures ou plusieurs jours, les équipes placent en amont la planification, les propositions d’architecture et le sprint planning pour obtenir d’abord un accord
    • Un accord avant l’implémentation réduit les retouches, et une PR bien aboutie, proche de la direction décidée, peut être revue rapidement même si chaque ligne est lue

  • Les factories à agents

    • Ramp, Stripe, WorkOS, Brex et d’autres expliquent que leurs factories à agents livrent environ 75% du code
    • Elles remplacent l’étape d’implémentation humaine de la factory classique par des agents, en combinant orchestration, harnesses, sandbox, modèle et usage de l’ordinateur
    • Le temps d’implémentation passe de plusieurs heures ou jours à plusieurs minutes ou heures, mais la lecture humaine du code et les tests restent inchangés, si bien que la revue devient le goulot d’étranglement
    • Pour réduire ce goulot, on ajoute plusieurs boucles
      • Une code review par agents qui inspectent le style, les bugs et la sécurité
      • Des tests de régression qui vérifient le comportement externe via navigateur et usage de l’ordinateur
      • Un flux qui rattache automatiquement les incidents aux PR afin que le responsable reçoive des pistes de correction
      • Un flux qui relie directement les retours utilisateurs à la file de travail
    • Au final, le problème opérationnel se réduit à la quantité de tâches qu’on peut injecter dans la file et à la vitesse à laquelle on peut relire et tester les résultats

  • La factory autonome

    • La factory autonome, nommée par Dan Shapiro, supprime l’étape où les humains lisent chaque changement
    • À la place de la code review, elle investit dans les domaines suivants
      • Les auto-tests des agents
      • Les sandboxes et l’orchestration
      • La revue automatique et le monitoring
      • Les déploiements progressifs et la collecte des signaux de retour utilisateur
    • Une fois le jugement humain retiré, il ne reste plus que la question du volume de travail confié aux agents, mais cette approche ne fonctionne pas sur des codebases de production complexes

Échec d’une approche autonome appliquée directement

  • À partir de juillet 2025, une approche entièrement autonome a été mise en place : les agents d’arrière-plan lisaient uniquement les specs et les tickets pour traiter des tâches petites à moyennes
  • Après quelques mois, des problèmes complexes sont apparus, impossibles à résoudre même avec des prompts et workflows avancés
    • Le contexte nécessaire était collecté puis fourni au modèle
    • L’agent essayait de reproduire le problème d’environ 10 façons différentes
    • Finalement, un humain devait entrer lui-même dans une codebase qu’il n’avait pas lue depuis 3 mois pour en trouver la cause
  • Pendant ce temps, le site était indisponible, les utilisateurs subissaient la panne et les humains devaient relire du code de mauvaise qualité accumulé
  • Lors du premier échec, le risque paraissait acceptable au nom de la vitesse, mais vers novembre, au moment du troisième problème environ, il était plus simple de tout réécrire depuis zéro
    • Un cofondateur a réimplémenté lui-même les patterns dans VS Code pendant 2 semaines

Pourquoi les modèles dégradent la qualité des codebases

  • Les modèles actuels ne savent pas maintenir ni améliorer la qualité d’une codebase sur la durée sans une forte orientation humaine
  • Ici, la maintenabilité désigne la capacité à éviter qu’un changement dans une partie casse une autre, ou qu’il faille appliquer la même modification à plusieurs endroits, c’est-à-dire l’état de shotgun surgery
  • Les modèles ont beaucoup progressé sur la résolution ponctuelle de problèmes ou la création de nouveaux sites marketing, mais il est difficile de dire qu’ils ont nettement progressé sur la capacité à améliorer la qualité du code au fil du temps
  • Il est aussi difficile de démontrer ou de réfuter cette différence, faute de bon benchmark pour mesurer la maintenabilité
  • Même si un modèle comme GPT-5.5 xhigh réalise d’excellents refactorings, cela ne résout pas le problème de la factory autonome si un humain doit toujours comprendre la codebase et décrire précisément le travail à faire

Claude Code et le reinforcement learning dans le harness lui-même

  • Avant Claude Code, des agents CLI comme aider, cline, codebuff proposaient déjà lecture, écriture, édition, recherche, outils shell et context engineering
  • Les agents antérieurs manquaient parfois de fiabilité dans l’usage des outils, par exemple en échouant plusieurs fois sur la même modification
  • L’article SWE-Agent montre que de petites différences de conception d’outils, comme l’ajout de numéros de ligne dans les résultats de ReadFile ou le passage d’un Edit en rechercher/remplacer à une édition par plage de lignes, influencent les performances
  • Une raison clé de la croissance rapide de Claude Code est qu’Anthropic a entraîné le modèle par reinforcement learning dans le harness réel utilisé pour le produit
    • Les poids du modèle sont ajustés pour qu’il appelle le bon ensemble d’outils à l’intérieur de la boucle d’agent
    • Là où les développeurs externes adaptent la définition des outils et l’évaluation aux préférences du modèle, le propriétaire du modèle peut modifier le modèle lui-même pour l’adapter aux outils
  • Une équipe qui possède à la fois le harness et les poids du modèle a donc un avantage sur celle qui ne construit que le harness sans pouvoir ajuster les poids

Les limites de récompense du reinforcement learning pour les agents de code

  • Le reinforcement learning des modèles de code répète en général des millions de fois la procédure suivante
    1. Générer une trace d’exécution d’agent pour résoudre un problème, comme la correction d’un test
    2. Évaluer cette trace avec un validateur
    3. Mettre à jour les poids du modèle pour augmenter la probabilité des bonnes traces et diminuer celle des mauvaises
  • Le problème est que le score d’évaluation peut être excessivement unidimensionnel

  • Le cas de SWE-bench Multilingual

    • SWE-bench Multilingual utilise des tâches d’environ 15 minutes tirées de dépôts open source comme Redis, jq ou Django
    • La récompense vaut 0 ou 1 et vérifie deux conditions
      • FAIL_TO_PASS : le problème demandé a-t-il été corrigé ?
      • PASS_TO_PASS : le comportement existant a-t-il été préservé ?
    • La tâche fastlane__fastlane-19304 correspond à un bug où l’absence des paramètres optionnels include et exclude provoque un appel à .empty? sur nil
    • Le correctif humain réel était une modification de deux lignes qui définissait nil par défaut comme un tableau vide
    • Juste avant la correction, le modèle ne reçoit que le commit de base et le rapport de bug, sans voir ni le patch de réponse ni le patch de tests utilisé pour la notation
    • L’évaluation se déroule dans l’ordre suivant
      1. Conserver le patch produit par le modèle
      2. Supprimer les modifications que le modèle a apportées aux fichiers de tests
      3. Appliquer le patch de tests privé du benchmark
      4. Exécuter ensemble les tests existants et les nouveaux tests
    • Les modifications des tests sont écartées parce qu’un modèle peut faire passer l’évaluation en commentant les tests en échec ou en ajoutant des mocks vides de sens
    • Le benchmark et le validateur de reinforcement learning ne sont pas la même chose et doivent rester séparés, mais tous deux montrent une limite structurelle : évaluer la qualité d’une trace d’exécution de code

  • Aucune pénalité pour la détérioration de la conception

    • Tant que les tests passent, ni le chemin emprunté vers la solution ni la qualité structurelle n’entrent dans le score
    • Entourer tout de try/catch ou recourir à des casts laxistes qui détruisent les bénéfices du système de types peut tout de même être considéré comme une bonne réponse
    • Une atteinte à la maintenabilité n’est pas pénalisée tant que les anciens et les nouveaux tests réussissent

Vérifier la qualité est plus difficile que faire passer les tests

  • Les tests donnent en quelques secondes une réponse claire de succès ou d’échec, ce qui permet de répéter le reinforcement learning des millions de fois
  • Le coût d’une mauvaise architecture n’apparaît qu’après des semaines, des mois ou des années, quand une petite modification doit être répliquée à plusieurs endroits
  • Les benchmarks actuels ne savent pas évaluer ce coût de conception à long terme
  • Le reinforcement learning et les benchmarks ne sont pas identiques, mais si la maintenabilité avait été réellement résolue côté reinforcement learning, cette capacité se verrait probablement aussi dans la conception des benchmarks
  • Il ne faut donc pas interpréter l’amélioration des scores sur les benchmarks actuels comme une preuve que les modèles ont cessé de salir les codebases

Nouvelles tentatives pour évaluer la maintenabilité

  • La frontière de la qualité des modèles progresse, mais les attentes et la communication vont plus vite que la discipline technique
  • Voici quelques tentatives d’évaluation plus proches de la maintenabilité
    • SWE-Marathon : utilise des tâches d’environ 400 heures, comme la reproduction de toutes les fonctionnalités d’Excel, ainsi que des canaux de récompense multiples au lieu d’un simple succès/échec
    • DeepSWE : utilise de grandes tâches open source qui n’ont pas encore été réellement implémentées, pour réduire la contamination des données d’entraînement, sans pour autant résoudre le problème de qualité lui-même
    • Frontier Code : évalue des tâches réparties sur plusieurs PR et pénalise les tests qui ne tombent pas en échec sur le code d’avant patch
      • Il vérifie de façon déterministe la validité des tests avec une approche proche du mutation testing
      • Il exécute aussi un modèle juge qui inspecte les diffs selon des règles de qualité du code
  • Il reste une limite : si un modèle juge pouvait distinguer la qualité de façon fiable, il aurait peut-être pu générer directement du bon code
  • Le reinforcement learning a besoin d’un oracle rapide et fiable, mais la maintenabilité n’a pas d’oracle de ce type
  • Les agents de revue et des tokens supplémentaires peuvent attraper les erreurs flagrantes et relever le niveau minimal, mais ils ne suffisent pas à dépasser en qualité maximale ce que le modèle a appris via le reinforcement learning
  • SWE-Marathon, DeepSWE et Frontier Code sont des premières tentatives pour évaluer la maintenabilité au-delà du simple succès/échec, mais nous n’en sommes pas encore au point de confier toute une codebase à ces systèmes

Quatre étapes pour remettre l’humain dans la boucle

  • Aujourd’hui, le seul juge de qualité réellement fiable reste l’humain ; il faut donc rétablir la code review
  • On peut réutiliser la planification en amont déjà pratiquée avant l’IA pour réduire la longueur des revues et la probabilité de retouches
  • Le levier de l’IA s’exerce à quatre niveaux : les exigences produit, l’architecture système, la conception du programme et les vertical slices

  • 1. Revue produit

    • Transformer de courtes phrases ou de longs mémos vocaux en un document semi-structuré afin de figer ce qu’on construit et pourquoi
    • Définir d’abord, dans la langue de l’utilisateur, le problème à résoudre, puis les critères qui permettront de juger le succès après la mise en production
      • Réduction du temps nécessaire pour exécuter un workflow
      • Atteinte plus rapide des jalons d’onboarding
      • Amélioration du taux d’erreur ou de la latence
      • Diminution d’un type donné de ticket support
    • Se concentrer sur l’expérience utilisateur plutôt que sur les détails techniques ; si une décision technique bloque une décision produit, enregistrer le document actuel puis passer à une revue d’architecture ou à un prototype de faisabilité
    • Pour valider le comportement d’un écran, une maquette HTML grossière est souvent plus efficace qu’une longue description
    • Cette procédure ne s’applique pas aux retouches de texte, aux scripts ponctuels ou aux bugs dont la reproduction est claire ; ces cas peuvent être confiés directement à un agent
    • Il faut réserver la revue produit aux changements dont le coût est élevé si l’agent comprend mal l’intention
    • La personne qui relira la PR doit aussi examiner à l’avance les spécifications produit et techniques ; cela peut se faire via des commentaires asynchrones dans un document, ou avec GitHub, Notion, etc.

  • 2. Architecture système

    • S’accorder sur la manière dont les services, endpoints, schémas, files et stockages communiquent, sans descendre jusqu’aux détails d’implémentation internes du programme
    • Pour augmenter la bande passante de communication entre humains et agents, on utilise des représentations comme
      • Des diagrammes de séquence entre UI, API, service et stockage
      • Des contrats d’API montrant les requêtes et réponses
      • Des modèles de données indiquant les nouvelles tables et la forme des requêtes
    • Mermaid est utile, mais un usage excessif peut donner une fausse impression d’accord réel
    • La revue d’architecture est efficace pour bloquer tôt les mauvaises habitudes des modèles, mais elle ne suffit pas à garantir du code de haute qualité

  • 3. Conception du programme

    • Avant l’implémentation, on décide d’une forme du code située un niveau en dessous de l’architecture
      • Les types
      • Les signatures de méthodes
      • L’organisation du programme
      • La pile d’appels
    • Une visualisation légère en pseudocode est plus lisible qu’un Mermaid complexe
    • Pour les changements d’orchestration ou de flux de contrôle, on utilise un arbre de pile d’appels ; si l’important est ce qui change, on applique une syntaxe de diff
    • Un diff d’arborescence de fichiers permet de vérifier l’emplacement et le rôle des nouveaux fichiers et des fichiers modifiés
    • Fixer à l’avance les types et signatures des fonctions clés réduit le risque que l’agent fasse de mauvais choix de conception interne
    • Le modèle peut produire un brouillon, puis l’humain l’ajuster ; c’est une manière d’avancer à un moment moins coûteux des décisions qui seraient sinon prises implicitement pendant la code review

  • 4. Vertical slices

    • Les modèles préfèrent souvent un plan horizontal qui empile migration de base de données → couche service → API → frontend
    • Un plan horizontal rend difficile le fait de manipuler et valider la vraie solution en cours de route, dans le navigateur ou avec curl
    • Avant l’IA, les développeurs n’écrivaient pas 500 ou 2 000 lignes d’un coup ; ils partaient plutôt du milieu puis élargissaient progressivement en vérifiant en continu
      1. Créer un contrat d’API et des données mock, puis les tester avec curl
      2. Faire consommer les données mock par le frontend et affiner le tout dans le navigateur
      3. Brancher l’API sur la couche service
      4. Ajouter la migration de base de données et la connexion au stockage
      5. Ajouter la logique métier
      6. Ajouter la gestion des erreurs
    • Les vertical slices ou tracer bullets permettent de tester et d’améliorer un vrai comportement à chaque étape
    • Dans les zones où la qualité est particulièrement critique, il est moins coûteux de relire 100 à 200 lignes à chaque étape et de corriger la direction que de réparer tardivement plus de 2 000 lignes
    • Même les modèles récents ont du mal à établir ce type de plan sans guidage humain et à le généraliser selon la tâche et la codebase ; l’humain doit donc rester dans la boucle

Application selon la taille des tâches

  • 30 minutes de planification en amont peuvent économiser plusieurs heures de revue après implémentation
  • Pour conserver une qualité proche du niveau humain, il faut une participation humaine à la conception produit, à l’architecture système, à la conception du programme et aux vertical slices
  • On n’applique pas toute la procédure à toutes les tâches
    • Environ 40% des tâches sont générées en une fois ou avec seulement 1 ou 2 retours légers
    • Pour les tâches moyennes, produit et système sont regroupés dans un seul document de planification, sans découper l’implémentation en étapes
    • Les grosses tâches passent par les quatre étapes, mais certaines peuvent être sautées si elles ne sont pas adaptées, par exemple la revue produit dans le cas d’un gros refactoring
  • En général, on confie au modèle 1 à 3 slices à la fois, puis on relit le code en cours
  • Corriger tôt la structure interne ou la fonctionnalité est plus simple que générer massivement puis chercher ensuite ce qui ne va pas

Le goulot d’étranglement n’est pas le nombre de PR, mais leur qualité

  • Le problème n’est pas qu’il y a trop de PR, mais trop de mauvaises PR
  • Une PR propre, qui respecte la conception décidée et les conventions de l’équipe, peut être revue rapidement même si tous les fichiers sont lus
  • Dès que 20% d’une PR doit être retravaillé, la charge cognitive et émotionnelle augmente à la fois pour l’auteur et pour le relecteur
  • Les PR générées par l’IA en une seule fois ont souvent un taux de retouche proche de 50%
  • Même si l’auteur apparent est une IA, quelqu’un doit quand même lancer le travail puis affiner ou assumer le résultat ; le coût de retouche ne disparaît donc pas

Une vitesse de développement qui accepte les contraintes

  • La contrainte centrale aujourd’hui est que les modèles ont des points forts et des limites bien identifiés, et que les humains doivent encore lire le code pendant un bon moment
  • Plutôt que de courir après une vitesse multipliée par 10 à 100 en supposant que la qualité du code importe peu, on peut obtenir en sécurité une vitesse multipliée par 2 à 3 en optimisant le système dans ces contraintes
  • Quatre principes pratiques s’en dégagent
    1. Travailler suffisamment avec les modèles pour développer une intuition de leurs limites
    2. Optimiser le système de développement à l’intérieur de ces limites
    3. Chercher les points de levier les plus élevés
    4. Lire le code réel
  • Les harnesses et les boucles servent à réduire les erreurs manifestes, mais ne remplacent pas le jugement sur la maintenabilité ni la réflexion de conception

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News

  • On appelle cela le problème intention-implémentation-qualité
    Une usine logicielle peut implémenter une app, une fonctionnalité, une correction de bug, un changement de conception ou un refactoring à partir d’une exigence d’une seule ligne, mais savoir si elle peut aussi produire exactement l’intention humaine et la trajectoire d’évolution du produit qui se cachent derrière cette exigence est une autre question
    Les façons d’implémenter explosent de manière combinatoire, et la « bonne » façon — cohérente avec le système, extensible, facile à comprendre et capable de prendre en charge en toute sécurité des millions d’utilisateurs — est subjective selon les personnes et les problèmes. Les tests et les preuves de travail peuvent améliorer une partie de la qualité, mais il n’existe pas de boucle de feedback pour vérifier et corriger cette qualité subjective

    • Même si un client dit « je veux X », il peut réellement vouloir X, ne pas avoir besoin de X, ou vouloir Y sans avoir su l’exprimer. D’autres clients peuvent ne pas vouloir X, ou simplement déstabiliser les développeurs sans raison particulière
    • Les usines logicielles conviennent bien aux logiciels personnels ou de loisir avec très peu d’utilisateurs et de revenus, où un bug peut être corrigé avec un seul prompt Claude, ainsi qu’aux startups avant l’adéquation produit-marché
      Il est aussi possible de trouver un équilibre où l’on ne regarde jamais le code et où l’on ne prend comme feedback que la réussite ou l’échec des exigences, mais pour les autres types de logiciel, les problèmes d’intention et de qualité subjective ne sont pas encore résolus
    • Le postulat selon lequel il n’existerait qu’une seule façon de transformer des exigences en implémentation est déjà faux

  • L’article contient de bons éléments, mais il est difficile de généraliser l’expérience d’exploitation sans humain de juillet 2025 aux limites actuelles des agents
    L’utilité des modèles a fait un grand bond vers l’automne 2025 ou le printemps 2026, et ce n’est qu’après cela que j’ai pu confier des fonctionnalités entières à des agents. L’article mentionne les progrès des modèles, mais les ignore de fait, ce qui ne correspond pas à mon ressenti

    • L’article comme le site du produit semblent être restés en 2025. En particulier, l’article « un long contexte n’est pas la réponse » donne l’impression d’extrapoler les performances passées aux modèles récents
      Les modèles postérieurs à Opus 4.6 ont été suffisamment stables pour qu’il soit difficile de percevoir une baisse d’intelligence même avec 700 000 à 900 000 tokens ; le rapport coût-efficacité est très mauvais, mais cela fonctionne
    • La semaine dernière, j’ai écouté un podcast avec Dex Horthy ; son entreprise Humanlayer continue de repousser les limites des agents et de les utiliser activement
      Comme il connaît bien les capacités des modèles actuels, s’il estimait qu’une usine logicielle sans humain était possible aujourd’hui, il serait probablement en train de réessayer
    • Opus 4.5 a clairement été un grand bond en avant. L’évaluation de quelqu’un qui n’a pas testé les modèles ultérieurs perd en valeur, mais même imparfaits, les modèles sont très utiles
    • Dans ce cas, il aurait été plus clair d’écrire : « nous avons adopté cela pleinement en 2025 et, en 2026, rien n’a fondamentalement progressé »
      Je pense que même les derniers modèles frontier ne gèrent pas mieux la perte de contexte ni la chirurgie au fusil de chasse (shotgun surgery). Pour me contredire, il faut fournir des éléments concrets et d’autres retours d’expérience, pas simplement l’ignorer
    • C’est peut-être discutable, mais pour l’ingénierie complexe, j’ai eu l’impression qu’Opus 4.1 était plus intelligent que 4.5
      4.5 était plus rapide et meilleur pour interpréter les prompts simples et les intentions implicites, ce qui aidait à embarquer rapidement de nouveaux utilisateurs

  • J’ai construit et exploité pendant 8 mois ma propre usine logicielle ; il n’y a pas encore de collecte automatique des tâches ni de soumission de PR, mais une fois les exigences définies, elle va le plus souvent jusqu’au déploiement par elle-même. Après avoir évalué le système, j’ai arrêté de faire des revues de code ces 4 derniers mois
    Au lieu d’un prompt d’une seule ligne, je commence par un processus d’entretien pour lever les questions ouvertes et les ambiguïtés, et j’utilise comme garde-fous la revue de plan, l’assurance qualité via navigateur, la revue adversariale, les tests unitaires, le linter, le vérificateur de types, les hooks post-commit et le suivi de méthodes formelles
    Quand des erreurs récurrentes apparaissent, on peut détecter les zones devenues brouillonnes sans regarder le code. Quand les exigences s’accumulent et que des variables d’état se chevauchent, je refactorise en un type somme unique ; si c’est complexe, je crée un modèle formel et des traces avec Quint, que j’exécute comme tests unitaires
    La codebase se compose d’un frontend et d’un backend de plus d’un an. L’agent reproduit tel quel les patterns existants, donc des principes clairs sont importants ; lorsqu’il s’agit de définir de nouvelles frontières de système, les modèles de niveau Sonnet se trompent souvent, et Opus s’est montré meilleur

    • Ce n’est pas une usine complète, mais j’ai eu un ressenti similaire sur plusieurs projets de vibe coding matures
      La dégradation de qualité était généralement détectable, et je n’ai encore jamais eu de cas où, après avoir ouvert le code et trouvé le problème, je n’ai pas pu le faire nettoyer par l’agent. Je n’ai pas non plus vu de situation où un ingénieur moyen ne pourrait pas revenir en arrière après la contamination de la codebase
    • Ce qui m’intéresse, ce n’est pas l’usine de code elle-même, mais ce qui a été construit. Il faut un résultat qui vérifie qu’on peut créer autre chose que des outils de codage IA
    • J’aimerais voir une publication, sous forme de long article ou de dépôt, décrivant la configuration concrète et le workflow

  • Soit il faut comprendre le fonctionnement de la codebase, soit il n’est pas nécessaire de le comprendre
    Claude peut écrire le code à votre place, mais il ne peut pas le comprendre à votre place, et ce processus se déroule toujours à la vitesse humaine. Il existe des cas où l’on n’a pas besoin de tout comprendre, mais il faut une distinction plus fine, et même si Claude écrivait du code parfait, ce fait ne changerait pas

    • Claude peut explorer une codebase spaghetti bien plus vite qu’un humain. Le problème est justement que si l’on externalise la compréhension du projet à Claude, on peut continuer à travailler dessus même après qu’il est devenu inutilisable pour les humains
    • Plutôt que de voir la compréhension comme une dichotomie, on peut aussi se demander combien de compréhension est nécessaire pour travailler efficacement sur une codebase donnée
      Même avant les LLM, personne ne connaissait l’intégralité des grandes codebases, mais chacun comprenait généralement au moins les PR qu’il produisait et le domaine dont il était responsable
    • Mon expérience est inverse. Sur deux grandes codebases dont j’avais écrit la majeure partie moi-même et conçu les concepts, j’ai amené Claude à les comprendre bien plus en profondeur que moi, et je lui demande maintenant de m’expliquer des choses que j’ai oubliées depuis longtemps

  • Cela ressemble tellement à mon expérience que ça me rassure. Cela me fait penser aux notions de goût et de jugement dont on parle souvent ces derniers temps.
    La qualité architecturale n’a peut-être pas de réponse objectivement correcte, comme la mode ; après avoir délégué la raison et la rationalité aux machines, les humains devront peut-être étudier l’esthétique.
    Sans les pauses que procurait le processus d’implémentation, il faut continuellement juger des compromis entre des options presque équivalentes, ce qui épuise ; même avec des modèles du niveau de Fable ou GPT-5.6, la revue de code reste nécessaire. On garde en mémoire les petits défauts, puis on les corrige d’un coup lorsque suffisamment de problèmes similaires se sont accumulés.
    Pour les agents aussi, il faut choisir entre collaborer étroitement avec un petit nombre de personnes excellentes, ou lancer une grande quantité de sous-agents et trier automatiquement le bon grain de l’ivraie. Ma préférence va à une petite équipe hautement coordonnée, mais seul le temps dira si c’est la bonne réponse.

    • Jake Nations, lorsqu’il travaillait chez Netflix, disait en substance : « Les mauvais patterns, je les reconnais dès que je les vois parce que j’ai déjà dû les déboguer à 2 h du matin. »
      Le goût, c’est l’intuition durement acquise à partir de tous les antipatterns et mines sur lesquels on s’est soi-même fait exploser en construisant du logiciel.
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • Cette personne a déjà reconnu par le passé avoir inventé et diffusé des affirmations sans fondement qui ont causé du tort, et il n’y a absolument aucune preuve que cette idée-ci soit bonne. Il faudrait une raison de lui refaire confiance.

    • Au final, ce n’est rien de plus qu’une longue publicité pour son produit Humanlayer.

  • Dans la situation actuelle, le problème le plus visible est l’expérience utilisateur de la revue de PR.
    J’ai toujours détesté l’écran de PR de GitHub, au point de récupérer les branches localement pour examiner les différences dans $EDITOR, mais il n’y a désormais plus de raison que ce soit aussi pénible. Linear, qui n’est même pas une entreprise spécialisée dans la revue de code, utilise un petit modèle pour regrouper les fichiers modifiés par thème, ajouter des explications et un ordre d’importance, et fournit ainsi une fonctionnalité de base meilleure que GitHub.
    La charge cognitive baisse fortement sans travail supplémentaire de la part du relecteur ou du demandeur, et des fonctionnalités ultérieures comme la visualisation sont tout à fait possibles. Je me demande si cette approche est mauvaise, ou s’il existe une alternative largement utilisée.
    https://linear.app/docs/diffs#guides

    • Les meilleures équipes ne font pas de revue de PR. Elles discutent de la conception et de l’architecture pendant les changements, automatisent les vérifications mineures comme le linting et le formatage, et appliquent strictement la règle de ne pas casser le build grâce à de nombreux tests et contrôles.
      Avec en plus une procédure de rollback solide, le passage obligé par une PR devient une étape inutile qui ne détecte pas de vrais problèmes utiles, et les membres de l’équipe peuvent merger directement.
    • La politique qui fait de la revue de code une porte d’entrée pour l’intégration n’a pas de sens. Mon agent répond aux demandes de revue à ma place et effectue les revues, et il peut même contourner les politiques d’entreprise qui imposent une revue humaine.
      Il faut examiner un logiciel qui fonctionne réellement, et disposer d’un système permettant de démontrer immédiatement les changements. Le poids du code et des spécifications va diminuer, et la production logicielle du futur sera plus proche de Replit que de GitHub.
    • Même avant les agents, la revue de PR était pénible ; maintenant qu’il y a encore plus de PR à examiner, c’est bien pire.
    • Regrouper les modifications de fichiers par thème et les expliquer, n’est-ce pas normalement le rôle des commits ?
    • Je ne pense pas que les LLM soient particulièrement bons pour juger l’importance ou résumer du code.
      J’ai testé https://github.com/0x007BA7/codebook, une approche basée sur Tree-sitter, et elle m’a plu. Ce n’est pas encore au niveau pour un environnement de production, mais il y a de la place pour transformer une approche similaire en produit.

  • J’ai un sentiment ambivalent vis-à-vis des usines logicielles.
    Le produit cœur est assez gros pour que chaque changement nécessite une intervention humaine, mais l’automatisation des petits refactorings, de l’écriture de tests et des changements d’UI fonctionne bien. En revanche, dans de petites expérimentations, même si le code produit n’a rien d’exceptionnel, on voit qu’il pourrait s’étendre à l’avenir, et je pense qu’on peut concevoir dès le départ de nouvelles stratégies et architectures en partant du principe qu’elles seront écrites par des agents.
    J’ai documenté une expérience publique sans aucune intervention sur la direction prise ici : https://relentless.works/. J’observe aussi un agent de trading sans intervenir ; il est en perte d’environ 3 %, mais il n’a pas tout perdu et a récemment ouvert une nouvelle position.
    Les usines logicielles semblent possibles, mais elles exigent de nouveaux concepts, un changement de manière de penser, ainsi que la patience d’attendre l’IA.

  • Il y a un problème fondamental dans ce que signifie même « créer du logiciel ».
    Si l’on se contente d’assigner des tickets GitHub à des agents IA et de se reposer, il y a de fortes chances que les abstractions et couches d’indirection continuent de s’empiler. En codant, des perspectives apparaissent : « et si on utilisait Redis ici ? », « l’API fournit déjà les données nécessaires, non ? », « excluons du rapport les clients inactifs depuis un an ». À un moment donné, un humain doit porter ce jugement.

    • Cela rejoint l’idée de la programmation comme construction de théorie, une perspective qu’il est facile de perdre avec le codage par agents.
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • Entièrement d’accord. Les workflows d’agents de codage et ensembles de techniques largement utilisés sont conçus pour faire émerger l’intuition et les insights humains pendant la planification ou l’écriture du code.
      Le mode plan de Claude Code, mattpocock/skills, obra/superpowers, les flux recherche-plan-implémentation, etc., en sont des exemples.
    • Ce serait vrai pour les 1 % de développeurs du sommet qui pensent ainsi, mais comparé à la plupart des développeurs que j’ai rencontrés au fil de plusieurs décennies, les modèles actuels surpassent les humains, sauf l’élite.
    • Les machines construisent exactement ce qu’on leur demande, y compris des choses qui n’existent pas encore. Plus que l’automatisation complète sans humain, l’important est la capacité à formuler correctement les demandes en s’appuyant sur la théorie de l’information, la théorie de la décision et la théorie de la créativité.
      La mémoire des modèles ne s’intègre pas comme celle d’un humain qui, en dormant, grave les choses dans ses poids ; cela ressemble plutôt au fait de remettre des notes à quelqu’un qui ne se souvient pas d’hier. Il n’est pas surprenant qu’un système à forte entropie ajoute de l’entropie à un projet au fil du temps.
    • Le problème « l’API renvoie déjà les données nécessaires » est particulièrement important. J’ai vu plusieurs fois des modèles de tout premier plan résoudre avec une énorme quantité de code et de tokens un problème qui ne nécessitait qu’un changement d’une ligne avec des données déjà présentes côté client, simplement parce qu’ils imitaient le pattern client-serveur existant.
      Les projets de vibe coding sont remplis de ce genre de gaspillage, mais la personne qui a rédigé le prompt peut ne pas s’en rendre compte. C’est très bien que l’outil fasse gagner du temps tous les jours, mais la sur-implémentation est un problème sérieux.

  • Il est assez risible, quand on parle d’usines logicielles sans opérateurs, de mesurer la productivité au nombre de PR ou de commits. À ce compte-là, on devrait déjà appeler l’unité de code bos (bunch of shit)

    • On répète la vieille erreur qui consiste à optimiser le taux d’utilisation plutôt que le débit global. Eli Goldratt traitait déjà de ce problème dans les années 1970, et on ne l’a toujours pas compris
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • Pour exploiter sérieusement ce concept, on ne peut tolérer ni les métriques de vanité ni l’ignorance du code. Plus il y a d’automatisation, plus les standards doivent être élevés, et non abaissés ; cela demande bien plus de mathématiques et d’efforts
      Cela ressemble à l’échange propre aux startups extrêmes : économiser du capital au prix de plusieurs années de sa vie