LLM-Coding-Experiment: Dokumenten-Übersetzungssystem#

Methodische Erkenntnisse zur Rolle der Spezifikationsqualität und den Möglichkeiten LLM-gestützter Entwicklung#

Zusammenfassung#

Dieser Beitrag dokumentiert die Entwicklung eines webbasierten Dokumenten-Übersetzungssystems als Experiment zur Exploration von LLM-gestütztem Coding. Das Projekt untersuchte, wie weit man mit klarer Spezifikation bei komplexeren Anwendungen kommt und wo praktische Herausforderungen der Methodik liegen. Mit einem Gesamtaufwand von 6-7 Stunden entstand eine produktiv genutzte Anwendung mit etwa 12.000 Zeilen Code. Eine zentrale Erkenntnis: Die Qualität der Spezifikation – insbesondere die Explizierung technischer Abhängigkeiten – erwies sich als zentraler Erfolgsfaktor. Gleichzeitig markiert das Projekt Grenzbereiche: Für größere Systeme werden womöglich noch systematischere Spezifikationsprozesse relevant.

1. Experimenteller Kontext#

1.1 Motivation und Lernziele#

Die Idee für das Projekt ergab sich aus einem praktischen Bedarf: Im Alltag fallen regelmäßig Übersetzungsaufgaben für Dokumente verschiedener Formate an. Gleichzeitig sollte exploriert werden, welche Komplexitäten sich bei einem scheinbar einfachen Anwendungsfall wie einem Übersetzungstool ergeben. Übersetzung bietet sich als Anwendung für LLM-Tools an, doch die Anforderung, beliebig große Dokumente verschiedener Formate mit Strukturerhaltung und stilistischer Kontinuität zu übersetzen, bringt weitere technische Herausforderungen mit sich.

Das primäre Lernziel bestand darin zu untersuchen, wie gut LLMs komplexe, mehrstufige Entwicklungsaufgaben bewältigen können, wenn eine klare Spezifikation vorliegt. Das Projekt war von Beginn an sowohl als Lernvehikel als auch als potenziell produktiv nutzbares Tool konzipiert.

1.2 Technische Herausforderungen#

Was zunächst einfach erscheint, entpuppt sich bei näherer Betrachtung als komplexes System mit mehreren nicht-trivialen Teilproblemen:

Verarbeitung verschiedener Dokumentformate mit Strukturerhaltung
Intelligentes Chunking großer Dokumente unter Berücksichtigung von Satz- und Absatzgrenzen
Parallele API-Verarbeitung mit Rate-Limiting und Fehlerbehandlung
Konsistenz der Übersetzung über Chunk-Grenzen hinweg
Spezialbehandlung komplexer Elemente wie Tabellen
Benutzerfreundliche Oberfläche mit Fortschrittsanzeige
Session-Management für parallele Nutzung

Die Wahl fiel auf dieses Projekt, weil es mehrere anspruchsvolle Bereiche kombiniert und damit ein realistisches Abbild komplexerer Entwicklungsaufgaben darstellt.

2. Technische Umsetzung#

2.1 Architektur und Systemdesign#

Das System wurde mit Python und Gradio als Web-Framework entwickelt. Die Architektur folgt einem modularen Aufbau mit klarer Separation of Concerns:

Kernkomponenten:

Dokumentenverarbeitung: Extraktion und Strukturerkennung aus PDF, Word, Text und Markdown
Context-Management-System: Sicherung der stilistischen Kontinuität
Chunking-System: Intelligente Segmentierung unter Berücksichtigung semantischer Grenzen
Translation Engine: Parallele Übersetzung mit Context-Management
Export-System: Ausgabe in verschiedenen Formaten (Markdown, Word, HTML)
UI-Komponenten: Gradio-basiertes Interface mit Side-by-Side-Ansicht

Die Architektur wurde interaktiv mit dem LLM entwickelt. Eine zentrale Designentscheidung war die “Unified Pipeline”: Alle Dokumentformate werden zunächst in ein einheitliches Markdown-Format konvertiert, das dann durch die gleiche Verarbeitungspipeline läuft. Dies reduziert die Komplexität erheblich gegenüber formatspezifischen Verarbeitungsstufen, wie sie von LLMs während der Spezifikation konzipiert wurden.

2.2 Verwendete Bibliotheken#

Die Auswahl der Hauptbibliotheken erfolgte pragmatisch:

Gradio: Bewährt sich in vielen Projekten für schnelle UI-Entwicklung
PyMuPDF/pymupdf4llm: Für PDF-Verarbeitung, basierend auf vorherigen Erfahrungen
python-docx: Standard für Word-Dokumentverarbeitung
aiohttp: Für asynchrone HTTP-Requests an die LLM-API
tenacity: Retry-Logik mit exponentiellem Backoff

Die vollständige Anwendung umfasst etwa 12.000 Zeilen Code (ohne Kommentare) verteilt auf 40 Dateien, organisiert in klar strukturierten Modulen für Dokumentverarbeitung, Chunking, Translation, UI und Session-Management.

2.3 Besondere Implementierungsdetails#

Einheitliche Pipeline: Initial schlug das LLM formatspezifische Verarbeitungsstufen vor – unterschiedliche Pipelines für PDF, Word und andere Formate. Durch LLM-Diskussion über unterschiedliche Verarbeitungsqualität verschiedener Formate im Resultat wurde klar, dass eine einheitliche Markdown-basierte Pipeline deutlich einfacher und wartbarer ist.

Context-Management für Übersetzungskonsistenz: Eine zentrale Herausforderung bestand darin, die stilistische und terminologische Konsistenz über Chunk-Grenzen hinweg zu gewährleisten. Die implementierte Lösung übergibt jedem Übersetzungs-Chunk:

Ein optionales Glossar mit definierten Übersetzungen
Die letzten 50 übersetzten Schlüsselbegriffe (Key Terms)
Zusammenfassungen der vorherigen 3 Chunks (je 200 Zeichen)
Positionsinformationen im Dokument

Dieser Ansatz funktionierte überraschend gut und liefert konsistente Übersetzungen auch bei großen Dokumenten.

Smart Boundary Detection: Das Chunking-System respektiert eine Hierarchie: Überschriften > Absätze > Sätze. Niemals wird mitten im Satz getrennt. Tabellen werden als komplette Einheiten behandelt, bei Überschreitung der Token-Limits werden sie mit wiederholten Headern gesplittet. Diese Logik erwies sich als technisch anspruchsvoll, funktioniert aber zuverlässig.

Parallele Verarbeitung mit Rate-Limiting: Das System verarbeitet standardmäßig 5 Chunks parallel, respektiert dabei API-Limits und implementiert Retry-Logik mit exponentiellem Backoff. Die asynchrone Verarbeitung war ein bewusst gewähltes Lernfeld und funktioniert robust.

3. Entwicklungsprozess mit LLM#

3.1 Workflow und Methodik#

Der Entwicklungsprozess folgte einem klaren Muster:

Spezifikationsentwicklung (30-60 Minuten): Iterative Diskussion mit dem LLM zur Erarbeitung funktionaler und technischer Anforderungen
Code-Generierung in großen Schritten: Implementierung kompletter Module statt inkrementeller Einzelschritte
Iterative Korrekturen: 2-3 Iterationen für komplexe Module wie Chunking und Translation Engine
Dokumentation und Deployment (ca. 60 Minuten)

Der Gesamtaufwand betrug 6-7 Stunden, verteilt auf drei Haupt-Iterationen. Dies steht in erheblichem Kontrast zu den ursprünglich für manuelle Entwicklung geschätzten 4-6 Wochen.

3.2 Eingesetzte LLMs#

Während der Entwicklung kamen verschiedene LLMs zum Einsatz. Im produktiven Betrieb läuft das System mit Mistral Small 2506, was darauf hindeutet, dass auch für komplexere Übersetzungsaufgaben nicht zwingend die größten Modelle erforderlich sind.

3.3 Qualität der Spezifikation#

Die Spezifikation war funktional bereits eindeutig, aber hinsichtlich der technischen Umsetzung und der technischen Abhängigkeiten von funktionalen Entscheidungen noch nicht vollständig durchdacht. Dies führte dazu, dass wichtige technische Aspekte iterativ geklärt werden mussten:

Die Entscheidung für eine Unified Pipeline statt formatspezifischer Verarbeitung
Das konkrete Chunking-Verfahren mit Smart Boundaries
Die Implementierung des Context-Managements
Der Umgang mit Tabellen-Splitting

Dieses Projekt markierte einen Zwischenschritt in der Entwicklung der Spezifikationsmethodik: bessere Spezifikation als in früheren Projekten, aber noch nicht vollständig durchdacht bis ins letzte Detail.

4. Methodische Erkenntnisse#

4.1 Zentrale Erkenntnis: Spezifikationsqualität war zentral#

Die Anforderungen an Spezifikationen für LLM-gestütztes Coding erwiesen sich als hoch. Je detaillierter die funktionalen Anforderungen und technischen Abhängigkeiten vorab herausgearbeitet waren, desto einfacher und fehlerfreier verlief die spätere Umsetzung. Die Interaktion mit LLMs verleitet dazu, Details und Komplikationen auszublenden – genau an diesen Stellen traten jedoch Fehler auf.

Aspekte, die sich in diesem Projekt als wichtig erwiesen:

Funktionale Anforderungen waren so klar formuliert, dass technische Abhängigkeiten nachvollziehbar wurden
Technisch schwierige Aspekte wurden explizit beschrieben und diskutiert
Alternative Lösungsansätze wurden abgewogen und die Entscheidung dokumentiert
Architekturentscheidungen wurden klar begründet

4.2 Technische Abhängigkeiten erwiesen sich als zentral#

Eine wichtige Erkenntnis war, dass funktionale Klarheit nicht ausreichte. Die technische Umsetzung und insbesondere die Abhängigkeiten zwischen Komponenten mussten ebenso klar herausgearbeitet werden. Beispiele aus diesem Projekt:

Die Entscheidung für Markdown als Zwischenformat hatte Auswirkungen auf die gesamte Pipeline
Das Chunking-Verfahren beeinflusste direkt die Übersetzungsqualität und war auf das Context-Management abgestimmt
Die Wahl der parallelen Verarbeitung erforderte entsprechendes Session-Management

Wurden diese Abhängigkeiten nicht vorab geklärt, entstanden Inkonsistenzen oder Refactoring-Bedarf.

4.3 LLMs neigen zu Overengineering#

Eine konsistente Beobachtung war die Tendenz von LLMs zu komplexeren Lösungen als notwendig. In Problembereichen, die einfach erscheinen, wurden oft komplizierte aber “klare” Ansätze vorgeschlagen. Die bessere Lösung ergab sich meist durch sorgfältige Herausarbeitung und Abwägung der Alternativen.

Konkrete Beispiele:

Formatspezifische Pipelines statt einheitlicher Markdown-Verarbeitung
Komplexe State-Management-Lösungen, wo einfache Ansätze ausreichten
Übermäßige Abstraktion bei zunächst einmalig genutzten Funktionen

Die Rolle der Entwickelnden verschob sich: Es ging weniger um Code-Erstellung, mehr um kritische Bewertung der LLM-Vorschläge und aktives Einfordern einfacherer Lösungen.

4.4 Grenzbereiche der Methodik#

Dieses Projekt mit etwa 12.000 Zeilen Code markiert im Umfang bereits einen Grenzbereich. Für größere Projekte werden womöglich noch klarere und systematischere Spezifikationsprozesse relevant. Die Erkenntnis aus diesem Experiment: Mit einer “guten aber nicht ausgesprochen hochwertigen” Spezifikation ließen sich Systeme dieser Komplexität noch erfolgreich umsetzen. Für größere Systeme wird jedoch womöglich ein noch höherer Standard relevant.

Identifizierte Grenzbereiche:

Ab einer gewissen Systemgröße reichte funktionale Klarheit nicht mehr aus
Architekturentscheidungen benötigten explizitere Dokumentation und Begründung
Schnittstellen zwischen Modulen benötigten in diesem Fall präzisere Spezifikation
Performance-Anforderungen erwiesen sich als wichtig zu quantifizieren

4.5 Bewährte Patterns und Strukturierungsansätze#

Einheitliche Pipeline: Die Konsolidierung auf ein einheitliches Zwischenformat (Markdown) vereinfacht das System erheblich und reduziert Fehlerquellen. Dies ist ein womöglich übertragbares Pattern: Heterogene Inputs auf gemeinsames Format normalisieren, dann einheitlich verarbeiten.

Modulare Prompt-Strukturen: Die Verwendung separater, kombinierbarer Prompt-Module für verschiedene Aspekte (Base Translation, Glossary, Context, Styles) erwies sich als wartbar und flexibel.

Context-Management über Grenzen hinweg: Der Ansatz, bei der Verarbeitung segmentierter Daten (Chunks) explizit Kontext mitzuführen, könnte auch auf andere Domänen übertragbar sein – etwa bei der Verarbeitung großer Codebases oder langer Dokumente.

5. Validierung und produktive Nutzung#

5.1 Funktionale Validierung#

Die Validierung erfolgte durch:

Systematische Tests mit verschiedenen Dokumenttypen (PDF, Word, Text) und Größen
Manuelle Überprüfung der Übersetzungsqualität und Strukturerhaltung
Performance-Tests mit großen Dokumenten
Prüfung der Ausgabeformate

Das System erwies sich als robust und liefert qualitativ hochwertige Übersetzungen mit zuverlässiger Strukturerhaltung.

5.2 Produktive Nutzung#

Das Tool ist mittlerweile produktiv im Einsatz. Die Ausgabe in Dateien macht es besonders für größere Übersetzungen hilfreich. Das System hat sich von initial 6 auf mittlerweile 10 unterstützte Sprachen erweitert. Aktuell werden weitere Sprachen angefragt, für die zunächst geprüft werden muss, ob die eingesetzten LLMs diese qualitativ ausreichend ausgeben können.

Die Übersetzungsgeschwindigkeit hängt stark von der Dokumentgröße bzw. der Anzahl der Chunks ab. Kleinere Dateien werden sehr schnell verarbeitet, größere Dokumente profitieren von der parallelen Verarbeitung.

5.3 Evolution vom Experiment zum produktiven Tool#

Das Tool hat sich vom reinen Experiment zu einem produktiv genutzten Werkzeug entwickelt. Dies war sowohl geplant als auch eine positive Überraschung hinsichtlich der Code-Qualität und Robustheit. Die Tatsache, dass das System stabil im Einsatz ist und erweitert wurde, validiert die grundsätzliche Machbarkeit LLM-gestützter Entwicklung für diese Komplexitätsklasse.

6. Beobachtungen für zukünftige Projekte#

6.1 Investition in Spezifikationsqualität#

Eine zentrale Beobachtung für die folgenden Projekte: In diesem Projekt wurde ein großer Aufwand in wirklich klare Spezifikationen investiert – sowohl für funktionale Beschreibungen als auch für Architektur und detaillierte technische Umsetzungskonzepte.

Der Zeitgewinn (6-7 Stunden statt mehrerer Wochen) wurde durch die vorherige Klärung der Anforderungen möglich. Dabei zeigte sich: Je komplexer das System, desto höher waren in diesem Fall die Anforderungen an die Spezifikation.

6.2 Rolle der Entwickelnden#

In diesem Projekt verschob sich die Rolle der Entwickelnden von der Code-Erstellung zu:

Treffen und Begründen von Architekturentscheidungen
Kritischer Bewertung von LLM-Vorschlägen
Aktivem Einfordern einfacher Lösungen
Qualitätssicherung der Spezifikation
Identifizieren und Explizieren technischer Abhängigkeiten

6.3 Balance zwischen funktionaler und technischer Spezifikation#

Eine rein funktionale Spezifikation reichte in diesem Projekt nicht aus. Die technische Umsetzung – insbesondere Architekturentscheidungen und Abhängigkeiten zwischen Komponenten – erwies sich als ebenso wichtig zu klären. Dies erforderte technisches Verständnis bereits in der Spezifikationsphase.

6.4 Iterative Verfeinerung als Beobachtung#

Selbst mit guter Spezifikation waren 2-3 Iterationen für komplexe Module erforderlich. Die Herausforderung lag darin, die richtigen Aspekte in der ersten Iteration zu klären und nicht zu viel Zeit in Überarbeitung zu investieren.

7. Zusammenfassung und Ausblick#

Das Experiment hat gezeigt, dass LLM-gestütztes Coding für Systeme mittlerer Komplexität (hier: ~12.000 Zeilen Code) bei guter Spezifikation effizient funktionierte. Der Zeitgewinn war erheblich. Gleichzeitig wurden Grenzbereiche sichtbar: Das Vorgehen bei der Entwicklung der Spezifikation und der Prozess zur Umsetzung sind dabei wesentliche Faktoren.

Für größere Projekte werden womöglich noch systematischere Spezifikationsprozesse relevant sein. Die Herausforderung liegt darin, funktionale und technische Anforderungen sowie Architekturentscheidungen so zu dokumentieren, dass LLMs daraus konsistenten, wartbaren Code generieren können.

Die Tendenz von LLMs zu Overengineering erforderte aktive Steuerung durch die Entwickelnden. Einfache Lösungen mussten eingefordert, Alternativen mussten abgewogen werden. Die Rolle der Entwickelnden wandelt sich vom Code-Schreiber zur Architektin und Qualitätssicherer.

Metriken im Überblick:

Entwicklungsaufwand: 6-7 Stunden (davon 30-60 Min Spezifikation)
Codeumfang: ~12.000 Zeilen in 40 Dateien
Haupt-Iterationen: 3 (Initial → Einheitliche Pipeline → Finale Version)
Unterstützte Sprachen: 6 initial, 10 aktuell
Status: Produktiv im Einsatz

Dieser Beitrag ist Teil einer Serie zur methodischen Dokumentation von LLM-gestützten Entwicklungsprojekten.