SPECMINE: A Large-Scale Corpus of Spec-Driven Development Artifacts

Dans le monde de la création de logiciels, il existe depuis longtemps une tension fondamentale entre l'idée d'un programme et le programme lui-même. Traditionnellement, un développeur conservait une vision dans son esprit ou griffonnait des notes sur une serviette en papier, puis passait des mois à traduire cette vision en lignes de code. Le code était l'artefact primaire, la chose qui était écrite, revue et maintenue. Cependant, une nouvelle pratique a récemment émergé où l'ordre est inversé. Avant qu'une seule ligne de code ne soit écrite, un développeur, s'aidant souvent d'un outil d'intelligence artificielle, rédige une description détaillée et structurée de ce qui doit être construit. Cette description, écrite en langage clair, fait office de blueprint (plan directeur). Un agent d'IA lit ensuite ce blueprint et génère le logiciel proprement dit. Ce changement signifie que le document le plus important du projet n'est plus le code, mais la spécification elle-même. Comprendre comment ces spécifications sont écrites, comment elles évoluent et comment elles deviennent finalement des logiciels fonctionnels est désormais une question critique pour quiconque étudie la manière dont la technologie est fabriquée.

Jusqu'à présent, personne n'avait de carte claire de ce nouveau paysage. Bien que des dizaines d'outils soient apparus pour aider les développeurs à rédiger ces blueprints, les documents réels qu'ils produisent n'ont jamais été étudiés à grande échelle. Les chercheurs Shyam Agarwal et Bogdan Vasilescu, de l'Université Carnegie Mellon, ont changé cela en créant SPECMINE, une collection massive de ces documents de spécification et du code qu'ils produisent. Ils ont rassemblé près d'un demi-million de fichiers de spécification provenant de projets publics sur GitHub, capturant un instantané de cette pratique telle qu'elle est née en 2025 et 2026. Cette collection comprend non seulement le texte des spécifications, mais aussi l'historique complet des projets auxquels elles appartiennent, les personnes qui les ont écrites, et les changements spécifiques apportés au code lorsque les spécifications ont été mises à jour. C'est la première fois que la communauté logicielle peut voir, en détail, comment une description écrite se transforme en un programme fonctionnel à l'ère de l'IA.

Les chercheurs ont construit cette collection de deux manières principales pour s'assurer de capturer l'image complète. Premièrement, ils ont recherché des fichiers nommés « spec.md » ou « specs.md », qui est le nom standard utilisé par la plupart des nouveaux outils. Cette recherche seule a permis de récupérer plus de 470 000 fichiers provenant de plus de 73 000 dépôts différents. Ils ont ensuite ajouté une seconde recherche distincte pour un outil spécifique appelé AWS Kiro, qui utilise une convention de nommage différente avec des fichiers séparés pour les exigences, la conception et les tâches. Cela a ajouté 98 000 fichiers supplémentaires. En combinant ces recherches, ils ont créé un recensement large qui couvre la vaste majorité des outils actuellement utilisés. Chaque fichier de cette collection est étiqueté avec des informations sur le projet dont il provient, comme le nombre de personnes ayant suivi le projet, le langage de programmation utilisé et l'outil spécifique ayant généré la spécification.

Pour comprendre comment ces plans écrits mènent réellement au code, les chercheurs sont allés plus loin. Ils se sont concentrés sur un groupe plus restreint et soigneusement sélectionné de projets populaires et ont suivi chaque demande de modification du code impliquant un fichier de spécification. Ils ont trouvé près de 6 000 de ces demandes, appelées pull requests, où un développeur ou un agent d'IA mettait à jour le blueprint et le code simultanément. Cela leur a permis de voir le lien direct entre l'idée et l'implémentation. Dans de nombreux cas, la spécification et le code changeaient ensemble lors d'une seule mise à jour, confirmant que le blueprint était utilisé pour piloter le travail en temps réel. Cependant, les chercheurs ont également noté que ce n'est pas la seule façon dont cela se produit ; parfois, un plan est écrit d'abord et le code vient plus tard, ou le code est écrit d'abord et le plan est ajouté après coup. Les données montrent que si le changement simultané est courant, la relation est complexe et varie d'un projet à l'autre.

Au-delà du simple comptage de fichiers, l'équipe a analysé la structure de ces documents pour voir à quoi ils ressemblent réellement. Ils ont découvert que les spécifications ne sont pas de simples notes aléatoires ; elles suivent souvent des modèles spécifiques, comme l'utilisation de titres clairs, de listes ou de formats structurés qui les rendent faciles à lire tant pour les humains que pour les machines. Les chercheurs ont également construit un système pour tracer les références au sein de ces documents. Si une spécification mentionne un fichier spécifique ou une tâche à accomplir, le système vérifie si ce fichier existe réellement dans le projet ou si la tâche a été réalisée. Cela a révélé une lacune significative dans certains projets : il existe des milliers de spécifications qui mentionnent des fichiers ou des tâches qui n'ont jamais réellement apparu dans le code. Cela suggère que bien que la pratique de la rédaction de spécifications soit en pleine croissance, la discipline consistant à s'assurer que ces spécifications sont pleinement réalisées est encore en pleine évolution.

La collection offre également une fenêtre sur ceux qui écrivent. Comme les données incluent l'historique de chaque modification, les chercheurs peuvent voir si une spécification a été écrite par un humain, générée par une IA, ou si elle est un mélange des deux. Ils peuvent suivre la fréquence à laquelle ces documents sont mis à jour et combien de temps ils restent actifs avant d'être abandonnés. Ce niveau de détail permet de répondre à des questions auparavant impossibles, telles que : est-ce qu'une spécification bien écrite conduit à moins d'erreurs dans le code final, ou est-ce que certains types de projets sont plus susceptibles d'adopter cette nouvelle façon de travailler. Les données montrent que la pratique se répand rapidement, la vaste majorité de ces fichiers étant apparue au cours des deux dernières années, marquant une ère distincte et nouvelle dans le développement de logiciels.

Les chercheurs ont rendu l'ensemble de ce jeu de données public, organisé de manière à ce que quiconque puisse explorer les connexions entre les idées et le code. Ils ont fourni le texte brut des spécifications, l'historique des projets et les liens entre les deux, sans masquer l'identité des contributeurs ou des projets, puisque tout provient de sources publiques. Cette transparence signifie que d'autres scientifiques peuvent vérifier les conclusions, poser de nouvelles questions et étudier comment cette pratique évolue au fil du temps. Ce travail ne prétend pas que cette nouvelle méthode est parfaite ou qu'elle a résolu tous les problèmes du développement logiciel. Au lieu de cela, il fournit le premier fondement solide de preuves, une carte à grande échelle d'un territoire qui était auparavant inexploré. Il montre que bien que les outils pour écrire des spécifications soient là et que le volume de travail augmente, la manière dont les humains et les machines collaborent pour transformer ces mots en logiciels est encore en cours de définition, un projet à la fois.