Construire l’usine logicielle : Règles et harnais pour les agents de codage

Le codage a cessé d’être l’étape lente. La prochaine étape utile est d’arrêter de traiter les agents comme des codeurs bavards en one-shot et de commencer à construire une usine logicielle : des boucles d’agents coordonnées et répétables avec des déclencheurs clairs, des échafaudages, des contrôles déterministes, et une propriété humaine de l’architecture et du jugement.

C’est le pattern pratique qui émerge des derniers talks sur Beyond Coding et de David Ondrej. C’est une emphase différente de l’analyse pure des goulots d’étranglement. Le goulot s’est déjà déplacé vers la revue, la confiance et la vérification ; la question maintenant est comment structurer l’usine pour que les agents restent utiles sur les systèmes de production sans dégrader le codebase.

Ce qu’est réellement une usine logicielle

David Ondrej la présente comme une collection de boucles d’agents plutôt que de plus de prompting manuel. Chaque boucle a :

• un déclencheur (planification, webhook, événement produit, erreur, feedback client),
• une tâche bornée avec le bon modèle, compétences, contexte et outils,
• une forme de vérification ou de suivi.

Une usine, c’est beaucoup de ces boucles à travers le travail produit, la sécurité, la santé de la base de données, la facturation ou le support. Les humains restent responsables de la priorisation, du goût, de la stratégie et des approbations à haut risque. L’opérateur n’est plus le goulot qui démarre chaque session à la main.

Voir : Stop coding, build Software Factories instead (et discussions liées sur le passage des prompts manuels aux boucles).

Règles concrètes des praticiens seniors

Échafauder d’abord ; garder l’agent principal loin des fichiers

Carlos Kelkboom (architecte lead, Beyond Coding) est explicite : les agents sont mauvais aux changements itératifs et bons à l’exécution one-shot. Sa pratique est de créer manuellement les dossiers, fichiers clés, signatures de fonctions ou types, commentaires et frontières de dossiers avant qu’un agent d’implémentation ne tourne. Son agent conversationnel principal reste en mode « ouvert » — il discute, enseigne et construit une compréhension mutuelle — mais ne touche jamais aux fichiers. Seulement quand la confiance est élevée, il lance un worker fermé pour une tâche étroite ou large one-shot.

Il utilise un harnais de style graphe (nœuds Markdown, divulgation progressive via liens, hashes de commit, résumés courts) pour que le contexte soit récupéré à la demande au lieu d’être déversé dans chaque prompt. Les expériences parallèles tournent dans des git worktrees ; les meilleures implémentations sont mergées et le reste jeté.

Règle la plus importante : jette le code si tu ne le comprends pas, même s’il passe les tests. La compréhension est ce qui te permet de le maintenir, déboguer et étendre plus tard.

Épisode complet : Lead Architect Reveals His Rules for Coding Agents.

Transformer les agents en CI/CD sophistiqué et déterministe

Kerim Satirli (HashiCorp / IBM) fait le même changement sur l’infrastructure de production. « Ne fais pas d’erreurs » n’est qu’une demande polie ; ce n’est pas une ligne dure. Il s’éloigne du pur non-déterminisme et traite les agents plus comme un pipeline CI/CD amélioré : lancer des outils de qualité, évaluer les plans, faire surface les diffs inattendus (par exemple un provider Terraform qui montre toujours des changements), croiser avec des problèmes connus via recherche, et recommander des holds.

La plupart des Terraform applies peuvent tourner automatiquement pour que l’humain ne soit pas le bloqueur perpétuel ; les changements risqués gardent des échappatoires. Les specs (style GitHub Spec Kit), résumés BLUF (bottom-line-up-front) qui coupent le bruit de documentation, et contraintes d’usine personnalisées remplacent l’espoir. Presque chaque ingénieur qu’il connaît construit ou personnalise déjà lourdement sa propre usine.

Épisode complet : How Senior Engineers Use Coding Agents On Prod Infrastructure.

Que faire lundi

1. Choisis une boucle répétitive et clairement bornée (mises à jour de providers, scan de sécurité de tes propres repos, triage de feedback) et donne-lui un vrai déclencheur plus un contrôle indépendant.
2. Échafaude la structure et la définition de done toi-même. Garde l’agent coordinateur en lecture seule jusqu’à ce que la tâche soit claire.
3. Préfère les tâches one-shot ou larges bornées plutôt que le patching itératif sans fin. Isole le travail dans des worktrees.
4. Encode la sécurité et l’anti-slop comme des portes dures (hooks qui refusent les édits, outils de qualité, credentials de courte durée, évaluateurs de plans) plutôt que des souhaits de prompt.
5. Partage l’interface de l’usine — specs, skills, evals, le graphe de contexte — pour que toute l’équipe puisse utiliser les mêmes boucles.

Les équipes qui restent rapides ne sont pas celles qui font tourner le plus d’agents non supervisés la nuit. Ce sont celles qui ont remarqué que le goulot avait bougé et qui ont ensuite construit les harnais, échafaudages et boucles de vérification qui permettent aux agents de continuer à produire sans empirer le codebase.

Sources : les deux épisodes récents de Beyond Coding liés ci-dessus, plus le cadrage software-factory de David Ondrej. La discussion liée sur Hacker News continue de souligner la charge de revue et la pression CI sous un volume d’agents plus élevé, renforçant pourquoi l’usine a besoin de contrôles déterministes plutôt que de plus de génération.