LLM-Coding-Experiment: Dokumenten-Übersetzungssystem#

Spezifikationsqualität als wichtiger Faktor – und die Grenzen von LLM-gestützter Entwicklung

Im Rahmen meiner Experimentserie zur LLM-gestützten Softwareentwicklung habe ich ein webbasiertes Dokumenten-Übersetzungssystem entwickelt. Das Projekt sollte zwei Fragen beantworten: Wie weit kommt man mit klarer Spezifikation bei komplexeren Anwendungen? Und wo liegen die praktischen Grenzen von LLM-gestütztem Coding?

Das entwickelte System#

Das Tool übersetzt beliebig große Dokumente mittels lokaler LLMs über OpenAI-kompatible Schnittstellen. Es verarbeitet verschiedene Formate (PDF, Word, Text, Markdown) und nutzt ein mehrstufiges Verfahren: Dokumente werden in ein einheitliches Markdown-Format konvertiert, durch intelligentes Chunking in verarbeitbare Segmente unterteilt, parallel übersetzt und wieder zusammengesetzt. Besondere Herausforderungen lagen in der Erhaltung der Dokumentstruktur, der Konsistenz über Chunk-Grenzen hinweg und dem Umgang mit komplexen Elementen wie Tabellen.

Die technische Umsetzung erfolgte mit Python und Gradio, umfasst etwa 12.000 Zeilen Code in 40 Dateien und nutzt asynchrone Verarbeitung für parallele API-Calls. Für die Übersetzungskonsistenz wird ein Context-Management eingesetzt, das Glossare, bereits übersetzte Schlüsselbegriffe und Zusammenfassungen vorheriger Chunks an das LLM übergibt.

Entwicklungsprozess und Zeitaufwand#

Der Gesamtaufwand betrug 6-7 Stunden, verteilt auf drei Haupt-Iterationen. Die initiale funktionale Spezifikation wurde in etwa 30-60 Minuten mit dem LLM erarbeitet, gefolgt von der Code-Generierung in großen Schritten und iterativen Korrekturen. Weitere 60 Minuten entfielen auf Dokumentation und Deployment. Dies steht in erheblichem Kontrast zu den ursprünglich für manuelle Entwicklung geschätzten 4-6 Wochen.

Zum Einsatz kamen verschiedene LLMs während der Entwicklung, im produktiven Betrieb läuft das System mit Mistral Small 2506. Das Tool wird mittlerweile produktiv genutzt und hat sich von 6 auf 10 unterstützte Sprachen erweitert.

Zentrale methodische Erkenntnisse#

1. Spezifikationsqualität erwies sich als zentral#

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

2. Explizite technische Abhängigkeiten#

Die Spezifikation war in diesem Projekt funktional eindeutig, aber hinsichtlich der technischen Umsetzung noch nicht vollständig durchdacht. Wichtige technische Aspekte wie die Verarbeitungspipeline oder das Chunking-Verfahren mussten iterativ geklärt werden. Die Erfahrung zeigte: Technische Abhängigkeiten und schwierige Aspekte der Funktionalität sollten ebenso klar beschrieben sein wie die funktionalen Anforderungen selbst.

3. LLMs neigen zu Overengineering#

In Problembereichen, die einfach erscheinen, schlugen LLMs oft komplizierte Lösungen vor. Initial wurde eine formatspezifische Verarbeitungspipeline implementiert, die später durch eine einheitliche Markdown-basierte Pipeline ersetzt wurde – ein deutlich simplerer und wartbarerer Ansatz. Der komplizierte aber klare Weg erwies sich nicht immer als der beste. Die aktive Einforderung einfacher Lösungen und das sorgfältige Abwägen von Alternativen waren hilfreich.

4. Grenzen der Methodik werden sichtbar#

Dieses Projekt mit etwa 12.000 Zeilen Code erreichte im Umfang bereits die Grenze der Möglichkeiten für LLM-gestütztes Coding mit einer “guten aber nicht ausgesprochen hochwertigen” Spezifikation. Für größere Projekte zeigten sich klarere und systematischere Spezifikationsprozesse als notwendig, die sowohl funktionale Beschreibungen als auch Architektur und detaillierte technische Konzepte umfassen.

Übertragbare Erkenntnisse#

Die Investition in eine hochwertige Spezifikation zahlte sich aus – sowohl in Entwicklungszeit als auch in Code-Qualität. Der drastische Zeitgewinn (6-7 Stunden statt mehrerer Wochen) war nur durch die vorherige Klärung der Anforderungen möglich. Gleichzeitig wurde deutlich, dass sich die Rolle der Entwickelnden verschob: von der Code-Erstellung zur Architekturentscheidung, zur kritischen Bewertung von LLM-Vorschlägen und zur Qualitätssicherung der Spezifikation.

Für nachfolgende Projekte zeigte sich: Eine noch größere Investition in wirklich klare Spezifikationen ist sinnvoll – sowohl für funktionale Beschreibungen als auch für Architektur und detaillierte technische Umsetzungskonzepte.

Dieser Beitrag ist Teil einer Serie zur methodischen Dokumentation von LLM-gestützten Entwicklungsprojekten. Der Fokus liegt auf übertragbaren Erkenntnissen, nicht auf den entwickelten Tools selbst.