LLM-gestütztes Rapid Prototyping: Ergebnisse aus der Entwicklung eines Content-Migrations-Tools#

Einleitung#

Dieser Artikel dokumentiert Beobachtungen und Ergebnisse aus einem experimentellen Projekt zur Entwicklung eines webbasierten Tools für Content-Migration. Das Projekt entstand im Kontext einer anstehenden Migration von Plone zu TYPO3 und diente primär dazu, die Machbarkeit einer Idee zu explorieren: Lässt sich ein funktionsfähiger Demonstrator entwickeln, der JSON-Exporte aus Plone verarbeitet, durch LLM-Analyse verbessert und in verschiedenen Formaten exportiert – und wie lange dauert das?

Das Projekt ist Teil einer Serie von LLM-gestützten Entwicklungsexperimenten, die methodische Erkenntnisse für ähnliche Vorhaben liefern sollen.

Experimenteller Kontext#

Ausgangssituation und Motivation#

Die Entwicklung des Tools ergab sich aus einem Gespräch über eine anstehende Content-Migration im Zuge der Umstellung eines Content-Managament-Systems von Plone auf TYPO3. Dabei stellte sich die Frage, ob und wie dieser Prozess durch Tools unterstützt werden könnte. Anstatt direkt eine Produktivlösung zu entwickeln, wurde bewusst ein explorativer Ansatz gewählt: Ein Rapid Prototype sollte zeigen, ob die grundlegende Idee funktioniert.

Das primäre Lernziel war die Erprobung eines bestimmten Entwicklungsansatzes: Kann mit LLM-Unterstützung schnell ein funktionsfähiges Tool entwickelt werden, das eine klare Aufgabe erfüllt? Wie verhält sich dieser Ansatz in der Praxis? Welche Herausforderungen treten auf?

Erwartungshaltung und Intention#

Von Anfang an war klar, dass es sich um einen Demonstrator handelt. Die Haltung war: “Wir wollten sehen, wie es funktioniert und testen. Dann werden wir weiter sehen.” Diese offene Erwartungshaltung ohne fixe Produktionsabsicht erwies sich als vorteilhaft – sie ermöglichte eine fokussierte Exploration ohne den Druck, sofort alle möglichen Produktivszenarien abdecken zu müssen.

Technische Umsetzung#

Architekturentscheidungen#

Die gewählte technische Architektur basierte bewusst auf bereits bekannten Technologien:

Kernkomponenten:

• Python als Basis-Sprache
• Gradio für die Web-Oberfläche
• OpenAI-kompatible API für LLM-Integration
• Docker für Deployment

Diese Wahl war pragmatisch motiviert: Vorerfahrungen mit diesen Technologien ermöglichten eine schnellere Umsetzung. Eine wichtige frühe Entscheidung betraf das Importformat. Die Überlegung, welches Format sich am besten eignet, führte schnell zur Wahl von JSON. Dies hatte einen direkten Einfluss auf die Tool-Architektur: Statt einzelne Seiten zu verarbeiten, verarbeitet das Tool gleich komplette Sub-Websites als strukturierte JSON-Dateien.

Modulare Struktur#

Die Anwendung wurde von Anfang an in drei Hauptmodule strukturiert:

main.py (~800 Zeilen): Enthält die Gradio-basierte Benutzeroberfläche und orchestriert den Gesamtablauf. Das Modul handhäbt File-Uploads, JSON-Parsing, die Hierarchie-Erkennung der Plone-Inhalte und koordiniert die Export-Funktionen.

llm_analyzer.py (~280 Zeilen): Kapselt die LLM-Integration. Das Modul implementiert die OpenAI-kompatible API-Kommunikation, Retry-Logic mit exponential backoff, Timeout-Management und die zweistufige Prompt-Verarbeitung.

word_exporter.py (~850 Zeilen): Realisiert den Word-Export mit umfangreicher Markdown-zu-Word-Konvertierung. Das Modul wurde als Erweiterung hinzugefügt und implementiert graceful degradation, falls die notwendigen Bibliotheken nicht verfügbar sind.

Diese klare Strukturierung war von Anfang an geplant und erwies sich als praktikabel. Die Trennung ermöglicht unabhängige Weiterentwicklung der einzelnen Komponenten und erleichtert das Verständnis des Gesamtsystems.

JSON-Handling als Lernfeld#

Ein zentrales technisches Lernfeld war das Handling von großen, strukturierten JSON-Importen. Die Sub-Websites variieren erheblich in ihrer Größe: Einige umfassen nur 200 KB, andere erreichen 10 MB oder mehr. Ein konkretes Beispiel ist eine Sub-Website zum Thema WLAN mit folgenden Charakteristiken:

• 85 einzelne Seiten
• 7 verschiedene Content-Typen
• Aufgliederung: 20 Dokumente, 4 FAQ-Seiten, 27 FAQ-Items, 9 Dateien, 18 Ordner, 6 Bilder, 1 Link
• Dateigröße: ca. 12 MB als JSON

Für die Verarbeitung solcher Datenmengen wurde ein LLM mit 256.000 Token Kontextlänge verwendet. Diese große Kontextgröße war notwendig, um vollständige Sub-Websites in einem Durchgang analysieren zu können.

Zweistufige LLM-Verarbeitung#

Die Implementierung nutzt einen zweistufigen Ansatz für die Content-Analyse:

Phase 1 – Strukturanalyse: Das LLM analysiert die gesamte Sub-Website und entwickelt ein Konzept für eine verbesserte Struktur. Diese Analyse berücksichtigt Hierarchien, Content-Typen, Redundanzen und strukturelle Schwächen.

Phase 2 – Content-Transformation: Basierend auf dem entwickelten Konzept aus Phase 1 werden die bestehenden Inhalte neu strukturiert und verbessert ausgegeben.

Diese Trennung erwies sich als sinnvoll: Statt direkt Content zu transformieren, entsteht zunächst ein explizites Konzept, das dann angewendet wird. Alle Verarbeitungen finden ausschließlich im Speicher der Anwendungssession statt.

Entwicklungsprozess mit LLM#

Spezifikationsphase#

Die Entwicklung begann mit einer detaillierten Spezifikation, die etwa 20 Minuten in Anspruch nahm. Diese Spezifikation umfasste sowohl funktionale als auch technische Anforderungen und wurde am Stück formuliert und übergeben – nicht iterativ entwickelt.

Inhaltliche Schwerpunkte der Spezifikation:

• Klare Beschreibung der zu verarbeitenden Datenstrukturen (Plone JSON-Schema)
• Funktionale Anforderungen (JSON-Import, LLM-Analyse, Export in verschiedenen Formaten)
• Technische Rahmenbedingungen (Gradio-basierte UI, API-Integration, Docker-Deployment)
• Nicht-funktionale Anforderungen (Error-Handling, Performance-Überlegungen bei großen Dateien)

Ein wichtiger Aspekt war die explizite Berücksichtigung des KISS-Prinzips bereits in der Spezifikationsphase. Durch klare Fokussierung auf die Kernfunktionalität wurde vermieden, dass das LLM zu komplexe oder überdesignte Lösungen generiert.

Iterative Umsetzung#

Die eigentliche Implementierung dauerte etwa eine Stunde und umfasste drei Iterationen:

Iteration 1 – Erste Code-Umsetzung: Das LLM generierte basierend auf der Spezifikation die Grundstruktur der drei Module. Dies umfasste JSON-Parsing, Gradio-Interface, LLM-Integration und grundlegende Export-Funktionen in Markdown.

Iteration 2 – Export-Erweiterungen: In dieser Phase wurden zusätzliche Export-Formate hinzugefügt (ZIP-Archive mit einzelnen Dateien, Word-Export). Dabei traten einige Herausforderungen auf, insbesondere beim Handling von ZIP-Archiven und bei der Bewältigung der Dateimenge. Eine Sub-Website mit 85 Seiten erzeugt entsprechend viele einzelne Dateien, was sowohl bei der Pfadverwaltung als auch bei Windows-Pfadlängenbeschränkungen berücksichtigt werden musste.

Iteration 3 – UI-Verfeinerungen: Die letzte Iteration fokussierte auf kleinere Anpassungen der Benutzeroberfläche – primär Layout-Optimierungen und die Verbesserung der Fortschrittsanzeigen bei länger laufenden LLM-Operationen.

Eingesetzte LLM#

Content-Analyse: Für die LLM-gestützte Content-Analyse im fertigen Tool wird Qwen/Qwen3-30B-A3B-Instruct verwendet. Dieses Modell wurde gewählt, weil es mit deutschen Texten gut funktioniert und eine ausreichende Kontextlänge bietet.

Dokumentation#

Die README-Dokumentation wurde nicht separat manuell erstellt, sondern automatisch aus der Spezifikation und dem generierten Code erzeugt. Dies geschah innerhalb der angegebenen Implementierungszeit von einer Stunde. Dieser Ansatz sicherte Konsistenz zwischen Code, Spezifikation und Dokumentation.

Methodische Erkenntnisse#

Bestätigung eines etablierten Workflows#

Eine zentrale Beobachtung aus diesem Experiment war die Bestätigung eines bereits in vorherigen Projekten entwickelten Workflows. Die Kombination aus detaillierter, am Stück übergebener Spezifikation und enger Abstimmung der technischen Umsetzung führte zu einem schnellen und zuverlässigen Ergebnis. Dieser Ansatz funktionierte in diesem spezifischen Fall gut – weitere Projekte werden zeigen, ob er sich auf andere Kontexte übertragen lässt.

Bedeutung detaillierter Spezifikation#

Die Spezifikation war bewusst umfassend und detailliert formuliert. Beide Dimensionen wurden explizit ausgearbeitet:

Funktionale Ebene: Was soll das Tool tun? Welche Daten verarbeitet es? Welche Ausgaben erzeugt es?

Technische Ebene: Welche Technologien werden verwendet? Wie ist die Architektur strukturiert? Welche Bibliotheken kommen zum Einsatz?

In einem nachfolgenden Projekt wurde dieser Ansatz weiterentwickelt, indem technische Aspekte noch stärker betont und in eine separate technische Spezifikation ausgelagert wurden.

Wert von Vorerfahrungen#

Die Tatsache, dass auf bereits bekannte Technologien zurückgegriffen wurde, beschleunigte die Entwicklung erheblich. Die Spezifikation konnte präziser formuliert werden, weil konkrete Annahmen über Funktionsweisen und Limitierungen der verwendeten Frameworks getroffen werden konnten. Dies reduzierte die Notwendigkeit für Korrekturen während der Implementierung.

Diese Beobachtung deutet darauf hin, dass LLM-gestütztes Rapid Prototyping womöglich dann besonders effizient ist, wenn es auf einem bestehenden technologischen Fundament aufbaut. Ob der Ansatz auch bei der Exploration völlig neuer Technologie-Stacks ähnlich gut funktioniert, wäre eine interessante Fragestellung für weitere Experimente.

Session-basierte Verarbeitung#

Die Entscheidung, alle Daten nur in der Anwendungssession zu halten ohne persistente Speicherung, erwies sich als vorteilhaft. Aus Datenschutzperspektive vereinfacht dies den Umgang mit sensiblen Inhalten erheblich. Sobald die Session endet, sind alle verarbeiteten Daten automatisch verworfen – es gibt keine Datenbank, keine temporären Files auf dem Server, keine Überbleibsel.

Dieser Aspekt könnte für ähnliche Projekte relevant sein, bei denen sensible Forschungsdaten, Erhebungsergebnisse oder unveröffentlichte Materialien verarbeitet werden. Die technische Umsetzung mit Gradio unterstützt diesen Ansatz gut, da das Framework bereits geeignete Mechanismen für Session-Management und temporäres File-Handling mitbringt.

Umgang mit Herausforderungen#

Nicht alle Aspekte der Implementierung verliefen reibungslos. Insbesondere drei Bereiche erforderten Aufmerksamkeit:

ZIP-Archive: Das Erstellen von ZIP-Archiven mit einer großen Anzahl von Dateien (85 Seiten führen zu mindestens ebenso vielen einzelnen Markdown-Dateien) brachte Herausforderungen mit sich. Insbesondere Windows-Pfadlängenbeschränkungen mussten berücksichtigt werden.

Performance bei großen Dateien: Bei Sub-Websites mit 10+ MB JSON-Daten entstehen längere Verarbeitungszeiten durch das LLM. Dies musste durch geeignete Fortschrittsanzeigen in der UI kommuniziert werden, um Nutzenden Feedback zu geben.

Export-Formate: Die Erweiterung um Word-Export (zusätzlich zu Markdown und ZIP) war eine nachträgliche Ergänzung in Iteration 2. Die Implementierung eines robusten Markdown-zu-Word-Konverters erwies sich als umfangreicher als zunächst angenommen – was sich in der Dateigröße von word_exporter.py mit 850 Zeilen widerspiegelt.

Diese Herausforderungen führten zu den erwähnten zusätzlichen Iterationen, zeigen aber auch, dass das LLM mit konkreten Problemstellungen gut umgehen konnte, sobald diese identifiziert und kommuniziert wurden.

Validierung und Nutzung#

Aktueller Evaluierungsstatus#

Das Tool befindet sich derzeit in einer aktiven Evaluierungsphase. Mehrere Teams testen es mit echten Plone-Exporten aus verschiedenen Bereichen der Universität. Dabei wird bewertet:

• Wie gut funktioniert die LLM-Analyse bei echten, gewachsenen Content-Strukturen?
• Sind die generierten Strukturvorschläge hilfreich für die tatsächliche Migration?
• Welche zusätzlichen Funktionen würden die Nutzbarkeit erhöhen?
• Wo liegen Limitierungen des aktuellen Ansatzes?

Diese Evaluierung dient der Vorbereitung der tatsächlichen Migration und hilft bei der Bearbeitung der Frage, wie diese konkret unterstützt werden kann. Die gesammelten Rückmeldungen fließen in Überlegungen für eine mögliche nächste Entwicklungsstufe ein.

Vom Prototyp zur Evaluation#

Die Tatsache, dass aus einem einstündigen Rapid-Prototyping-Experiment ein Tool entstand, das nun von verschiedenen Gruppen evaluiert wird, illustriert eine mögliche Stärke dieses Entwicklungsansatzes: Ideen lassen sich schnell in funktionsfähige Demonstratoren überführen, die dann als Grundlage für fundierte Entscheidungen dienen können.

Ob das Tool letztlich in irgendeiner Form produktiv eingesetzt wird, ist zum jetzigen Zeitpunkt offen und hängt von den Evaluierungsergebnissen ab. Die explorative Natur des Projekts lässt beide Szenarien zu – produktive Nutzung oder die Erkenntnis, dass ein anderer Ansatz besser geeignet ist.

Übertragbarkeit und Grenzen#

Mögliche übertragbare Prinzipien#

Basierend auf den Beobachtungen aus diesem Projekt scheinen einige Prinzipien womöglich übertragbar:

Detaillierte Spezifikation vor Implementierung: Der Ansatz, erst eine umfassende Spezifikation zu erstellen und diese dann am Stück zu übergeben, hat in diesem Fall gut funktioniert. Dies könnte für ähnlich strukturierte Projekte relevant sein.

Aufbau auf Bekanntem: Die Nutzung bereits vertrauter Technologien ermöglichte präzisere Spezifikationen und schnellere Umsetzung. Bei Projekten mit zeitlichen Constraints könnte dies ein relevanter Faktor sein.

Session-basierte Verarbeitung für sensible Daten: Wo Datenschutz eine Rolle spielt, könnte der Ansatz, Daten nur in der Session zu halten, nützlich sein.

Rapid Prototyping als Entscheidungsgrundlage: Die Entwicklung eines funktionsfähigen Demonstrators als Basis für weitere Entscheidungen erwies sich als praktikabel.

Grenzen und offene Fragen#

Es ist wichtig zu betonen, dass diese Beobachtungen aus einem spezifischen Kontext stammen. Verschiedene Faktoren könnten die Übertragbarkeit einschränken:

Projektgröße: Das Tool umfasst etwa 1900 Zeilen Code. Ob der Ansatz auch für wesentlich größere Projekte funktioniert, ist eine offene Frage.

Vorerfahrungen: Die beteiligten Personen hatten bereits Erfahrung mit den verwendeten Technologien. Ob Personen ohne diese Vorerfahrungen zu ähnlichen Ergebnissen kämen, ist unklar.

Problemkomplexität: Die zu lösende Aufgabe – JSON-Verarbeitung, LLM-Integration, File-Export – ist strukturiert und klar umrissen. Bei weniger strukturierten oder explorativeren Problemstellungen könnte der Ansatz anders funktionieren.

LLM-Fähigkeiten: Die Beobachtungen basieren auf aktuellen LLMs. Zukünftige Entwicklungen könnten sowohl die Möglichkeiten als auch die Limitierungen verändern.

Dieser Artikel ist Teil einer Serie, die methodische Erkenntnisse aus verschiedenen LLM-gestützten Entwicklungsprojekten dokumentiert. Der Fokus liegt auf reproduzierbaren Beobachtungen und übertragbaren Prinzipien für ähnliche Vorhaben.