LLM-gestütztes Coding: Von der Spezifikation zur Implementierung eines Document-Chat-Tools#

Einleitung#

Diese Dokumentation beschreibt ein Experiment zur Exploration von LLM-gestütztem Coding, das Teil einer fortlaufenden Serie zur Untersuchung von Möglichkeiten und Grenzen dieser Entwicklungsmethodik ist. Im Zentrum steht die Frage, wie detaillierte Spezifikationen die Qualität und Geschwindigkeit der Code-Generierung beeinflussen und welche Architektur-Patterns sich für LLM-basierte Entwicklung bewähren.

Das entwickelte Tool diente primär als Vehikel zur Beantwortung spezifischer methodischer Fragen. Die praktische Nutzbarkeit des Tools war zunächst sekundär, erwies sich jedoch im Verlauf als unerwartet hoch.

Experimenteller Kontext und Motivation#

Ausgangssituation#

Nach erfolgreicher lokaler Inbetriebnahme eines Large Language Models mit 256K Token Kontext stellte sich die Frage nach den praktischen Grenzen dieser Kontextgröße. Frühere Experimente zeigten, dass die Konsistenz von LLM-Antworten typischerweise mit zunehmender Token-Anzahl abnimmt. Unklar war, ob und wie sich große Kontextfenster produktiv für die Verarbeitung umfangreicher Dokumente nutzen lassen.

Lernziele des Experiments#

Das Experiment verfolgte mehrere methodische Ziele:

• Praktische Evaluation der Nutzbarkeit langer Kontexte für Dokumentenverarbeitung
• Systematische Untersuchung der Antwort-Konsistenz bei hoher Token-Auslastung
• Vertiefung der Methodik schneller Entwicklung durch hochwertige Spezifikation
• Exploration optimaler Token-Nutzung ohne klassische Chunking-Strategien

Auswahl des Übungsbeispiels#

Die Entwicklung eines “Talk to Documents”-Tools erschien als geeignetes Testfeld, da es mehrere Komplexitätsdimensionen vereint:

• Verarbeitung verschiedener Dokumentformate
• Intelligente Content-Optimierung für Token-Effizienz
• Multi-Dokument-Management mit Kontext-Limitierung
• Implementierung eines Referenzsystems für Quellenangaben
• Integration einer Web-Oberfläche für praktische Nutzbarkeit

Die Komplexität war ausreichend, um aussagekräftige methodische Erkenntnisse zu generieren, ohne die Grenzen LLM-gestützter Entwicklung zu überschreiten.

Funktionsweise des entwickelten Tools#

Kernfunktionalität#

Das Tool ermöglicht das Hochladen von bis zu 10 Dokumenten in verschiedenen Formaten (PDF, Word, Excel, PowerPoint, Text, Markdown, HTML, CSV, RTF). Nach dem Upload durchlaufen die Dokumente mehrere Verarbeitungsschritte:

• Extraktion: Nutzung der Unstructured-Bibliothek zur Extraktion strukturierter Inhalte aus verschiedenen Formaten
• Content-Cleaning: Entfernung von Headers, Footers, Seitenzahlen und anderen wiederkehrenden Metadaten
• Deduplizierung: Identifikation und Entfernung doppelter oder nahezu identischer Inhalte
• Markdown-Formatierung: Konvertierung in strukturerhaltende Markdown-Repräsentation
• Referenzierung: Automatische Einfügung von [P1], [P2]-Markierungen für Quellenangaben
• Token-Zählung: Berechnung und Visualisierung der Kontext-Auslastung

Die verarbeiteten Dokumente werden vollständig im LLM-Kontext gehalten, ohne externe Datenbanken oder Retrieval-Mechanismen. Anfragen werden direkt mit dem kombinierten Dokumentenkontext an das LLM gesendet.

Modularisierung#

Die Modularisierung folgt einer klaren Struktur:

• Extractors: Dokumenten-Verarbeitung und Content-Extraktion
• Optimizers: Content-Cleaning, Deduplizierung, Formatierung
• LLM-Integration: API-Kommunikation und Multi-Dokument-Management
• UI: Gradio-basierte Web-Oberfläche

Jedes Modul bleibt unter 1000 Zeilen Code, was sich als praktikable Grenze für LLM-Wartbarkeit erwiesen hat. Die Hauptanwendung umfasst 800 Zeilen, der Word-Exporter 400 Zeilen, das LLM-Interface 300 Zeilen, die Formatierung 250 Zeilen.

Entwicklungsprozess#

Phase 1: Spezifikationserstellung (90 Minuten)#

Der Hauptaufwand des Projekts konzentrierte sich auf die Erstellung einer detaillierten Spezifikation in interaktiver Zusammenarbeit mit einem LLM. Diese Phase umfasste:

• Diskussion verschiedener Architekturansätze und Abwägung ihrer Vor- und Nachteile
• Evaluation verschiedener Referenzsysteme für Quellenangaben
• Definition konkreter Implementierungsdetails für alle Module
• Spezifikation der Schnittstellen zwischen Komponenten
• Festlegung von Konventionen und Limitierungen

Für das Referenzsystem wurden mehrere Alternativen diskutiert, darunter komplexe Metadaten-Strukturen, Paralleldokumente mit Annotationen und verschiedene Retrieval-Mechanismen. Die finale Lösung mit einfachen [P1], [P2]-Markierungen erwies sich als funktional: simpel und zuverlässig implementierbar.

Ein zentrales Thema während der Spezifikationserstellung war die konsequente Anwendung des KISS-Prinzips (Keep It Small and Simple). Dies erforderte aktives Gegensteuern, da LLMs zur Suggestion aufwendiger Lösungen tendieren, die möglicherweise in ihren Trainingsdaten enthalten sind, aber nicht immer sauber repliziert werden können.

Phase 2: Code-Generierung (60 Minuten)#

Nach Abschluss der Spezifikation erfolgte die Code-Generierung durch Übergabe des vollständigen Spezifikationsdokuments an das LLM. Die Implementierung verlief in drei Hauptiterationen:

1. Iteration 1: Generierung der Kernmodule (Extractors, Optimizers, LLM-Interface)
2. Iteration 2: Implementierung der UI-Komponenten und Integration
3. Iteration 3: Finalisierung mit Word-Export und Deployment-Konfiguration

Die meisten Module funktionierten direkt beim ersten Durchlauf. Lediglich einzelne Anpassungen in der Dokumentenformatierung und der Integration hochwertiger Prompts für den Alltagseinsatz erforderten Nachbesserungen.

Phase 3: Dokumentation und Deployment (ca. 60-90 Minuten)#

Die finale Phase umfasste die Erstellung von README, Deployment-Konfiguration und initialen Tests. Der gesamte Entwicklungsprozess erstreckte sich über drei Tage, was iterative Reflexionsphasen zwischen den Arbeitssessions ermöglichte.

Eingesetzte LLMs#

Während der Entwicklung kamen verschiedene LLMs zum Einsatz, sowohl für die Spezifikationserstellung als auch für die Code-Generierung. Für den produktiven Betrieb des Tools wird Qwen3-30B-A3B-Instruct-2507 verwendet, ein lokal betriebenes Modell mit 256K Token Kontext.

Technische Besonderheiten der Implementierung#

Content-Optimierung#

Die Token-Effizienz war ein zentraler Aspekt, da zu Projektbeginn unklar war, wie weit sich der verfügbare Kontext ausreizen lässt. Die Optimierungsstrategie umfasste mehrere Teile:

Content-Cleaning: Automatische Entfernung von wiederkehrenden Elementen wie Seitenzahlen, Kopf- und Fußzeilen, Copyright-Vermerken und grafischen Artefakten (Linien, Trennzeichen). Die Erkennung erfolgt durch Musterabgleich und Identifikation wiederholender Strukturen.

Deduplizierung: Dreistufiger Ansatz zur Eliminierung redundanter Inhalte: Exakte Duplikate über Hash-Vergleiche, nahezu identische Inhalte über Fuzzy-Matching, strukturelle Duplikate wie wiederholte Tabellen-Header über Strukturanalyse.

Markdown-Formatierung: Konvertierung von Tabellen, Listen und Überschriften in kompakte Markdown-Syntax bei Erhaltung der Dokumentstruktur. Dies reduziert den Token-Verbrauch im Vergleich zu vollständigem HTML oder proprietären Formaten erheblich.

Token-Zählung und Visualisierung#

Die Integration von Tiktoken zur approximativen Token-Zählung erwies sich als hilfreiche Erweiterung gegenüber früheren Projekten. Die Visualisierung der Kontext-Auslastung ermöglicht das Verständnis der verbleibenden Kapazität und verhindert Überschreitungen des Kontextlimits.

Diese Komponente wurde in nachfolgende Projekte übernommen und etabliert sich als Standard-Pattern für Anwendungen mit Kontext-Limitierungen.

Streaming und Interaktivität#

Die Implementierung von Token-by-Token-Streaming verbessert die wahrgenommene Reaktionsgeschwindigkeit erheblich. Ein Stop-Button ermöglicht das Abbrechen langer Antworten, was sich in der Praxis nachträglich als notwendig erwies.

Eine technische Herausforderung ergab sich für die Minimierung von UI-Flickering bei LaTeX-Formeln während des Streamings. Die Lösung verwendet einen Buffer-Mechanismus, der Zeichen sammelt und Updates an semantischen Grenzen (Satzenden, Absätzen) durchführt.

Methodische Erkenntnisse#

Spezifikationsqualität als Erfolgsfaktor#

Eine zentrale Erkenntnis des Experiments: Hochwertige Spezifikationen übersetzen sich direkt in überwiegend fehlerfreie, wartbare Implementierungen. Eine LLM-taugliche Spezifikation muss über funktionale Anforderungen hinausgehen und den expliziten Zusammenhang zwischen Funktion, Architektur und technischer Implementierung herstellen.

Konkret bedeutet dies:

• Nicht nur “Was” wird implementiert, sondern auch “Wie” und “Warum”
• Explizite Nennung von Designentscheidungen und ihren Begründungen
• Bewusste Entscheidungen zu eingesetzten Frameworks und auch deren Versionen
• Konkrete Beispiele für erwartete Eingaben und Ausgaben
• Spezifikation von Fehlerbehandlung und Randfällen
• Definition von Schnittstellen zwischen Komponenten

Die Qualität der Spezifikation entwickelt sich über mehrere Projekte kontinuierlich weiter. Jedes Experiment liefert Erkenntnisse darüber, welche Aspekte expliziter formuliert werden müssen.

KISS-Prinzip als aktive Steuerungsaufgabe#

Die Durchsetzung einfacher Lösungen erforderte kontinuierliche Aufmerksamkeit während der Spezifikationserstellung. LLMs tendieren dazu, aus ihren Trainingsdaten komplexe, möglicherweise über-engineerte Lösungen zu suggerieren. Diese Lösungen sind häufig nicht optimal replizierbar oder führen zu schwer wartbarem Code.

Die Angemessenheit vorgeschlagener Ansätze wurde kontinuierlich hinterfragt:

• Ist dieser Ansatz für das spezifische Problem angemessen?
• Gibt es einfachere Alternativen?
• Werden aktuelle Versionen von Frameworks berücksichtigt?
• Kann die Lösung vom LLM zuverlässig implementiert werden?
• Bleibt der Code wartbar und verständlich?

Diese kritische Evaluation erfolgte bereits während der Spezifikationserstellung, nicht erst bei der Code-Review.

Modularisierung und Größenlimitierung#

Die Grenze von 1000 Zeilen pro Datei erwies sich als praktikable Heuristik. Diese Limitierung basiert auf der Beobachtung, dass LLMs größere Komplexität nicht immer vollständig überblicken können. Bei der Wartung oder Modifikation größerer Dateien steigt die Fehlerrate merklich.

Die Modularisierung nach klaren Aufgabenbereichen ermöglichte isolierte Bearbeitung einzelner Komponenten. Jedes Modul bleibt verständlich und testbar. Die Schnittstellen zwischen Modulen wurden explizit in der Spezifikation definiert.

Grenzen und Möglichkeiten LLM-gestützter Entwicklung#

Trotz erheblicher Fortschritte zeigten sich spezifische Limitierungen:

Komplexitätshandhabung: LLMs konnten größere Systemkomplexität noch nicht selbstständig in kleinere Komponenten zerlegen. Die Zerlegung in handhabbare Teilprobleme blieb Aufgabe der menschlichen Entwickelnden.

Architekturentscheidungen: Grundlegende Designentscheidungen erforderten weiterhin menschliches Urteilsvermögen. LLMs konnten Alternativen aufzeigen und ihre Vor- und Nachteile diskutieren, die finale Entscheidung wurde jedoch informiert getroffen.

Fehlerdiagnose: Bei unerwarteten Fehlern oder Randfällen war menschliche Intervention zur Diagnose häufig effizienter als iterative LLM-Anfragen.

Übertragbare Patterns#

Mehrere Aspekte erwiesen sich als womöglich über dieses Projekt hinaus übertragbar:

Spezifikations-First-Ansatz: Die Investition von mehr als der Hälfte der Gesamtzeit in Spezifikation beschleunigte die Implementierung und reduzierte Fehler erheblich.

Token-Visualisierung: Die Integration von Token-Zählung und Kontext-Auslastungs-Anzeige etabliert sich als Standard-Pattern für kontextbasierte Anwendungen.

Modulare Größenlimitierung: Die 1000-Zeilen-Grenze pro Datei erwies sich als robuste Heuristik für LLM-wartbaren Code.

Iterative Spezifikationsverfeinerung: Die kontinuierliche Verbesserung von Spezifikationsqualität über mehrere Projekte hinweg zeigte messbaren Effekt auf Implementierungsqualität.

Validierung und praktische Bewährung#

Funktionale Tests#

Das Tool wurde durch verschiedene Personen mit unterschiedlichen Dokumenttypen getestet. Die Rückmeldungen fielen durchweg positiv aus, sowohl hinsichtlich Funktionalität als auch Geschwindigkeit.

Überraschende Stärken#

Das Tool wird gerne genutzt und funktioniert sehr überzeugend.

Antwort-Konsistenz: Die zentrale experimentelle Frage nach der Konsistenz bei hoher Token-Auslastung wurde positiv beantwortet. Auch bei Dokumenten mit vielen Token blieben die Antworten konsistent und präzise.

Verarbeitungsgeschwindigkeit: Die Antwortzeiten lagen im Bereich weniger Sekunden und entsprachen typischen LLM-Antwortzeiten.

Vielseitige Anwendbarkeit: Über die ursprüngliche Intention hinaus erwies sich das Tool als nützlich für Versionsvergleiche von Dokumenten und strukturierte Analysen.

Identifizierte Verbesserungspotentiale#

Die Funktion für Quellenangaben funktionierte zuverlässig, könnte jedoch hinsichtlich Detailgrad und Präsentation optimiert werden. Dies betrifft primär die Formatierung und Darstellung der Referenzen, nicht die grundsätzliche Funktionalität.

Die typische Kontext-Auslastung lag deutlich unter den 250K Token, was Spielraum für zusätzliche Features oder komplexere Dokumentensammlungen lässt.

Produktive Nutzung#

Nach der Testphase ist produktiver Einsatz des Tools vorgesehen. Die ursprünglich rein experimentelle Idee entwickelte sich durch die praktische Bewährung in Richtung produktiver Nutzbarkeit. Dies war zu Projektbeginn nicht absehbar, zeigt jedoch die Bedeutung funktionaler Validierung auch bei primär methodisch motivierten Experimenten.

Metriken und Quantifizierung#

Codeumfang#

Das finale System umfasst 3100 Zeilen Code, verteilt auf 16 Python-Dateien. Die Aufteilung nach Komponenten:

• Hauptanwendung (gradio_app.py): 800 Zeilen
• Word-Exporter: 400 Zeilen
• LLM-Interface: 300 Zeilen
• Content-Formatierung: 250 Zeilen
• Verbleibende Module (Extractors, Optimizers, Konfiguration): ca. 1350 Zeilen

Entwicklungszeit#

Gesamtaufwand: 3-4 Stunden, verteilt über 3 Tage

• Spezifikationserstellung: 90 Minuten (45% der Gesamtzeit)
• Code-Generierung: 60 Minuten (30% der Gesamtzeit)
• Dokumentation und Deployment: 60-90 Minuten (25% der Gesamtzeit)

Die Verteilung über mehrere Tage ermöglichte Reflexionsphasen zwischen den Arbeitssessions.

Iterationen#

Drei Hauptiterationen führten vom initialen Code zur finalen Version. Die geringe Iterationszahl resultierte direkt aus der Qualität der Spezifikation.

Unterstützte Formate#

Das Tool verarbeitet mehr als 10 verschiedene Dokumentformate: PDF, Word (DOCX/DOC), Excel (XLSX/XLS), PowerPoint (PPTX/PPT), Text (TXT), Markdown (MD), reStructuredText (RST), HTML (HTML/HTM), CSV, RTF.

Schlussfolgerungen und Ausblick#

Das Experiment bestätigte mehrere zentrale Hypothesen über LLM-gestütztes Coding:

• Hochwertige Spezifikationen waren der kritische Erfolgsfaktor für effiziente LLM-basierte Entwicklung
• KISS-Prinzipien (Keep It Small and Simple) mussten aktiv durchgesetzt werden und entstanden nicht automatisch
• Modulare Strukturierung mit klaren Größenlimitierungen verbesserte LLM-Wartbarkeit erheblich
• Die Grenzen LLM-gestützter Entwicklung lagen primär bei Komplexitätshandhabung und Architekturentscheidungen

Die kontinuierliche Verfeinerung von Spezifikationstechniken über mehrere Projekte zeigte messbaren Effekt. Jedes Experiment trug zur Entwicklung robusterer Patterns bei. Zukünftige Experimente werden sich auf spezifische Aspekte konzentrieren: Skalierung auf größere Projekte, Handhabung verschiedener Dokumentdomänen, Integration zusätzlicher LLM-Fähigkeiten wie Vision-Modelle für OCR. Die Methodik des Spezifikations-First-Ansatzes hat sich als funktional und potenziell skalierbar erwiesen. Die dokumentierten Patterns bieten Orientierung für eigene LLM-gestützte Entwicklungsprojekte.