- Cas d’expérimentation d’un produit logiciel interne en bêta construit avec la contrainte fixe de 0 ligne de code écrite manuellement, où Codex a rédigé la logique applicative, les tests, la configuration CI, la documentation, l’observabilité et même les outils internes
- En partant d’un dépôt git vide, la base de code a atteint environ 1 million de lignes en près de 5 mois, avec un débit de PR d’environ 1 500 PR ouvertes et fusionnées par trois ingénieurs pilotant Codex
- Le travail principal des ingénieurs s’est déplacé de l’écriture du code vers la conception de l’environnement, la spécification des intentions et la mise en place de boucles de feedback permettant aux agents de travailler de manière fiable
- La connaissance du dépôt est gérée via un
AGENTS.mdconcis, undocs/structuré, des plans d’exécution, des linters et la CI, tandis que l’UI, les logs, les métriques et les traces sont transformés en lisibilité applicative que Codex peut lire et vérifier directement - Avec l’augmentation du débit, la réduction au minimum des portes de fusion et les corrections par exécutions de suivi sont devenues un choix pratique, mais la cohérence architecturale à long terme et l’encodage du jugement humain restent encore des sujets d’apprentissage
Une bêta interne construite avec 0 ligne de code écrite manuellement
- Expérience menée ces 5 derniers mois pour construire et lancer un produit logiciel interne en bêta avec 0 ligne de code écrite manuellement
- Le produit compte des utilisateurs internes quotidiens et des testeurs alpha externes, et traverse réellement les cycles de lancement, de déploiement, d’incident et de correction
- Toutes les lignes de code, de la logique applicative aux tests, à la configuration CI, à la documentation, à l’observabilité et aux outils internes, ont été écrites par Codex, avec une estimation d’un temps de construction d’environ un dixième de celui d’une écriture manuelle
- Les humains pilotent, les agents exécutent
- Le résultat final, qui a fini par atteindre environ 1 million de lignes en quelques semaines avant lancement, a obligé l’équipe d’ingénierie à déplacer son travail principal de l’écriture de code vers la conception de l’environnement, la spécification des intentions et la création de boucles de feedback
En partant d’un dépôt git vide
- Le premier commit du dépôt vide a eu lieu fin août 2025
- Le scaffold initial — structure du dépôt, configuration CI, règles de formatage, configuration du gestionnaire de paquets et framework applicatif — a été généré par Codex CLI utilisant GPT-5 à partir de quelques indications issues de templates existants
- Le fichier initial
AGENTS.md, qui guide la façon dont l’agent travaille dans le dépôt, a lui aussi été rédigé par Codex - Il n’y avait pas de code humain préexistant pour soutenir le système, et le dépôt a été façonné par l’agent dès le départ
- Cinq mois plus tard, le dépôt atteignait environ 1 million de lignes couvrant la logique applicative, l’infrastructure, les outils, la documentation et les utilitaires internes pour développeurs
- Trois ingénieurs ont piloté Codex pour ouvrir et fusionner environ 1 500 PR, soit un débit moyen de 3,5 PR par jour et par ingénieur
- Le débit a encore augmenté depuis que l’équipe est passée à sept ingénieurs
- Le résultat n’est pas un simple volume de sortie pour le principe : le produit est utilisé par des centaines d’utilisateurs internes, dont des power users internes
- Pendant tout le processus de développement, les humains n’ont pas contribué directement au code, et l’absence de code écrit manuellement est restée une philosophie centrale de l’équipe
Redéfinir le rôle de l’ingénieur
- La contrainte consistant à ne pas coder directement introduit une autre forme de travail d’ingénierie, axée sur les systèmes, le scaffolding et l’effet de levier
- Les premiers progrès ont été plus lents que prévu, non pas à cause d’un manque de capacités de Codex, mais parce que l’environnement n’était pas suffisamment spécifié
- L’agent manquait d’outils, d’abstractions et de structure interne pour progresser vers des objectifs de haut niveau
- Le travail principal de l’équipe d’ingénierie est devenu de rendre possible un travail utile de la part des agents
- En pratique, le travail suit une approche en profondeur : découper les grands objectifs en blocs plus petits comme conception, code, revue et tests, demander à l’agent de construire ces blocs, puis s’en servir comme tremplins vers des tâches plus complexes
- En cas d’échec, la solution n’est pas « essayer plus fort », mais identifier quelle capacité manque pour permettre à Codex de faire le travail, puis la rendre lisible et exploitable par l’agent
- Les humains interagissent principalement avec le système via des prompts, où l’ingénieur décrit une tâche, exécute l’agent, puis lui fait ouvrir une PR
- Dans le processus de finalisation d’une PR, Codex relit localement ses propres changements, sollicite des revues d’agents supplémentaires en local et dans le cloud, répond aux retours humains ou agents, puis itère jusqu’à satisfaction de tous les relecteurs agents, dans une logique proche de la Ralph Wiggum Loop
- Codex utilise directement des outils de développement standards comme
gh, des scripts locaux et des skills intégrés au dépôt pour collecter du contexte sans copier-coller humain - Les humains peuvent relire les PR, mais ce n’est pas obligatoire ; avec le temps, presque tout le travail de revue a basculé vers des traitements entre agents
Accroître la lisibilité de l’application
- À mesure que le débit de code augmentait, le goulet d’étranglement s’est déplacé vers la capacité de QA humaine
- Comme la contrainte fixe portait sur le temps et l’attention des humains, les capacités des agents ont été étendues en rendant directement lisibles par Codex l’UI de l’application, les logs et les métriques de l’app elle-même
- L’application est conçue pour pouvoir démarrer par git worktree, afin que Codex puisse lancer et manipuler une instance pour chaque changement
- Le Chrome DevTools Protocol a été connecté au runtime de l’agent, avec création de skills pour les snapshots DOM, les captures d’écran et les actions de navigation
- Codex peut ainsi reproduire des bugs, vérifier des correctifs et raisonner directement sur le comportement de l’UI
- Les logs, métriques et traces sont exposés à Codex via une stack d’observabilité locale et temporaire propre à un worktree donné
- Codex travaille sur une version complètement isolée de l’application, incluant logs et métriques, qui sont supprimés une fois le travail terminé
- L’agent interroge les logs avec LogQL et les métriques avec PromQL
- Des prompts comme « garantir que le démarrage du service se termine en moins de 800 ms » ou « garantir qu’aucun span sur quatre parcours utilisateur clés ne dépasse 2 secondes » deviennent ainsi des tâches exécutables
- Il est fréquent qu’une seule exécution de Codex travaille plus de 6 heures sur une tâche, souvent pendant que l’humain dort
Transformer la connaissance du dépôt en système d’enregistrement
- L’un des principaux défis pour rendre un agent efficace sur des tâches vastes et complexes est la gestion du contexte
- Codex n’a pas besoin d’un manuel de 1 000 pages, mais d’une carte
- Le contexte est une ressource rare, et un énorme fichier d’instructions évince les tâches, le code et les documents pertinents, ce qui pousse l’agent à manquer des contraintes essentielles ou à optimiser les mauvaises
- Trop de guidage cesse d’être du guidage : quand tout devient important, plus rien ne l’est, et l’agent reste dans le pattern matching local au lieu d’explorer de manière intentionnelle
- Un manuel monolithique devient immédiatement obsolète, risque de se transformer en cimetière de règles périmées et en distraction séduisante que personne ne maintient
- Un fichier monobloc rend la vérification mécanique de la couverture, de l’actualité, de la propriété et des liens croisés difficile, ce qui rend la dérive inévitable
AGENTS.mdest traité non comme une encyclopédie mais comme une table des matières- La base de connaissances du dépôt se trouve dans un répertoire
docs/structuré, traité comme système d’enregistrement - Un
AGENTS.mdcourt d’environ 100 lignes est injecté dans le contexte et sert de carte vers des sources de vérité plus profondes - Les documents de conception sont catalogués et indexés avec un ensemble central de convictions définissant l’état de validation et les principes d’exploitation agent-first
- Le document d’architecture fournit la carte de plus haut niveau du domaine et des couches de packages
- Les documents qualité notent chaque domaine produit et chaque couche architecturale, et suivent les écarts dans le temps
- Les plans sont traités comme des artefacts de premier ordre : les petits changements utilisent des plans légers et temporaires, tandis que les tâches complexes sont enregistrées dans le dépôt sous forme de plans d’exécution incluant l’avancement et un journal de décisions
- Les plans actifs, les plans terminés et la dette technique connue sont tous versionnés et co-localisés, permettant à l’agent de travailler sans dépendre de contexte externe
- Cette structure permet une divulgation progressive : l’agent démarre depuis un point d’entrée petit et stable au lieu d’être submergé d’emblée, puis apprend où regarder ensuite
- Des linters dédiés et des jobs CI vérifient l’actualité de la base de connaissances, les liens croisés et la justesse structurelle
- Un agent récurrent d’entretien documentaire repère les documents anciens ou obsolètes qui ne reflètent plus le comportement réel du code et génère des PR de correction
La lisibilité pour les agents comme objectif
- Comme l’ensemble de la base de code est un produit d’agent, l’optimisation prioritaire est la lisibilité pour Codex
- De la même manière qu’on aide un nouvel ingénieur à explorer le code, l’objectif des ingénieurs humains est de permettre à l’agent d’inférer tout le domaine métier directement depuis le dépôt lui-même
- Du point de vue de l’agent, ce qui n’est pas accessible dans le contexte d’exécution n’existe pratiquement pas
- Les connaissances dans Google Docs, les fils de discussion ou la tête des gens ne sont pas accessibles au système ; seuls le code, le Markdown, les schémas et les plans d’exécution versionnés localement dans le dépôt sont visibles par l’agent
- Même si l’équipe s’est accordée sur un pattern architectural dans une discussion Slack, si l’agent ne peut pas le découvrir, cela revient à une connaissance inconnue d’un nouveau venu arrivé trois mois plus tard
- Donner plus de contexte à Codex ne consiste pas à déverser des instructions arbitraires, mais à organiser et exposer la bonne information pour que l’agent puisse raisonner
- Comme pour l’onboarding d’un nouveau membre d’équipe aux principes produit, aux normes d’ingénierie, à la culture de l’équipe et même aux préférences d’emojis, fournir ces informations à l’agent conduit à des sorties mieux alignées
- Les dépendances et abstractions sont de préférence totalement internalisées dans le dépôt et directement raisonnables
- Les technologies souvent jugées « ennuyeuses » sont en général plus faciles à modéliser pour les agents grâce à leur composabilité, à la stabilité de leurs API et à leur représentation dans les données d’apprentissage
- Dans certains cas, il est moins coûteux que l’agent réimplémente une partie d’une fonctionnalité plutôt que de contourner le comportement de haut niveau opaque d’une bibliothèque publique
- Au lieu d’importer un package générique de style
p-limit, l’équipe a implémenté son propre helper map-with-concurrency, étroitement intégré à l’instrumentation OpenTelemetry, avec une couverture de test à 100 % et un comportement correspondant exactement aux attentes du runtime - Plus le système est ramené sous une forme que l’agent peut inspecter, vérifier et corriger directement, plus l’effet de levier augmente non seulement pour Codex, mais aussi pour d’autres agents comme Aardvark travaillant sur la même base de code
Imposer l’architecture et les préférences
- La documentation seule ne suffit pas à maintenir la cohérence d’une base de code entièrement générée par agent
- En imposant des invariants sans microgérer les détails d’implémentation, on permet à l’agent de livrer vite sans fragiliser les fondations
- On demande à Codex de parser la forme des données à la frontière, sans pour autant lui imposer précisément comment le faire
- Les agents sont les plus efficaces dans des environnements avec des frontières strictes et une structure prévisible, donc l’application est organisée autour d’un modèle architectural robuste
- Chaque domaine métier est découpé en un ensemble fixe de couches, avec des directions de dépendance et des connexions autorisées strictement vérifiées
- Cette contrainte est imposée mécaniquement par des linters sur mesure et des tests structurels générés par Codex
- Dans chaque domaine métier, le code ne peut dépendre qu’en avant selon les couches fixes
Types → Config → Repo → Service → Runtime → UI - Les préoccupations transverses comme l’authentification, les connecteurs, la télémétrie ou les feature flags ne peuvent entrer que via une unique interface explicite appelée
Providers - Toute autre dépendance est interdite et bloquée mécaniquement
- Ce type d’architecture est souvent repoussé jusqu’à avoir des centaines d’ingénieurs, mais dans un environnement avec agents de codage, c’est une précondition précoce pour maintenir la vitesse tout en évitant la corruption et la dérive architecturale
- En pratique, les règles sont imposées par des linters personnalisés, des tests structurels et un petit ensemble d’« invariants de préférence »
- Le logging structuré, les conventions de nommage des schémas et des types, les limites de taille de fichiers et les exigences de fiabilité propres à chaque plateforme sont imposés statiquement par des règles de lint personnalisées
- Les messages d’erreur de ces règles sont rédigés pour injecter des consignes de correction dans le contexte de l’agent
- Dans un workflow centré humain, ces règles pourraient sembler excessivement tatillonnes ou contraignantes, mais dans un environnement agentique, une règle encodée une fois devient un multiplicateur appliqué partout en même temps
- Le centre gère fortement les frontières, la justesse et la reproductibilité, tandis qu’à l’intérieur de ce cadre, les équipes ou les agents gardent une grande liberté d’expression dans la manière de résoudre
- Le code produit ne correspond pas toujours aux préférences stylistiques humaines, mais s’il est correct, maintenable et lisible pour les futures exécutions d’agents, le critère est rempli
- Les préférences humaines continuent d’être réinjectées via des commentaires de revue, des PR de refactoring et des bugs visibles côté utilisateur, ce qui alimente des mises à jour de documentation ou d’outillage
- Quand la documentation ne suffit pas, la règle est promue en code
Une philosophie de fusion transformée par le débit
- Avec l’augmentation du débit de Codex, une grande partie des normes d’ingénierie traditionnelles est devenue contre-productive
- Le dépôt fonctionne avec un minimum de portes de fusion bloquantes
- Les PR restent courtes
- Les flakes de tests sont souvent traités par des exécutions de suivi plutôt que de bloquer indéfiniment l’avancement
- Dans un système où le débit des agents dépasse largement l’attention humaine, le coût de correction est faible et le coût d’attente élevé
- Cette approche pourrait être irresponsable dans un environnement à faible débit, mais dans ce contexte c’est souvent le bon compromis
Ce que recouvre réellement « généré par agent »
- Dire que la base de code est générée par des agents Codex signifie tout ce qui se trouve dans cette base
- Ce que les agents produisent
- Le code produit et les tests
- La configuration CI et les outils de release
- Les outils internes pour développeurs
- La documentation et l’historique de conception
- Les harness d’évaluation
- Les commentaires de revue et les réponses
- Les scripts qui gèrent le dépôt lui-même
- Les fichiers de définition des dashboards de production
- Les humains restent toujours dans la boucle, mais travaillent à un niveau d’abstraction plus élevé qu’auparavant
- Les humains définissent les priorités, traduisent les retours utilisateurs en critères d’acceptation et valident les résultats
- Quand l’agent rencontre une difficulté, c’est traité comme un signal indiquant si l’élément manquant est l’outillage, les garde-fous ou la documentation, puis cette correction est réinjectée dans le dépôt pour être elle aussi écrite par Codex
- Les agents utilisent directement les outils standard de développement, récupèrent les retours de revue, répondent en ligne, poussent les mises à jour et fusionnent souvent leurs propres PR après squash
Relever le niveau d’autonomie
- Comme les tests, la validation, la revue, le traitement du feedback et la récupération sont de plus en plus encodés dans le système, Codex a récemment franchi le seuil où il peut porter une nouvelle fonctionnalité de bout en bout
- Ce qu’un agent peut faire à partir d’un seul prompt
- Vérifier l’état actuel de la base de code
- Reproduire un bug signalé
- Enregistrer une vidéo montrant l’échec
- Implémenter le correctif
- Vérifier le correctif en manipulant directement l’application
- Enregistrer une seconde vidéo montrant la résolution
- Ouvrir une PR
- Répondre aux retours des agents et des humains
- Détecter et corriger les échecs de build
- N’escalader vers un humain qu’en cas de besoin de jugement
- Fusionner le changement
- Ce comportement dépend fortement de la structure et de l’outillage spécifiques de ce dépôt, et il ne faut pas supposer qu’il se généralise sans investissements comparables
Entropie et garbage collection
- L’autonomie complète des agents introduit aussi de nouveaux problèmes
- Codex reproduit les patterns déjà présents dans le dépôt, même s’ils sont inégaux ou non optimaux
- Avec le temps, cette répétition conduit à de la dérive
- Au début, les humains s’en occupaient manuellement, et l’équipe consacrait chaque vendredi, soit 20 % du temps hebdomadaire, au nettoyage de l’« AI slop »
- Comme cette approche ne passait pas à l’échelle, les « principes d’or » ont été encodés directement dans le dépôt, avec un processus de nettoyage récurrent
- Les principes d’or sont des règles mécaniques fortes visant à garder la base de code lisible et cohérente pour les futures exécutions d’agents
- Un exemple consiste à préférer des packages utilitaires partagés à des helpers faits maison afin de centraliser les invariants
- Un autre consiste à valider les frontières ou à s’appuyer sur des SDK typés, plutôt que d’explorer les données « en mode YOLO » pour éviter que l’agent ne construise accidentellement sur des formes supposées
- Régulièrement, des tâches Codex en arrière-plan analysent les écarts, mettent à jour les notes de qualité et génèrent des PR de refactoring ciblées
- La plupart des PR de refactoring peuvent être relues en moins d’une minute et fusionnées automatiquement
- Ce processus fonctionne comme une garbage collection
- La dette technique ressemble à un prêt à taux élevé : il vaut presque toujours mieux la rembourser en continu par petites unités que la laisser s’accumuler puis la traiter douloureusement d’un coup
- Les préférences humaines, une fois capturées, peuvent être imposées en continu à toutes les lignes de code
- Les mauvais patterns peuvent être détectés et corrigés chaque jour avant de se propager pendant des jours ou des semaines dans la base de code
Encore en phase d’apprentissage
- Jusqu’ici, cette stratégie fonctionne bien pour les lancements internes et les phases d’adoption chez OpenAI
- Construire de vrais produits pour de vrais utilisateurs ancre l’investissement dans la réalité et pousse vers la maintenabilité de long terme
- On ignore encore comment la cohérence architecturale d’un système entièrement généré par agent évoluera sur plusieurs années
- L’équipe continue aussi d’apprendre où le jugement humain apporte le plus de levier, et comment encoder ce jugement pour produire un effet cumulatif
- On ne sait pas encore non plus comment ce système évoluera à mesure que les modèles deviendront plus compétents avec le temps
- Ce qui est devenu clair, c’est que construire du logiciel exige toujours de la discipline, mais qu’elle se manifeste davantage dans le scaffolding que dans le code
- L’importance des outils, des abstractions et des boucles de feedback qui maintiennent la cohérence de la base de code continue d’augmenter
- Le défi le plus difficile aujourd’hui est de concevoir les environnements, les boucles de feedback et les systèmes de contrôle qui aident les agents à construire et maintenir à grande échelle des logiciels complexes et fiables
- Plus des agents comme Codex prennent en charge une part importante du cycle de vie logiciel, plus ces questions deviennent importantes
- Les premiers enseignements aident à juger où investir les efforts pour simplement pouvoir construire quelque chose
1 commentaires
Avis Hacker News
Le débit est à un niveau absurde. Je me demande quelle référence il faut prendre. Avant le code piloté par des agents, combien de PR attendait-on en général d’un ingénieur ? Peut-être 2 à 10 par jour ?
Je me demande aussi si, sur les 6 derniers mois, les logiciels vous semblent meilleurs. Si le nombre d’ingénieurs reste similaire, le cycle d’itération des principales applications logicielles devrait être environ 5 fois plus rapide, mais ça ne donne pas cette impression. Les applis IA changent très vite, mais c’est un domaine tellement nouveau que c’est prévisible ; ailleurs, on le ressent beaucoup moins
Ici, on a 1 500 PR pour 1 million de lignes, donc une augmentation nette d’environ 650 lignes par PR. Cela ne veut pas dire que chaque PR fait 650 lignes au total, mais que le solde ajouts moins suppressions est de +650 lignes
Quelques questions pour les lecteurs attentifs. À quoi ressemble, dans 10 ans, un projet qui grossit chaque année d’un volume équivalent à une base de code Firefox ? Que disent les lignes de code sur la verbosité des outils, et que dit l’absence de présentation claire de l’objectif du projet sur le résultat ? Dans un monde où les humains n’écrivent plus directement le code, y a-t-il encore une raison de se soucier du nombre de lignes ? Si la base de code devient beaucoup plus grosse, qu’arrive-t-il à la consommation de tokens ? Si l’on confirme que l’usage des LLM fait exploser le nombre de lignes, qu’est-ce que cela implique pour une base de code qui, après quelques mois d’utilisation, voudrait revenir au codage manuel à cause des coûts ?
Étrangement, la plupart des usages des « agents » servent encore à fabriquer un autre produit IA. C’est des tortues jusqu’en bas. Cela en dit peut-être plus sur le domaine de Harness que sur la puissance des « agents »
Il suffit de regarder MS Office : il y a récemment eu beaucoup de petits changements, et la plupart sont agaçants. Par exemple, dans Word, si on @tague un collègue dans un commentaire, le focus disparaît ; ou dans Outlook, il faut cliquer deux fois pour saisir dans la barre de recherche ; ou encore le sélecteur de date d’Outlook mobile semble avoir perdu la fonction qui montrait mes disponibilités et celles des participants
Donc oui, le débit a l’air élevé, mais malheureusement on casse des fonctionnalités qui marchaient bien. Ou bien on passe du temps sur des choses sans importance, comme la barre d’état de recherche OneDrive qui tourne autour du champ de saisie
L’idée, c’est que je reste au volant et garde le contrôle sur l’essentiel du code écrit, tandis que l’IA sert à renforcer l’état de flow et à supprimer les blocages. Je voudrais que l’outil ne fasse que le minimum en génération de code réelle
Nous menons la même expérience depuis 5 mois sur tsz[1], et nous sommes arrivés à des conclusions très proches. Il faut beaucoup de harnais pour imposer une bonne séparation architecturale, et il faut aussi beaucoup de tests et de CI
Le but de tsz est d’apprendre à mener de très gros projets avec l’IA. À terme, le même workflow et le même état d’esprit peuvent aussi servir à construire des applications produit orientées client avec UI. OpenAI semble utiliser des tests de navigateur automatisés, et même de la vidéo, dans son workflow. À mesure que les modèles progresseront, cette manière de produire du logiciel finira probablement par avoir du sens, mais à mon avis on n’y est pas encore. Au moins, contrairement aux affirmations vagues d’OpenAI, on peut partager le résultat et le voir directement
Les solutions comme Lovable, qui offrent un niveau d’automatisation très élevé, me paraissent un peu trop optimistes et pas assez étroitement couplées à beaucoup de tests automatisés
[1] https://github.com/tsz-org/tsz
Cela recoupe exactement ma façon de faire. Je donne à Claude/Codex les moyens de vérifier leur propre travail : navigateur, smoke tests, tests end-to-end, environnements locaux à haute fidélité, etc.
Je garde tout le contexte — suivi des issues, documentation, idées, plans, journaux de travail — dans le dépôt (https://github.com/shepherdjerred/monorepo/tree/main/package...)
Je donne à Claude/Codex l’accès à des outils d’observabilité comme Grafana, Prometheus, Tempo et PagerDuty, et je leur fais suivre de bonnes règles d’ingénierie : fail fast, sûreté de typage, parsing aux frontières, etc.
En revanche, avec mon homelab, je n’ai pas encore atteint l’autonomie complète à cause des coûts et de la charge CI
J’ai récemment vu une vidéo d’ouvriers dans une usine de cigarettes électroniques. Ils prenaient un lot sur le tapis roulant, en mettaient une à la bouche, tiraient dessus pendant environ 5 secondes pour tester, puis passaient au lot suivant. Examiner des centaines de lignes modifiées dans une PR écrite par l’IA, ce n’est pas si différent
Ce n’est pas le cas des PR. Une seule mauvaise PR peut être fatale pour l’activité, alors qu’une seule mauvaise cigarette électronique ne l’est généralement pas
En outre, quand des ingénieurs logiciel échantillonnent les sorties de l’IA, ils constatent que la qualité actuelle n’atteint pas de façon constante le niveau requis pour un produit. Il faut donc relire toutes les PR et en corriger une part importante
Une approche par échantillonnage pourrait fonctionner si l’on peut limiter le rayon d’impact des changements et si les sorties deviennent généralement acceptables sans supervision, au point qu’en usine il suffise de faire une double vérification de l’absence de régressions
Je suis l’un des trois ingénieurs qui ont écrit cet article. Je peux répondre aux questions s’il y en a.
Je ne suis pas sceptique vis-à-vis de l’IA, mais l’intention de cet article me paraît douteuse. Il avance de grandes affirmations sur l’ingénierie agent-first en s’appuyant sur un vrai produit, de vrais utilisateurs et une vraie équipe en croissance, en donnant l’impression d’un cas concret, mais sans jamais dire ni montrer ce qui a été construit. C’est exactement comme tous les autres articles d’emballement autour de l’IA.
Ça ne peut fonctionner que si on dispose de ressources de calcul infinies et d’un nombre infini de tokens
Pour avoir utilisé l’offre à 20 $, cette approche purement agentique est impossible. On atteint très vite les limites, et on obtient moins de résultats.
Ce qui a très bien marché, c’est de fournir comme référence du code écrit par un humain et de demander au modèle de l’étendre. On pose toute la structure, on conçoit l’architecture, puis on écrit quelques exemples de code pour les contrôleurs, services, modèles, composants, schéma de base de données, méthode d’authentification, etc., afin de donner au LLM un point d’appui pour orienter son attention.
En général, j’écris des stubs qui détaillent la manière d’implémenter les choses. C’est une sorte de pseudo-code à un niveau d’abstraction plus élevé. Ensuite, je demande au LLM de faire l’implémentation.
Si ça échoue, il vaut souvent mieux annuler l’ensemble des modifications, ajuster les stubs pour qu’ils permettent d’attraper l’échec précédent, puis réessayer.
Ou alors valider les changements, puis ne traiter que ce qui ne va pas dans un nouveau contexte.
Quand j’essaie une approche agentique dès le départ, je suis toujours déçu à la fois par les résultats et par les limites. Il arrive même d’atteindre la limite avant une heure.
En passant à 200 $ par mois on peut en faire davantage, mais même pour quelqu’un qui l’utilise intensivement comme moi, ça manque toujours d’usage.
J’envie encore les gens qui ont reçu 200 fois plus d’usage juste parce qu’ils avaient confirmé leur présence à la fête OpenAI.
Encore un article commercial essoufflé de plus. On vend des pioches aux mineurs, mais où est l’or ? Où sont les produits incroyables réellement créés par des chatbots qui se parlent entre eux au-dessus de Git pour produire des tas de lignes de code ? On n’en voit absolument aucun.
J’aimerais que ce genre d’articles de blog exaltés soit un peu plus pédagogique
Par exemple, j’aimerais qu’on montre étape par étape comment configurer concrètement ce workflow présenté comme si puissant, avec une vraie démonstration.
Je ne suis pas sceptique vis-à-vis de l’IA. Au contraire, s’il existe un vrai superpouvoir, je ne veux pas le rater.
Pour les nouvelles fonctionnalités, j’écris des spécifications de fonctionnalités en Gherkin ; pour les améliorations, je les mets à jour ; pour les refactorings, je n’y touche pas. Dans les PR, j’ajoute des labels avec ces noms.
J’exécute en hook pre-push la vérification de types, le linting, les tests unitaires et d’autres validations rapides et scriptables.
Je crée un sous-site VitePress dans le dépôt et je le fais maintenir par l’agent. J’y documente les principes importants, l’architecture, etc.
Je crée une commande CLI qui liste toutes les pages et les descriptions du front matter YAML, afin que l’agent puisse choisir ce qu’il doit lire sans exploser la fenêtre de contexte.
J’utilise le domain-driven design et un monorepo. J’écris la logique dans des couches headless, puis je compose les couches en applications. Les agents explorent très bien les couches.
J’utilise zod, ou l’outil équivalent dans le langage concerné, ainsi qu’un développement d’API contract-first. Personnellement, c’est probablement la partie que je préfère, et j’utilise orpc.
Je ne crée qu’un seul skill appelé « code » et j’en décris le cycle de vie. Ouvrir un worktree, configurer le
.envpour éviter les conflits avec les autres agents, choisir des ports inutilisés, Docker est très bien pour ça. Écrire ou mettre à jour le fichier de fonctionnalité, aligner la spécification ici, puis implémenter, valider avec quelque chose comme playwright mcp, exécuter les vérifications avant push, attendre la revue après push, nettoyer, puis faire un fast-forward merge surmain.testcontainers est très utile pour garantir que plusieurs agents puissent exécuter des tests sans entrer en conflit.
Sérieusement, il n’y a qu’un seul skill. Tout le reste est dans la documentation. Je me sens très productif, non pas en nombre de lignes de code, mais au sens de « construire du bon logiciel ».
Pour cela, chaque fois que l’agent rencontrait un problème, je lui demandais comment le résoudre à l’aide d’un outil ou d’un script de validation. Pendant le processus d’audit, je lui ai aussi fait coder lui-même ce type d’outils. Résultat : j’ai maintenant plus de 30 règles de validation de commit[2], et ça fonctionne plutôt bien.
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (pour voir le mode « démo », il faut attendre la fin du minuteur)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Nous avons essayé cela au début. Avant d’écrire le moindre code, nous avons utilisé ChatGPT comme « chef de projet » pour lui faire mettre en place tout le harnais. Une semaine plus tard, nous avions plus de 140 documents sur les règles, l’architecture et les frameworks, et 0 ligne de code
Quand nous avons demandé plus tard à un autre outil de l’examiner, le verdict a été : « un coffre-fort vide parfaitement sécurisé ». Le harnais était irréprochable, mais il n’y avait rien dedans
Le harnais est important, mais si on ne le fait pas avancer en parallèle de la mise en production du code, on ne fait qu’écrire de la fiction