Contexte et objectifs

Ensemble est un agent de codage issu du projet The Art of Building AI Coding Agents de Bill Cox. La version actuelle, dite Edition 3, repose sur le langage C# 14 et le runtime .NET 10. L’objectif déclaré n’est pas de fournir une description fonctionnelle exhaustive à l’avance, mais de faire émerger la spécification pendant le développement, en associant chaque décision à une justification exploitable par un autre agent.

Architecture et workflow

Le code source et la spécification sont construits simultanément. Le processus s’articule en quatre étapes : discussion du design, rédaction d’un TL;DR et d’exercices pour le chapitre suivant, programmation en binôme avec l’IA, puis rédaction du chapitre à partir des notes de correction. Chaque chapitre inclut des « graders » automatisés qui valident l’implémentation avant que le texte ne soit finalisé. L’ensemble du projet est orchestré par make, qui compile le GUI C# et le client terminal, exécute les tests C# et Go, et génère les artefacts de publication (EPUB, PDF).

dotnet --list-sdks           # doit afficher une version 10.x
make                         # compile le GUI et crée ./ensemble
make cli                     # compile le client terminal
make test                    # lance les tests C# et Go

Le système nécessite explicitement le SDK .NET 10 ; le runtime seul ne suffit pas. Si le SDK n’est pas présent dans le PATH, l’utilisateur doit soit l’ajouter, soit fournir le chemin complet via la variable DOTNET aux invocations make.

Analyse des spécifications guidées par le développement

Cette méthode inverse la logique traditionnelle « spécifications‑first ». Au lieu d’une description statique, chaque décision de conception est capturée dans le texte du chapitre, accompagnée d’une justification et d’un exercice de validation. Le texte devient ainsi une spécification exécutable : un autre agent peut suivre le chapitre, exécuter les graders, et reconstruire le même code. Cette boucle de rétroaction garantit que la connaissance tacite du développeur humain est externalisée sous forme de données structurées, plutôt que d’être perdue dans un code final non commenté.

Les chapitres conservent leurs limites de vérification, ce qui rend explicite le périmètre de chaque fonctionnalité. Par exemple, le chapitre 5 expose une commande grade CH=5 … -executable‑only avec 65 points de portée, reflétant exactement ce qui est testé. Les éditions antérieures (1 et 2) restent archivées avec leurs livres, sources et graders, assurant la traçabilité historique.

Limites et perspectives

Le modèle dépend fortement de la qualité des graders et de la discipline du développeur à consigner chaque incertitude. Aucun mécanisme automatisé n’assure la complétude des justifications ; une omission peut rendre la spécification non reproductible. De plus, la nécessité d’un SDK .NET 10 limite l’adoption à des environnements où cette version est supportée, excluant par exemple les plateformes ne disposant que du runtime.

Malgré ces contraintes, l’approche montre comment un agent IA peut être intégré dans un cycle de développement itératif, tout en produisant un artefact de spécification réutilisable. Future work pourrait automatiser la génération de graders à partir de tests unitaires existants, ou étendre le modèle à d’autres langages et runtimes afin de réduire la dépendance à .NET 10.