Une usine logicielle est une boucle reproductible autour du travail de développement. Si vous construisez une usine logicielle, un code suffisamment bon pour être livré a toujours besoin du goût et de la responsabilité humaine. Nous discuterons de cela, y compris si vous avez vraiment besoin d'une usine pour l'instant.
Si c'est le cas :
- Vous aurez probablement besoin d'humains dans la boucle au départ pour décider de l'intention du produit, de la conception du système (si cela vous importe) et de votre niveau de qualité.
- Faites des revues de code (usine allumée) mais soyez intentionnel là où c'est le plus nécessaire. J'ai constaté qu'il faut surveiller les endroits où la contre-pression automatisée échoue. Ou là où des compromis de maintenabilité doivent être faits.
- Visez à ce que les contrôles qualité aient lieu le plus tôt et le plus continuellement possible. Ils ne doivent pas tous l'être, mais cela inclut les systèmes de typage, les tests automatisés, les tests de mutation, les scanners de sécurité et le linting pour les règles d'architecture.
- Le nombre de contrôles n'est pas égal à la qualité. Vous devrez probablement expérimenter pour voir quels contrôles vous offrent le meilleur rapport signal/bruit. Soyez prêt à resserrer ou à assouplir vos contraintes délibérément.
Vous voulez construire votre usine de sorte que certains aspects du goût humain soient encodés dans l'environnement, que l'agent vous fournisse des preuves que son travail est correct et qu'un humain « possède » toujours ce qui est livré en production.
Avez-vous vraiment besoin d'une usine logicielle ?
D'après mon expérience, vous pouvez aller étonnamment loin avec votre harnais de codage standard ! Par exemple, Claude Code ou Codex, plusieurs sessions, de bonnes spécifications avec vérification intégrée et des contraintes. Vous pouvez même leur lancer un lot de tickets GitHub avec des critères de mise en œuvre et d'implication humaine. Les routines Claude Code et les agents cloud Copilot/Codex vous offrent déjà une boucle planifiée ou pilotée par les événements sans infrastructure personnalisée.
Une usine en vaut la peine si vous avez besoin de cycles reproductibles et cohérents, de transférer le travail entre agents, d'empêcher deux sessions de prendre le même ticket, de conserver les preuves et de mettre la production en pause lorsque les revues sont en retard.
J'ai donc commencé par dire qu'une usine logicielle est une boucle reproductible autour du travail de développement. Nous pouvons en fait examiner une invite qui démontre une très petite boucle d'usine ici :
Lisez le ticket GitHub #123 et les instructions du dépôt avant de modifier le code.
Implémentez uniquement les critères d'acceptation énoncés. Ne modifiez pas l'authentification, la facturation, les migrations ou les assertions de test existantes. Travaillez dans une branche et gardez le diff facile à revoir.
Exécutez npm run lint, npm test et npm run build. Si une vérification requise ne peut pas être exécutée, arrêtez-vous et expliquez pourquoi. Ouvrez une pull request en brouillon avec les vérifications que vous avez effectuées, les risques restants et toute décision qu'un humain doit encore prendre. Ne fusionnez pas.
Un objectif peut maintenir cela en mouvement jusqu'à ce que les vérifications réussissent et nous pouvons interroger les tickets GitHub chaque matin pour des libellés spécifiques ou examiner les pull requests ouvertes. La protection de branche pourrait imposer une limite de fusion et l'humain peut rester dans la boucle en choisissant ce qui devient prêt, en révisant et en prenant les décisions finales de fusion, etc.
Ajoutez une usine logicielle lorsque vous avez besoin d'une file d'attente de travail pilotée par les événements (par exemple, déclencheurs Slack, tickets GitHub, Linear, un backlog) pour s'exécuter dans un environnement cloud isolé afin de gérer le triage, l'implémentation et les tests avec une certaine supervision humaine explicite. Certaines terminent leur boucle avec un agent de surveillance qui observe la production et crée des tickets qui sont à nouveau triés.
D'après mon expérience, l'usine devient utile lorsque la partie difficile est de faire en sorte que vos différents cycles se comportent de manière cohérente, de transférer le travail entre agents et d'éviter que différentes sessions ne revendiquent le même ticket, de préserver les preuves et d'arrêter la production lorsque la revue humaine prend du retard.
Ce qui résout cela peut sembler un peu ennuyeux. Par exemple, Warp mentionne le tri de chaque ticket entrant dans l'un des quatre états - prêt-à-implémenter, prêt-à-spécifier, besoin-d'infos, attendre-pour-implémenter - et le libellé est ce qui déclenche l'agent suivant.
Ce libellé fait plusieurs choses à la fois : c'est la file d'attente, le verrou et, comme une session ne prend que ce qui est marqué comme prêt, c'est là qu'un humain peut mettre des choses de côté sans dire non définitivement.
En termes de flux de travail, il y a quelques similitudes et différences par rapport à l'utilisation simple de Claude/Codex :
- Orientation : l'agent a besoin d'une correction de cap, vous pouvez donner votre avis et le rediriger
- Notifications : comment l'usine dit qu'elle est bloquée. Cela peut être parce qu'une exigence était ambiguë, qu'elle a commencé quelque chose de risqué ou qu'elle a besoin d'une intervention humaine (orientation)
- Transfert : déplacer la tâche, son état et son contexte entre l'usine cloud/un autre agent/un réviseur humain. Les bons transferts garderont une trace de ce qui s'est passé, de ce qui reste à faire et de la raison pour laquelle le transfert est nécessaire.
Dans une bonne usine, l'humain ne se limite pas à réviser et approuver le diff final à la toute fin. Il peut façonner le travail en amont, l'orienter pendant l'implémentation, le faire passer par un transfert ou l'empêcher d'être livré en production.
La vérification est ce à quoi une usine responsable consacre beaucoup de son temps. Nous y reviendrons plus tard.
Si vous décidez que vous avez besoin d'une usine logicielle, la construire n'est pas la seule option. Mettre en place l'infrastructure pour faire évoluer une usine peut représenter beaucoup de travail et vous voudrez peut-être envisager d'acheter plutôt que de construire. Factory.ai, Devin, Warp et HumanLayer vendent tous une partie de cette boucle.
Où je concentre réellement mon attention
Mon expérience quotidienne du développement logiciel a beaucoup changé au cours de l'année écoulée. J'ai parlé de plus en plus de faire beaucoup de travail en parallèle avec des agents, en évoluant vers une usine logicielle allumée. Et beaucoup de gens me demandent ce que ces choses signifient réellement. Que construisez-vous ? Quels sont les types de projets sur lesquels vous utilisez ces choses ? C'est beaucoup de ça :
Donc, lors d'une journée très moyenne, j'ai une usine logicielle allumée plus simple. Je peux avoir des tâches qui s'exécutent dans le cloud. La moitié de ces tâches peuvent consister à travailler sur des applications client de production avec de petites entreprises avec lesquelles je travaille. Elles vont avoir de vrais utilisateurs. Elles vont avoir une véritable authentification, des paiements, des abonnements, de vrais risques importants avec lesquels il faut être prudent. Vous ne pouvez pas simplement dire, oh, agent, va faire ça sans avoir de tests, de contraintes et de contrôles qualité en place.
Je pourrais travailler sur mes projets open source. Je pourrais construire des sites compagnons pour mes livres. Je pourrais travailler sur des outils. Je pourrais construire mes propres applications. Et ce sont toutes des applications très, très différentes sur lesquelles je travaille. Et parfois, tout ce qu'elles ont en commun, c'est l'outil que j'utilise pour travailler dessus, n'est-ce pas ? Peut-être que je travaille sur une migration. D'autres fois, je fais peut-être du vrai travail de fonctionnalité lourd. Et le rayon d'impact du travail peut aussi être très, très différent.
Donc, lorsque vous commencez à réfléchir à la façon d'arriver à un endroit où nous faisons de plus en plus de travail en parallèle, où nous essayons d'améliorer la vélocité, la productivité et l'autonomie, ce qui signifie amener le système à un endroit où nous lui faisons plus confiance, vous devez réfléchir aux endroits qui nécessitent absolument une revue de code humaine, une intervention humaine.
Et une grande partie de cela sera nécessaire en amont, n'est-ce pas ? Lorsque vous définissez votre spécification, vos exigences, à quoi ressemblera la conception du produit ? Quelle sera l'intention du produit ? Et ensuite, comment vérifiez-vous que les agents ont réellement bien fait le travail ? Comment vérifiez-vous qu'ils n'ont pas cassé le système existant en place ? Comment vous assurez-vous que cela répond à votre niveau de qualité ?
Et donc, générer du code n'est pas nécessairement la partie qui doit le plus vous préoccuper. Avec suffisamment de contexte, les agents peuvent écrire l'implémentation, exécuter les tests, inspecter les échecs et réviser le code pour nous. Nous devons arriver à un endroit où nous sentons qu'il y a suffisamment de goût humain encodé dans l'environnement pour que nous puissions faire confiance à ce qui est construit, afin que notre attention humaine puisse être concentrée sur les endroits où elle est le plus nécessaire.
Maintenant, il y a des critiques de la part de personnes qui disent : « Je n'achète pas que vous puissiez simplement automatiser tout ça. » Il ne s'agit pas de dire que nous automatisons tout, n'est-ce pas ? Mais étant donné le volume de code généré, je ne pense pas qu'il soit réaliste pour les humains de tout lire, surtout quand nous ne construisons pas des fusées la plupart du temps, n'est-ce pas ? Nous construisons des interfaces utilisateur, nous construisons des applications full stack.
Notre jugement, notre goût est mieux concentré sur les endroits où il est le plus nécessaire. Par exemple, quelles sont les parties les plus risquées des systèmes ? Où devons-nous appliquer le goût humain ? Cela peut être dans le front-end. Cela peut être dans la façon dont le système fonctionne. Cela ne doit pas être 100 % du code.
Ma bande passante cognitive ne s'adapte pas avec les agents
La réalité est que, oui, nous pouvons maintenant lancer des dizaines, des centaines, des milliers d'agents en parallèle, mais votre propre bande passante cognitive ne s'adapte pas de la même manière. Cela peut alimenter une dette cognitive ou de compréhension dont j'ai déjà parlé.
Si vous vous souvenez d'il y a seulement cinq ou dix ans, il y avait beaucoup de discussions dans la communauté technique sur le changement de contexte et son coût. Nous parlions de la façon dont les gens détestaient qu'un collègue ou quelqu'un vienne à votre bureau alors que vous étiez en pleine tâche. Il vous fallait ensuite beaucoup de temps pour retrouver votre état de flow, car vous deviez vous remettre à niveau : où en étais-je ? Que faisais-je ? Même si vous aviez un petit résidu, cela vous prenait du temps.
Nous changeons maintenant de contexte encore plus qu'avant. Un jour donné, si je travaille en dehors d'une usine logicielle, je peux travailler sur cinq ou dix projets différents avec des agents en même temps, ou cinq ou dix fonctionnalités différentes sur un seul projet à la fois. Je peux avoir cinq ou dix sessions différentes, pour ainsi dire.
Cela signifie que je dois être capable de suivre au moins quelques-unes d'entre elles. Il est possible que je puisse augmenter l'autonomie que je donne à certaines tâches si j'ai confiance que j'ai bien défini la tâche, que j'ai défini le résultat, comment elle va vérifier qu'elle est bien faite. Mais il y aura des tâches où je ne me sentirai peut-être pas nécessairement comme ça et où il y a plus de risque ou plus de nuances. Je vais devoir y prêter attention.
Envisagez d'optimiser l'usine logicielle pour votre réviseur. Étant donné que chacune de ces approches achemine toujours sa sortie vers l'attention d'une seule personne, vous devriez vous demander combien l'usine rend moins coûteuses les décisions que vous devez encore prendre.
Une erreur de mauvais projet
Je me souviens avoir travaillé sur plusieurs projets en parallèle avec mes agents, et il m'est arrivé de faire accidentellement des choses comme, peut-être que je travaillais sur une application web où je voulais ajouter un mode sombre, et j'avais donc dans ma tête, ok, voilà à quoi cela doit ressembler. Mais je suis accidentellement allé dans la session d'un projet différent, et j'ai commencé à mettre la même invite.
J'ai donc commencé à implémenter le mode sombre pour quelque chose qui n'en avait absolument pas besoin. Et donc je peux faire cette erreur. Je ne veux pas que mon usine logicielle fasse ce genre d'erreur.
Vous devez vraiment penser à cela en termes de système. Vous essayez effectivement d'encoder une culture d'ingénierie logicielle, une culture d'équipe, dans un système afin qu'il ait les mêmes types de comportements, afin qu'il y ait une responsabilité quelque part, afin que quelqu'un soit toujours responsable de ce qui se passe, et que vous soyez très explicite sur la façon dont vous pensez à ces choses.
Quand le vert est trompeur
Même dans ces systèmes, vous voulez être très prudent, n'est-ce pas ? Beaucoup d'entre nous ont vu que lorsque vous avez demandé à l'IA de vous aider à réussir un test, comme un test de programmation, un test unitaire, elle peut modifier le test unitaire pour satisfaire cette condition, ou elle peut modifier la logique du code pour passer cette condition. Cela ne signifie pas qu'elle a réellement suivi votre intention pour aligner à la fois le comportement fonctionnel et ce que le test était censé tester, n'est-ce pas ?
Ce n'est pas parce qu'une usine logicielle montre que tout est vert que c'est réellement vert, surtout au début lorsque vous mettez ces choses en place. Vous devez faire très attention pour vous assurer que vos contrôles, vos vérifications, tout cela est configuré correctement. Ils font ce que vous attendez d'eux. Vous ne voulez pas qu'ils soient trompeurs.
Vous ne voulez pas d'une situation où vous aviez des tests qui disaient : « Hé, en fait, j'ai changé les fournisseurs d'authentification pris en charge. Vous m'avez demandé d'ajouter GitHub par exemple comme fournisseur d'authentification, mais mon interface utilisateur n'avait de la place que pour trois, donc j'ai supprimé l'un des autres. Et au fait, il se trouve que c'était celui que vos clients voulaient réellement. » Vous devez donc être très explicite sur la façon dont vous voulez que ces systèmes fonctionnent.
Au fait, la sécurité est aussi super importante et si votre usine lit des entrées non fiables comme un ticket GitHub/un message Slack, cela pourrait être adversarial et inclure des problèmes comme des attaques sur la chaîne d'approvisionnement. Certains produits autour des usines logicielles, comme Vercel Sandbox/AI ADK Factory, exécutent leurs agents dans des sandbox isolés contenant uniquement les secrets dont une tâche a besoin. De cette façon, un cycle compromis ne peut pas atteindre ce dont le travail n'a pas besoin. Votre défense finit par être en couches.
Quels anciens projets méritent une seconde vie ?
Je pense aussi qu'une grande partie de notre façon de travailler aujourd'hui consiste à décider ce qui devrait exister. Si vous vous souvenez d'il y a de nombreuses années, avant l'IA, il y avait tellement de projets d'ingénierie logicielle abandonnés, tellement de projets de week-end abandonnés, des projets personnels qui ne seraient tout simplement pas lancés parce que nous n'avions pas le temps de les terminer. Nous n'avions pas la bande passante pour prioriser leur sortie parce qu'ils n'étaient tout simplement pas si importants pour nous ou que nous ne trouvions pas le temps.
Maintenant, il est assez trivial pour nous de terminer ces projets, mais la même question de jugement humain se pose. Ces projets méritent-ils d'exister ? Devraient-ils être lancés ? Parce que vous les mettez dans le monde et même s'ils n'ont que cinq utilisateurs, vous devrez peut-être les maintenir. Vous avez peut-être maintenant un niveau de qualité que vous souhaitez maintenir.
Je sais que j'ai eu tellement de projets GitHub au fil des ans où maintenant que j'ai un agent, la première chose que je fais est de faire en sorte que le projet se construise. Parce que, bien sûr, vous le clonez et maintenant il ne se construit plus parce que toutes les dépendances ont changé. La moitié des choses sont obsolètes ou ont des vulnérabilités de sécurité partout, donc vous devez les mettre à jour.
Ensuite, vous devez ajouter des tests si vous n'en aviez pas, afin de savoir que le comportement sera au moins là si vous mettez le projet à niveau d'une manière ou d'une autre, ou si vous le migrez vers un langage ou un framework plus moderne ou quelque chose comme ça.
Ensuite, vous commencez à vous demander, eh bien, peut-être, un exemple stupide, mais peut-être que j'utilisais Twitter Bootstrap à l'époque pour cela, mais maintenant tout le monde utilise Tailwind et shadcn, donc je dois réimplémenter l'interface utilisateur. Et ce que vous remarquerez, c'est que soudainement, cela vous prend plus de temps, n'est-ce pas ? Oui, l'agent peut faire une grande partie de cela plus rapidement, mais vous devez maintenant prendre en compte le sens du produit, le goût et tout cela.
Vous vous demandez encore, eh bien, pour qui est-ce ? A-t-il un marché ? Est-ce pour moi ? Est-ce pour les autres ? Si je le mets dans le monde, sera-t-il toujours aussi intéressant étant donné que maintenant n'importe qui peut créer ces choses aussi rapidement ?
Donc, je pense que cette question humaine de savoir si ces choses méritent d'exister, comment intégrer notre goût et notre jugement, je pense que ces choses continuent d'être extrêmement importantes. C'est là que cette ressource rare qu'est l'attention humaine entre vraiment en jeu. À l'époque, nous n'avions qu'un nombre fini d'heures dans la journée. Nous avions des réunions. Nous devions budgétiser du temps pour la conception, le codage, etc.
Maintenant que nous avons des agents pour nous aider, je pense que vous devez vraiment être très explicite sur où vous passez votre temps et pourquoi.
Ce qui s'est passé quand j'ai construit un exemple
Je vais donc parler du cycle d'usine de 82 minutes. Les gens me demandent depuis un certain temps : « Comment construire une usine logicielle ? » Ou : « J'ai l'habitude d'utiliser Claude Code ou Codex. Comment faire évoluer ma configuration pour utiliser une usine logicielle ? »
Donc, la première chose que j'ai dite est : « Vous êtes peut-être très bien. Votre travail peut en fait être totalement correct sans avoir besoin d'une usine. » Mais je voulais donner aux gens une configuration de référence qu'ils peuvent consulter. Donc, ce que j'ai mis en place, c'est un dépôt appelé Factory que vous pouvez aller voir. J'ai également mis en place une application de démonstration et un atelier.
Maintenant, ces dernières années, mon application de démonstration de prédilection pour beaucoup de choses a été une application de films. Je suis un grand fan de films. J'adore regarder des films. Je regarde des films tout le temps, et j'ai donc une application de démonstration, qui commence vraiment comme une application de films très simple. Et ce que je veux que l'usine soit capable de faire, c'est d'aller de l'avant et d'implémenter un certain nombre de fonctionnalités. Il y a quelques fonctionnalités différentes. Je veux une fonctionnalité de favoris. Je veux qu'elle puisse peut-être faire une recherche, et peut-être aussi vouloir un thème sombre, ce genre de choses.
J'ai donc mon usine qui commence à travailler sur ces choses. Vous pouvez consulter l'implémentation. L'un des avantages a été de détecter de vrais problèmes. Ces problèmes n'auraient peut-être pas été détectés si je lui avais simplement demandé une implémentation en un seul coup.
Peut-être autour de la 60e minute, je me suis dit : « Wow, ça va anormalement lentement. » J'ai demandé à mon harnais en utilisant l'usine : « Pourquoi ça va lentement ? » Il a répondu : « C'est tout à fait normal. Tous les vérificateurs sont encore en cours d'exécution. »
Vous vous attendiez peut-être à ce que les tâches individuelles prennent 10 minutes, 15 minutes, 20 minutes, mais elles peuvent prendre deux à quatre fois plus de temps une fois que vous commencez à inclure la vérification, les tentatives, les vérifications du navigateur, la revue humaine, tous ces délais supplémentaires.
Je pense que cela peut contribuer à une meilleure qualité et à une meilleure confiance dans le système. D'un point de vue mesure, vous pouvez examiner des métriques comme le coût par PR fusionnée et la durée de vie du code en tant que métriques de dette de compréhension.
Vous devez également réfléchir à ce qui est un délai utile par rapport aux frais généraux de l'usine. Les vérificateurs, dans mon cas, ont détecté de vrais problèmes. Un peu de temps a peut-être été consacré à produire les preuves que je voulais. Une partie était des frais généraux dans le fonctionnement de l'usine. Je n'ai pas vraiment passé de temps à l'optimiser, mais une usine qui exécute simplement beaucoup de vérifications que vous ne trouvez pas utiles ne signifie pas qu'elle est de haute qualité.
Vous voulez étudier comment, pour toutes les vérifications répétées, sont-elles non pertinentes ? Sont-elles bruyantes ? Rendent-elles réellement le système plus sûr ?
La vérification a besoin d'un budget
La façon dont je pense au budget pour la vérification, c'est essentiellement de quoi nous parlons. Nous parlons d'un budget de vérification. J'y pense de la même manière que j'ai historiquement pensé aux budgets de performance.
Il y aura certains types de vérifications que vous pouvez exécuter tôt dans votre cycle de développement logiciel, et il y aura certaines choses qui sont si lourdes, mais qui offrent tellement de valeur que vous voudrez les exécuter plus tard. Il y a certains types de vérifications rapides, le linting par exemple, la vérification de type. Ce sont des vérifications relativement rapides que vous pouvez exécuter tôt.
Notre suite complète de tests peut être exécutée plus près du moment où une pull request en brouillon est en cours d'élaboration ou après. Cela peut inclure les tests de mutation, les tests de navigateur, les vérifications de sécurité, tout ce genre de choses.
Je pense que vous ne voulez pas nécessairement remplacer cela par de simples résumés. Vous voulez de vrais tests, mais vous devez simplement vous assurer que vous budgétisez pour eux aux bons endroits parce que vous ne voulez pas ralentir votre boucle de développement. Je ne veux certainement jamais ralentir ma boucle de développement. Avoir une boucle d'itération rapide est important pour moi, mais je veux aussi avoir ces contrepoids.
Quand un cycle n'est pas livré
Une grande partie de ce que j'ai écrit ci-dessus concerne les vérifications.
Dans leur usine logicielle, Vercel marque chaque cycle d'agent comme « succès », « imparfait », « bloqué » ou « manuel » et seul le « succès » est livré en production. Le reste rentre dans le système. J'ai pensé aux cycles en termes similaires.
« Imparfait » signifie ici que la mauvaise chose a été implémentée ou peut-être qu'elle n'avait pas tout le contexte, donc cela doit être corrigé. « Bloqué » signifie que l'environnement manquait peut-être d'un identifiant, donc vous devez le fournir. « Manuel » est une limite que l'usine n'est peut-être pas encore autorisée à franchir.
Deux des trois choses ici peuvent avoir des correctifs mécaniques et la dernière concerne la confiance.
Bien que ce soit excellent, ce que le tri ne vous montre pas, c'est le coût. Revenons à mon implémentation d'usine avec l'application TMDB, le chercheur rapide sans rejet a pris 7 minutes. Les favoris, avec deux rejets et une décision humaine au milieu, ont pris 56 minutes. Même usine. Donc, je jumellerais la taxonomie avec un timing par étape, sinon vous savez qu'un cycle est revenu imparfait sans savoir combien cela vous a coûté de le découvrir. L'autre chose que je corrigerais est le transfert à la limite : mon usine exemple a arrêté le premier ticket et l'a déplacé vers factory:needs-info, ce qui était correct, mais je ne savais pas où mettre ma réponse. Un cycle manuel n'est pas terminé lorsque l'usine s'arrête, mais lorsque l'humain sait quoi faire ensuite.
L'autonomie n'est pas un réglage unique
J'ai écrit il y a quelques semaines un article sur l'autonomie agentique et comment penser à l'autonomie car l'autonomie ne sera pas un réglage unique pour chaque projet.
La vérification vous achète la confiance, et elle achète la capacité d'accorder plus d'autonomie à vos agents. Donc, si, par exemple, je travaille sur un changement non trivial, mais que j'ai un certain nombre de vérifications en place, que tout est vérifié correctement, et que peut-être je l'ai moi-même vérifié manuellement. La prochaine fois que je ferai une tâche comme celle-ci dans le même projet, je me sentirai peut-être à l'aise de donner un peu plus d'autonomie à l'agent.
C'est ce à quoi vous pensez lorsque vous construisez ces usines logicielles. Votre vérification va changer avec le risque. Votre objectif est le meilleur rapport signal/bruit. Vous ne voulez pas simplement avoir une grande liste de contrôle que vous exécutez.
La fonctionnalité que j'ai dû réapprendre
Il y avait une fonctionnalité que je reportais un jour où j'utilisais plusieurs sessions avec Claude, et je travaillais sur quelques projets différents à la fois, quelques fonctionnalités différentes à la fois par projet. Et donc Claude avait implémenté la fonctionnalité sur laquelle je travaillais. Il semblait que les tests réussissaient. Je n'avais pas beaucoup réfléchi à la vérification, mais les tests ont réussi, et j'ai donc pensé que cela fonctionnait. Je l'ai fusionnée.
Et c'était donc une fonctionnalité de favoris. J'ai pensé que c'était plutôt bien. J'ai essayé de la vérifier dans le navigateur. Cela semblait correct, mais quelques jours plus tard, je suis en fait revenu au code parce qu'il y avait quelques ajustements que je pensais pouvoir y apporter.
Je ne voulais pas simplement demander à mon agent de faire les modifications, car c'était une subtilité dans son fonctionnement. On tapait sur l'icône, et l'effet visuel au toucher ne s'affichait pas correctement. Je voulais donc juste peaufiner ça. Je voulais comprendre comment ça marchait pour pouvoir guider correctement mon agent.
Je suis retourné dans le code, et je n'aurais pas pu vous expliquer comment fonctionnait cette fonctionnalité. Ce dépôt était le mien, n'est-ce pas ? J'avais approuvé la modification. Je comprenais une grande partie de son fonctionnement, une grande partie du dépôt, mais ma compréhension n'avait pas suivi le rythme de tout le code qui s'était accumulé.
Ce que je n'avais pas réussi à assimiler, c'était comment cette fonctionnalité ajoutée fonctionnait réellement, comment l'interface utilisateur marchait, comment l'effet visuel fonctionnait. J'ai dû refaire cette fonctionnalité et réellement procéder étape par étape : « Comment ça marche ? Comment puis-je le comprendre ? »
Ce que le travail parallèle fait à la compréhension
Lorsque vous effectuez un travail parallèle, cela amplifie ce problème global, et cela devient encore plus amplifié lorsque vous le faites dans une usine logicielle. Lorsque vous menez cinq ou dix sessions, cela crée bien plus qu'un simple problème de volume de relecture. Cela crée plusieurs modèles mentaux qui peuvent finir par refroidir considérablement pendant que vous travaillez ailleurs.
Nous avons historiquement parlé des défis liés au changement de contexte, et dès que le chat se compacte, que vous rejetez certaines approches, que vous essayez différentes choses, que vous travaillez en binôme avec l'agent, vous aurez du mal à vous souvenir de tout ce qui s'est passé dans votre session.
Vous pouvez faire défiler vers le haut, mais comme la compaction a eu lieu, vous n'aurez pas tout à disposition, et vous ne pourrez pas tout stocker dans votre tête. Le code préserve souvent une décision qui a été prise, mais pas la raison pour laquelle elle a été prise.
C'est quelque chose qui, je pense, peut être un apprentissage utile pour vous, où il est important d'envisager de demander à votre agent de stocker des informations sur sa trajectoire, ou des leçons intéressantes sur la façon dont il a abordé un problème, afin que vous puissiez y revenir plus tard.
Cela peut, ou non, être quelque chose que vous décidez de valider dans un dépôt. Vous pouvez le garder en local si vous le souhaitez, vous pouvez le partager avec une équipe si vous le souhaitez, mais cela peut être quelque chose qui pourra être consulté ultérieurement. Plutôt que de compter sur le fait que ce soit peut-être dans une session, ou que vous vous en souveniez peut-être plus tard.
Qu'est-ce que ça produit réellement ?
@threepointone et @bentlegen ont publié des réflexions sur les usines logicielles avec lesquelles j'étais tout à fait d'accord :
Il est facile de se laisser fasciner par la machinerie de l'action, d'optimiser la machinerie et d'oublier ce qu'elle était censée produire. Si votre usine produit principalement une meilleure usine, vous avez construit un logiciel dont le produit est lui-même.
Je pense qu'investir dans la boucle est bien et que cela porte ses fruits. L'échec survient lorsque la boucle se referme, lorsque tout ce que l'usine produit est consommé par l'usine et que personne à l'extérieur ne remarquerait si vous l'éteigniez. Le test que j'appliquerais est celui de la traction. Quelque chose à l'extérieur doit demander l'amélioration. Si vous ne pouvez pas nommer qui tire, vous polissez.
La propriété ne disparaît pas
Il y a un principe plus large derrière tout cela.
Le pourcentage de code physiquement tapé par les humains peut chuter considérablement. Je ne pense pas que la propriété humaine doive chuter avec lui.
- Quelqu'un choisit toujours le problème.
- Quelqu'un choisit toujours l'architecture.
- Quelqu'un fixe toujours le niveau de qualité.
- Quelqu'un décide quels signaux de vérification méritent d'être fiables.
- Quelqu'un décide quand les preuves sont suffisantes pour livrer.
Et lorsque le système résultant échoue, « c'est l'agent qui l'a écrit » ne suffit pas. C'est pourquoi je ne pense pas que l'avenir du génie logiciel soit mieux décrit comme des humains quittant la boucle. Au lieu de cela, le jugement humain est relocalisé.
Nous devrions retirer les personnes des parties de la boucle où les machines peuvent produire des signaux plus forts, plus rapides et plus déterministes. En même temps, nous devrions concentrer les personnes autour des endroits où le contexte, le goût, le risque et la propriété à long terme comptent le plus.
Les meilleures usines logicielles ne seront pas définies par la manière dont elles éliminent complètement l'implication humaine.
Elles seront définies par la manière dont elles placent intelligemment cette implication.
Maintenez le jugement humain en amont sur l'intention, la forme du système et le niveau de qualité. Relisez le code là où la contre-pression automatisée devient faible ou où les conséquences deviennent subjectives. Poussez chaque signal déterministe le plus tôt et le plus continuellement possible dans la boucle. Resserrez et relâchez les contraintes délibérément à mesure que le système gagne ou perd la confiance.
Un humain doit toujours posséder ce que le code livre finalement. Un code assez bon pour être livré commence toujours par quelqu'un qui se soucie de savoir s'il devrait exister.
