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

In der Welt der Softwareerstellung gab es lange Zeit eine grundlegende Spannung zwischen der Idee eines Programms und dem Programm selbst. Traditionell hielt ein Entwickler eine Vision in seinem Kopf oder skizzierte Notizen auf einer Serviette und verbrachte dann Monate damit, diese Vision in Zeilen von Code zu übersetzen. Der Code war das primäre Artefakt, das Ding, das geschrieben, überprüft und gepflegt wurde. Es hat sich jedoch vor kur�re Zeit eine neue Praxis herausgebildet, bei der die Reihenfolge umgekehrt wird. Bevor auch nur eine einzige Zeile Code geschrieben wird, entwirft ein Entwickler, oft mit Hilfe eines Werkzeugs der künstlichen Intelligenz, eine detaillierte, strukturierte Beschreibung dessen, was gebaut werden soll. Diese Beschreibung, die in natürlicher Sprache verfasst ist, fungiert als Blaupause. Ein KI-Agent liest dann diese Blaupause und generiert die eigentliche Software. Dieser Wandel bedeutet, dass das wichtigste Dokument im Projekt nicht länger der Code ist, sondern die Spezifikation selbst. Zu verstehen, wie diese Spezifikationen geschrieben werden, wie sie sich ändern und wie sie schließlich zu funktionierender Software werden, ist nun eine entscheidende Frage für jeden, der untersucht, wie Technologie gemacht wird.

Bis jetzt hatte niemand eine klare Karte dieser neuen Landschaft. Während Dutzende von Werkzeugen erschienen sind, um Entwicklern beim Schreiben dieser Blaupausen zu helfen, wurden die tatsächlich produzierten Dokumente noch nie in großem Maßstab untersucht. Die Forscher Shyam Agarwal und Bogdan Vasilescu von der Carnegie Mellon University haben dies geändert, indem sie SPECMINE erstellt haben, eine massive Sammlung dieser Spezifikationsdokumente und des von ihnen erzeugten Codes. Sie sammelten fast eine halbe Million Spezifikationsdateien aus öffentlichen Projekten auf GitHub und hielten damit eine Momentaufnahme dieser Praxis fest, wie sie in den Jahren 2025 und 2026 entstand. Diese Sammlung umfasst nicht nur den Text der Spezifikationen, sondern auch die vollständige Historie der Projekte, zu denen sie gehören, die Personen, die sie geschrieben haben, und die spezifischen Änderungen am Code, die vorgenommen wurden, als die Spezifikationen aktualisiert wurden. Es ist das erste Mal, dass die Software-Community im Detail sehen kann, wie sich eine schriftliche Beschreibung in ein funktionierendes Programm im Zeitalter der KI verwandelt.

Die Forscher bauten diese Sammlung auf zwei Hauptwegen auf, um sicherzustellen, dass sie das gesamte Bild erfassten. Erstens suchten sie nach Dateien mit den Namen „spec.md“ oder „specs.md“, was der Standardname ist, den die meisten der neuen Werkzeuge verwenden. Allein diese Suche brachte über 470.000 Dateien aus mehr als 73.000 verschiedenen Repositories hervor. Dann fügten sie eine zweite, separate Suche für ein spezielles Werkzeug namens AWS Kiro hinzu, das eine andere Namenskonvention mit separaten Dateien für Anforderungen, Design und Aufgaben verwendet. Dies steuerte weitere 98.000 Dateien bei. Durch die Kombination dieser Suchen erstellten sie eine breite Volkszählung, die die überwiegende Mehrheit der derzeit verwendeten Werkzeuge abdeckt. Jede Datei in dieser Sammlung ist mit Informationen über das Projekt versehen, aus dem sie stammt, wie etwa die Anzahl der Beobachter des Projekts, die verwendete Programmiersprache und das spezifische Werkzeug, das die Spezifikation generiert hat.

Um zu verstehen, wie diese schriftlichen Pläne tatsächlich zu Code führen, gingen die Forscher einen Schritt weiter. Sie konzentrierten sich auf eine kleinere, sorgfältig ausgewählte Gruppe populärer Projekte und verfolgten jede Anfrage zur Änderung des Codes, die eine Spezifikationsdatei betraf. Sie fanden fast 6.000 solcher Anfragen, sogenannte Pull Requests, bei denen ein Entwickler oder ein KI-Agent die Blaupause und den Code gleichzeitig aktualisierte. Dies ermöglichte es ihnen, die direkte Verbindung zwischen der Idee und der Implementierung zu sehen. In vielen Fällen änderten sich die Spezifikation und der Code in einem einzigen Update gemeinsam, was bestätigte, dass die Blaupause dazu genutzt wurde, die Arbeit in Echtzeit voranzutreiben. Die Forscher stellten jedoch auch fest, dass dies nicht die einzige Art und Weise ist, wie es geschieht; manchmal wird zuerst ein Plan geschrieben und der Code folgt später, oder der Code wird zuerst geschrieben und die Planung wird nachträglich hinzugefügt. Die Daten zeigen, dass, obwohl die gleichzeitige Änderung häufig vorkommt, die Beziehung komplex ist und von Projekt zu Projekt variiert.

Über das bloße Zählen von Dateien hinaus analysierte das Team die Struktur dieser Dokumente, um zu sehen, wie sie tatsächlich aussehen. Sie fanden heraus, dass die Spezifikationen nicht einfach nur willkürliche Notizen sind; sie folgen oft spezifischen Mustern, wie etwa der Verwendung klarer Überschriften, Listen oder strukturierter Formate, die sie sowohl für Menschen als auch für Maschinen leicht lesbar machen. Die Forscher entwickelten auch ein System, um Referenzen innerhalb dieser Dokumente zurückzuverfolgen. Wenn eine Spezifikation eine bestimmte Datei oder eine Aufgabe erwähnt, die erledigt werden muss, prüft das System, ob diese Datei tatsächlich im Projekt existiert oder ob die Aufgabe jemals abgeschlossen wurde. Dies offenbarte eine signifikante Lücke in einigen Projekten: Es gibt tausende Spezifikationen, die Dateien oder Aufgaben erwähnen, die niemals im Code erschienen sind. Dies deutet darauf hin, dass, während die Praxis des Schreibens von Spezifikationen wächst, die Disziplin, sicherzustellen, dass diese Spezifikationen vollständig realisiert werden, noch in der Entwicklung begriffen ist.

Die Sammlung bietet auch ein Fenster zu der Frage, wer die Texte schreibt. Da die Daten die Historie jeder Änderung enthalten, können Forscher sehen, ob eine Spezifikation von einem Menschen, einer KI oder einer Mischung aus beidem geschrieben wurde. Sie können verfolgen, wie oft diese Dokumente aktualisiert werden und wie lange sie aktiv bleiben, bevor sie aufgegeben werden. Diese Detailtiefe ermöglicht Fragen, die zuvor unmöglich zu beantworten waren, wie etwa, ob eine gut geschriebene Spezifikation zu weniger Fehlern im fertigen Code führt oder ob bestimmte Arten von Projekten eher dazu neigen, diese neue Arbeitsweise zu übernehmen. Die Daten zeigen, dass sich die Praxis schnell verbreitet, wobei die überwiegende Mehrheit dieser Dateien erst in den letzten zwei Jahren auftauchte, was eine deutlich neue Ära in der Softwareentwicklung markiert.

Die Forscher machten diesen gesamten Datensatz der Öffentlichkeit zugänglich, organisiert in einer Weise, die es jedem ermöglicht, die Verbindungen zwischen Ideen und Code zu erforschen. Sie stellten den Rohtext der Spezifikationen, die Historie der Projekte und die Verknüpfungen zwischen beiden zur Verfügung, ohne die Identitäten der Mitwirkenden oder der Projekte zu verbergen, da alles aus öffentlichen Quellen stammt. Diese Transparenz bedeutet, dass andere Wissenschaftler die Ergebnisse verifizieren, neue Fragen stellen und untersuchen können, wie sich diese Praxis im Laufe der Zeit verändert. Die Arbeit behauptet nicht, dass diese neue Methode perfekt ist oder dass sie alle Probleme der Softwareentwicklung gelöst hat. Stattdessen liefert sie das erste solide Fundament aus Evidenz, eine groß angelegte Karte eines Gebiets, das zuvor unkartiert war. Sie zeigt, dass zwar die Werkzeuge zum Schreiben von Spezifikationen vorhanden sind und das Volumen der Arbeit wächst, die Art und Weise, wie Menschen und Maschinen zusammenarbeiten, um diese Worte in Software zu verwandeln, noch immer Stück für Stück – Projekt für Projekt – erarbeitet wird.