Pourquoi les usines logicielles échouent : comment redresser la barre

Ceci est la deuxième partie de Pourquoi les usines logicielles échouent

La version filmée de cet article est disponible sur YouTube : https://www.youtube.com/watch?v=Ib5GBkD555M

Rallumer les lumières

Dans la partie 1, je suis allé en profondeur sur les raisons pour lesquelles on ne peut pas faire confiance aux modèles pour maintenir la qualité du codebase dans le temps. Pourquoi aucune quantité d'ingénierie de harnais ou de tokenmaxxing ne résoudra un problème de formation de modèle et de benchmarks. Pourquoi le « modèle en tant que juge » pour la qualité du code ne fonctionne pas aussi bien que certains voudraient vous le faire croire.

Pour l'instant, le juge, c'est vous — donc on va remettre la revue de code au centre.

Nous allons adopter cette même pratique que nous utilisons depuis bien avant l'IA, à savoir faire un peu de planification en amont, pour réduire les risques d'une revue longue et difficile.

Nous allons trouver des leviers, et nous allons utiliser l'IA pour nous y aider, à travers 4 phases :

• Exigences Produit
• Architecture Système
• Conception Programme
• Tranches Verticales

Revue Produit

Tout commence par une revue produit : un court document qui définit précisément ce que nous construisons et pourquoi. L'objectif est de pouvoir prendre deux phrases ou un long message vocal décousu et le transformer en quelque chose de semi-structuré.

D'abord, nous nous alignons sur le problème à résoudre — la difficulté réelle de l'utilisateur, dans ses propres termes. Ensuite, à quoi ressemble le succès — ce que nous pourrons lire après le déploiement pour décider si la chose valait la peine d'être construite. Idéalement, il s'agit d'un résultat pour l'utilisateur, comme « peut effectuer le workflow XYZ en moins de temps » ou « atteint l'étape d'intégration ABC plus tôt ». Parfois, c'est plus bas niveau, comme un taux d'erreur ou une latence, parfois juste « les tickets de support concernant X s'arrêtent ».

Nous essayons de rester assez ancrés dans l'espace produit, pas dans le technique. En tant que personne vivant avec un pied dans le monde du produit et un pied dans la technique, je me surprends souvent à dériver vers les détails techniques ici. Quand cela arrive, j'essaie de simplement les noter pour les phases ultérieures et de revenir à ce que l'utilisateur vit réellement. Si les décisions techniques bloquent les décisions produit, alors nous validons ce que nous avons et passons à l'architecture ou faisons plus de recherche par prototype sur ce qui est faisable

Et comme la plupart de cela concerne ce que l'utilisateur voit, je ne le décris pas — je le maquette. Une maquette HTML grossière de l'écran réel règle une dispute que trois paragraphes ne feraient que prolonger.

En voici une vraie en cours — le document définit la fonctionnalité avec un plan JSON, puis deux maquettes HTML grossières des écrans réels :

https://x.com/dexhorthy/status/2078592010852982977

Bien sûr, tout ne fait pas l'objet d'une revue produit. Un ajustement de copie, un script unique, un bug avec une reproduction évidente — nous les envoyons toujours directement à l'agent. Ce processus est réservé aux changements où une méprise de l'agent sur notre intention est coûteuse.

Pour ce document et tous ceux de la série, nous faisons des revues avec option d'auteur. Si vous voulez gagner du temps pendant la revue, vous choisissez la personne qui relirait la PR, et vous parcourez les spécifications produit/techniques avec elle, soit de manière asynchrone via des commentaires sur le document (nous utilisons HumanLayer en interne pour cela, mais vous pouvez tout aussi bien le faire dans GitHub/Notion/Plannotator, etc.).

Architecture Système

Une fois la revue produit terminée, nous passons à l'architecture système. Ce n'est pas particulièrement nouveau et c'est quelque chose que même les vibe codeurs commencent à adopter.

Si vous voulez gagner du temps pendant la revue, vous choisissez la personne qui relira la PR, et vous parcourez les spécifications produit/techniques avec elle avant d'arriver à la partie codage.

Dans cette phase, nous nous alignons sur la façon dont les services, les endpoints, les schémas, les files d'attente et les magasins communiquent entre eux, sans entrer dans les détails de la conception programme. Pour maximiser la bande passante de communication humain<>agent, nous utilisons abondamment les visualisations ici — par exemple les diagrammes de séquence :

Formes des contrats / endpoints :

Modèles de données et transformations :

Mermaid est acceptable ici, mais cela peut parfois être excessif et parfois vous attirer dans un faux sentiment d'alignement. L'architecture est un levier assez important et il y a beaucoup de tics de modèle potentiellement mauvais que vous pouvez éviter pendant cette phase. Mais cela est insuffisant pour produire du code de haute qualité. Pour cela, nous avons besoin de la conception programme.

Conception Programme

Après l'architecture, nous faisons cette chose qui, selon moi, est terriblement sous-estimée dans le codage agentique : la conception programme.

La plupart des gens supposent qu'une fois l'architecture correcte, le modèle peut simplement cuisiner. Vous pouvez certainement faire cela, mais vous risquez de ne pas aimer ce que vous obtenez en retour.

Mais ce que je vois bien fonctionner, c'est qu'avant que quiconque (humain ou agent) n'écrive l'implémentation, nous descendons d'un niveau par rapport à l'architecture dans la forme du code : les types, les signatures de méthode, la disposition du programme et les piles d'appels.

La première version de notre compétence en conception programme était nulle. C'était dur à lire, c'était épuisant. Nous avons essayé Mermaid, qui a sa place, mais ce que nous aimons vraiment, ce sont des visualisations légères en pseudo-code :

Arbres de piles d'appels, pour tout changement d'orchestration ou de flux de contrôle. Utilisez la syntaxe de diff quand la partie intéressante est ce qui change :

Dillon Mulroy parle de l'utilisation de graphes d'appels dans le cadre de son processus de planification, et je pense que c'est tout à fait juste.

Diffs d'arborescence de fichiers - pour rester en contact avec la disposition de votre codebase et où se trouvent les choses

Types et signatures de méthode pour les nouvelles fonctions clés — ce qui est trop interne pour un document d'architecture mais qu'un agent pourrait encore mal comprendre

Aucun de ces éléments ne prend longtemps à produire (le modèle les ébauche, vous discutez avec lui), et chacun d'eux est une décision que vous prendriez autrement implicitement pendant la revue de code — au moment le plus coûteux possible pour changer d'avis.

Tranches Verticales

Ensuite, nous aimons faire ce que j'appelle des « tranches verticales » — Matt Pocock et moi avons eu une

discussion sur les tranches verticales ou « balles traçantes » lors d'un live stream en janvier 2026 - cela est également appelé - balles traçantes

Les modèles adorent ce que j'appelle les « plans horizontaux » - faire les choses dans l'ordre de la pile :

1. Migrations de base de données
2. Couche Service
3. API
4. Frontend

En pratique, cela signifie qu'il n'y a pas vraiment de moyen de « toucher » la solution pendant que vous avancez. Vous pouvez tester des choses avec du code, mais pour presque toutes les fonctionnalités que j'ai jamais construites, lire les tests était un début, mais sortir quelque chose dans un navigateur, ou l'atteindre avec curl pendant que je travaillais était toujours une partie fréquente du workflow.

Avant l'IA, il était rare que quelqu'un écrive plus de 2000 lignes de code, voire 500 lignes de code, sans vérifier quelque chose en cours de route.

Il m'a fallu un certain temps pour remarquer la différence avec ce à quoi j'étais habitué - quand j'écrivais du code avant l'IA, je commençais toujours par le milieu et je travaillais vers l'extérieur. Vaguement :

1. Créer le contrat API et servir des données factices, tester avec curl
2. Créer le frontend pour consommer les données factices, itérer+polir dans le navigateur
3. Connecter l'API à la couche de services (les services servent des données/comportements factices)
4. Ajouter les migrations de base de données, connecter les services à la base de données
5. Ajouter beaucoup de logique métier
6. Ajouter beaucoup de gestion d'erreurs

Et je testais/itérais/polissais à chaque étape.

Si je tiens beaucoup au code ou si je suis sceptique quant à la capacité du modèle à faire du bon travail dans cette partie du codebase, je révise le code à chaque étape aussi. Vérifier 100-200 lignes et se réorienter est beaucoup moins cher

ici, je le ferais. La plupart des modèles de pointe ne concevront pas un tel plan sans intervention humaine, et il est difficile de généraliser par codebase ou même par tâche, donc je préfère rester dans la boucle ici. Croyez-moi. Si je pouvais sous-traiter la réflexion

30 minutes de planification évitent des heures de revue

Et donc nous avons quelques étapes pour lesquelles je dirais que les humains doivent rester dans la boucle, si vous voulez maintenir un niveau de qualité proche de l'humain sans vous épuiser sur des montagnes de code bâclé en essayant de le nettoyer après coup. (c'est-à-dire que vous voulez vraiment aller vite)

1. Conception Produit
2. Architecture Système
3. Conception Programme
4. Tranches Verticales

Évidemment, nous ne faisons pas tout ce processus pour tout ce que nous livrons (voir la quête secondaire ci-dessous). Je dirais que la distribution est approximativement :

• ~40% des tâches sont expédiées en un seul coup ou avec 1 à 2 tours de feedback léger
• pour les tâches moyennes, nous faisons la conception produit/système dans un seul document de planification, et ne prenons pas la peine de diviser le travail en phases
• pour les grandes choses, nous faisons toutes les étapes. nous sautons la partie produit pour les choses où cela n'a pas de sens, comme les grosses refontes.

Et dans la plupart des cas, j'envoie un modèle faire 1 à 3 tranches à la fois, et je révise le code au fur et à mesure. Il est beaucoup plus facile de se réorienter tôt, que ce soit sur les aspects internes ou la fonctionnalité réelle, que de se retrouver de l'autre côté de 2000+ lignes de code sans aucune idée de ce qui est cassé.

Vous avez probablement l'impression d'avoir trop de pull requests

Vous n'avez pas trop de PRs. Vous avez trop de mauvaises PRs.

Nous avons tous relu beaucoup de PRs qui nécessitaient une refonte, et ce depuis bien avant l'IA.

Mais une bonne PR est un plaisir à relire. Vous parcourez chaque fichier, le code est propre, il suit toutes vos décisions/discussions/opinions durement acquises sur la façon dont le logiciel devrait être.

D'un autre côté, si une Pull Request nécessite ne serait-ce que 20% de refonte (et c'est généreux, je dirais que la plupart des PRs d'IA en un seul coup tendent vers 50%), c'est à la fois un fardeau intellectuel et un fardeau émotionnel pour le soumissionnaire et le relecteur. (Même si le soumissionnaire est une IA, quelqu'un a probablement lancé ce travail ou poli le résultat de l'IA ou, à tout le moins, se soucie du résultat).

Pour vous faire gagner du temps (nous touchons presque à la fin), j'ai divagué davantage à ce sujet dans une quête secondaire :

« où va le temps »

une théorie des contraintes (édition 2026)

Il est facile d'être un peu déçu par la thèse centrale ici : « pour l'instant, nous sommes coincés à lire le code ».

J'étais plutôt enthousiaste à l'idée d'un monde où nous pourrions simplement demander des choses et laisser les modèles cuisiner sans lire le code et obtenir un beau logiciel de production qui évolue avec le temps et ne part pas en vrille.

Mais ce que j'ai essayé de présenter ici ne sont rien d'autre que des contraintes. Les modèles sont bons pour certaines choses, moins bons pour d'autres. Comment optimiser votre processus à la lumière de ces contraintes ?

Les modèles sont bons pour certaines choses, moins bons pour d'autres. Comment optimiser votre processus à la lumière de ces contraintes ?

Il est possible que vous soyez trop occupé à essayer d'aller 10 à 100 fois plus vite et à vous convaincre que la qualité du code n'a plus d'importance, alors que vous pourriez accepter les contraintes et avancer 2 à 3 fois plus vite, en toute sécurité.

Mon genre de conseil de clôture ici est fondamentalement :

1. Apprenez bien les contraintes, développez votre intuition en travaillant beaucoup avec les modèles
2. Optimisez les systèmes dans l'arène de ces contraintes
3. Cherchez le levier
4. Lisez ce satané code

C'est tout. Si vous voulez rester pour le pitch, continuez à défiler je suppose. J'espère que cela vous aidera à éviter un désastre ou qu'au moins vous vous êtes amusé à regarder quelques jolies petites animations.

Merci d'avoir lu

-dex

PS Nous sommes obsédés par ça

Nous construisons humanlayer.com, un IDE agentique et une plateforme de collaboration pour vous aider à avancer 2 à 3 fois plus vite tout en maintenant un niveau de qualité de code humain (ou assez proche de l'humain).

Nous construisons autour de deux idées : « les blocs de construction pour votre usine logicielle » et « de meilleurs vérificateurs pour la maintenabilité des logiciels » (peut-être même de meilleurs modèles).

HumanLayer est gratuit pour les petites équipes jusqu'à 3 personnes, et si vous voulez de l'aide pour démarrer, vous pouvez venir traîner sur notre discord ou nous envoyer un ligne à founders@humanlayer.dev

Un grand merci à @calvinfo pour l'inspiration, à mon co-fondateur @0xBlacklight, à @swyx et à l'équipe de @aiDotEngineer pour m'avoir donné une arène pour explorer ces idées, et à tous nos incroyables clients, investisseurs, amis et famille qui nous encouragent.

Si vous voulez en savoir plus, je ne peux fondamentalement pas la fermer là-dessus, donc vous pouvez trouver tous les liens de cet article ainsi que quelques autres projections du contenu dans des podcasts, un whiteboard long format, etc., ci-dessous.

PPS Autres ressources

Podcasts et Articles :

• Dex et Gergely parlent d'ingénierie de contexte et d'usines logicielles sur The Pragmatic Engineer - Juillet 2026
• Dex et Matt Pocock parlent de conseils de codage IA intemporels (et de boucles ralph) - Janvier 2026

Épisodes AI That Works :

• Les benchmarks ne prouvent rien
• Spécifications Produit pour le Codage IA
• Tests d'Apprentissage pour une meilleure contre-pression
• Appliquer les principes des agents 12-factor au codage IA

Liens de cet article :

• Pourquoi les usines logicielles échouent — Keynote AI Engineer World's Fair 2026
• L'usine logicielle lights-off de StrongDM
• OpenAI : Ingénierie de Harnais (Fév 2026)
• Ryan Lopopolo sur Symphony (talk, Avr 2026)
• Mario à AI Engineer Europe : « Construire pi dans un monde de slop »
• FT : Pannes Amazon dues à des incidents d'agents de codage
• Matt Pocock : les codebases qui s'effondrent
• Faros AI : le rapport sur le coup de fouet de l'accélération IA
• Advanced Context Engineering for Coding Agents (talk 25/08)
• No Vibes Allowed (talk 11/25)
• Everything We Got Wrong About RPI (talk 3/26)
• Awesome-RLVR - Ressources sur l'apprentissage par renforcement
• Advanced Context Engineering for Coding Agents (article détaillé)
• 12-Factor Agents
• Addy Osmani sur le vibe-coding vs. la maintenance
• Conférence de l'OTAN sur le génie logiciel, 1968
• DoD DevSecOps Reference Design (PDF)
• La plateforme d'agent de codage de Ramp
• Stripe : Minions, agents de codage de bout en bout en un seul coup
• WorkOS : Project Horizon
• Brex (Latent Space)
• Dan Shapiro : les cinq niveaux de l'usine logicielle
• Simon Willison sur l'usine logicielle de StrongDM
• « Boil the ocean »
• Shotgun surgery (refactoring.guru)
• John Ousterhout — A Philosophy of Software Design
• Robert C. Martin — Clean Code
• Martin Fowler — Refactoring
• aider
• cline
• codebuff
• SWE-Agent paper (2024)
• OpenAI Codex talk (Nov)
• Calvin French-Owen — AI Council talk
• SWE-bench Multilingual (dataset)
• AIE Worlds Fair 2026 - The Great Loops Debate (« le battage médiatique dépasse la discipline »)
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Mutation testing (Wikipedia)
• Dillon Mulroy sur les graphes d'appels dans la planification
• Dex × Matt Pocock : tranches verticales / balles traçantes (livestream, Jan 2026)
• « Le travail difficile de la réflexion ne peut pas être sous-traité » (Jake Nations)