Erkenntnisse aus einem KI-gestützten Umfrage-Tool: Wenn Konzeptionelle Komplexität wichtiger wird als Codezeilen#

Kontext: Im Rahmen eines Lernprojekts entstand ein KI-gestütztes Umfrage-Tool, das intelligente Nachfragen stellt, um unklare Antworten zu präzisieren. Das primäre Ziel war nicht das Tool selbst, sondern die Exploration methodischer Grenzen und Möglichkeiten des LLM-gestützten Codings bei mehrstufigen Workflows.

Das Tool: Intelligente Umfrage-Orchestrierung#

Das entwickelte System basiert auf einem Single-Agent-Ansatz mit drei Kernfunktionen: Ein SurveyAgent bewertet eingehende Antworten auf Klarheit und Spezifität, generiert bei Bedarf kontextspezifische Nachfragen und strukturiert finale Antworten für späteres Clustering. Die technische Umsetzung erfolgte mit Python, Gradio für das UI, Pydantic für Datenvalidierung und asyncio für asynchrone Verarbeitung – ein bewusst gewählter Stack auf Basis vorhandener Erfahrungen, um sich auf die eigentliche Lernaufgabe konzentrieren zu können.

Das System verarbeitet Umfrage-Antworten in einem mehrstufigen Workflow: Nach jeder Antwort erfolgt eine automatische Bewertung (Clarity Score 0-1), bei unzureichender Klarheit generiert der Agent eine gezielte Nachfrage, die erweiterte Antwort wird erneut bewertet und schließlich in eine strukturierte Form für statistische Auswertung überführt. Die Modularität wurde von Anfang an in der Spezifikation festgelegt, um klare Verantwortlichkeiten zu schaffen.

Zentrale methodische Erkenntnisse#

1. Konzeptionelle Komplexität übertrifft Code-Menge: Die eigentliche Herausforderung lag nicht in der Anzahl der Codezeilen (4.000 Zeilen, 15 Dateien), sondern im Verständnis der benötigten Architekturmuster. Ohne vorherige Erfahrung mit solchen Agent-Workflow-Interaktionen war es schwierig zu spezifizieren, wie die einzelnen Komponenten orchestriert werden sollten. Dies führt zur Erkenntnis: Für komplexere LLM-Architekturen braucht es zunächst explorative Prototypen, um die Architekturmuster überhaupt kennenzulernen.

2. LLMs neigen zu Overengineering: Während der 5-6 Iterations-Runden zur Verfeinerung der Prompt-Templates zeigte sich wiederholt, dass das LLM zu ehrgeizige und komplexe Mechanismen vorschlug. Es war notwendig, das Konzept streng simpel zu halten und das LLM aktiv in Richtung KISS-Prinzip zu lenken. Dies erforderte explizite Vorgaben gegen unnötige Abstraktionen.

3. Strukturierte JSON-Outputs als Schlüssel: Die konsequente Verwendung strukturierter JSON-Responses war entscheidend für die Interaktion zwischen Survey-Agent, Workflow-Manager und UI. Dies ermöglichte eine klare Zustandsverwaltung und vorhersagbare Datenflüsse. Gleichzeitig ergab sich ein kritisches Learning: JSON-gesteuerte LLM-Systeme benötigen robuste Safeguards gegen Endlosschleifen, da fehlerhafte Verarbeitung schnell zu zirkulären Nachfragen führen kann.

4. Spezifikation vs. Experimentieren: Die initiale Spezifikationsphase (2 Stunden) war wichtig, um grundlegende Anforderungen zu klären. Allerdings zeigte sich, dass bei neuartigen Architekturmustern die Spezifikation allein nicht ausreicht – die tatsächliche Machbarkeit und optimale Strukturierung erschließen sich erst durch praktisches Experimentieren. Dies führte zu einem iterativen Ansatz aus Spezifikation, Implementierung und Architektur-Lernen.

5. Grenzen bei der Kriterienableitung: Die größte technische Herausforderung lag in der automatischen Ableitung von Bewertungskriterien aus Antworten. Während das System bei eindeutigen Fällen (sehr vage vs. sehr spezifisch) zuverlässig funktionierte, war die Bewertung der Vollständigkeit von Antworten inkonsistent. Dies deutet auf eine grundsätzliche Limitation bei der semantischen Tiefenanalyse hin.

Praktische Tauglichkeit und Folgen#

Das Tool wurde funktional validiert und zeigt gemischte Ergebnisse: Für bestimmte Fragetypen funktioniert das Nachfragesystem zuverlässig, bei anderen bleibt die Kriterienableitung problematisch. Die Entwicklungszeit von vier Stunden reiner Implementierung über drei Tage hinweg demonstriert die Effizienz von LLM-gestütztem Coding für klar definierte Aufgaben.

Das Projekt war explizit als exploratives Lernvehikel konzipiert. Die gewonnenen Erkenntnisse flossen direkt in ein verbessertes Nachfolgeprojekt (“ppt-helper”) ein, das die Architekturmuster mit mehreren spezialisierten Agenten weiterentwickelt. Dies zeigt den eigentlichen Wert solcher Experimente: Nicht die unmittelbare Produktivnutzung, sondern der systematische Kompetenzaufbau für komplexere LLM-Architekturen.

Fazit#

Die zentrale Erkenntnis dieses Experiments: Bei LLM-gestützter Entwicklung komplexerer Systeme ist Architektur-Verständnis der limitierende Faktor, nicht die Code-Generierung. LLMs sind hocheffizient bei der Umsetzung klar spezifizierter Komponenten, aber die Orchestrierung mehrstufiger Workflows erfordert Erfahrung, die sich nur durch praktisches Experimentieren aufbauen lässt. Eine klare, aber nicht überdetaillierte Spezifikation kombiniert mit iterativem Prototyping bildet den optimalen Workflow. Dabei muss das LLM aktiv zu einfachen Lösungen gelenkt werden – seine natürliche Tendenz geht in Richtung Overengineering.

Für zukünftige Projekte bedeutet dies: Komplexe Architekturen sollten zunächst in kleinen explorativen Prototypen erprobt werden, um die erforderlichen Muster zu verstehen, bevor man zur produktiven Implementierung übergeht.