Coder sur la durée : modifier sans casser, avec Git
Le coding long-horizon exige des modifications non-destructives et une intégration Git disciplinée, surtout quand un essaim travaille sur plusieurs fournisseurs.
Lynn Cole / Sujet
Un fil à suivre à travers mon travail.
Le coding long-horizon exige des modifications non-destructives et une intégration Git disciplinée, surtout quand un essaim travaille sur plusieurs fournisseurs.
Une nouvelle boucle de planification a aidé l’essaim de codage, puis des tickets contradictoires ont fait fondre le benchmark. Prochaine étape : validation du backlog avant l’implémentation.
Pizza Empire teste un essaim de codage long-horizon face à un produit complet : commandes, flux de cuisine, livraison et les contraintes qui rendent le tout cohérent.
Un graphique de contributions GitHub masque la planification, la recherche et l’évaluation sur des branches. Un faible volume de commits ne signifie pas un faible effort.
Une évaluation s’est arrêtée pour annoncer qu’elle avait commencé. La relancer a mis à nu un problème de concurrence dans l’architecture de la base de données du projet.
Les dépôts shadow protégeaient l’état du projet, jusqu’à ce que les outils du projet tentent de s’en servir. Sortir cet état du projet a déplacé la limite de rupture.
La QA a refusé d’arrêter d’utiliser des commandes terminal pour lesquelles elle n’avait plus les permissions. Le planner a tenté de négocier ; l’agent a ouvert un autre bug.
Éplucher la gestion de projet pour les agents soulève une question intéressante : quelle est la structure minimale irréductible nécessaire au travail coordonné ?
Une évaluation de code bornée oppose BitNet à un modèle Qwen plus petit. Les résultats révèlent la différence entre un langage coopératif et du code qui fonctionne.
Un prompt de rôle peut changer bien plus que le ton narratif. Des expériences avec Claude suggèrent un lien reproductible entre l’incarnation et le comportement de codage.