LLM-Enabled Development - Entwicklung eines Tools mit LLMs#

Code-Analyse#

Das Experiment: Entwicklung eines Code-Analyse-Tools für Java-Projekte mit realistischer Komplexität.

Das Ergebnis: In 2-3 Stunden entstanden 5000-6000 Zeilen Code, mit dem ein Projekt mit 1,2 Millionen Zeilen analysiert wurde.

Die Fragen#

Wie funktioniert das Wechselspiel von Spezifikation und Code-Erzeugung bei steigender Komplexität?
Welche Architektur-Patterns sind notwendig?
Wo sind die praktischen Grenzen?
Wie geht man mit Halluzinationen und Overengineering-Tendenzen um?
Wie lassen sich die Ergebnisse einer solchen Analyse gut lesbar darstellen?

Der technische Ansatz#

Das entwickelte Tool basiert auf einem hierarchischen Analyseansatz, der die Grenzen von LLM-Kontexten berücksichtigt:

File-Level: Detaillierte Analyse einzelner Dateien
Package-Level: Aggregation auf Package-Ebene
Module-Level: Modul-basierte Betrachtung
System-Level: Gesamtarchitektur

Für jede Java-Datei wurden vier spezialisierte LLM-Analysen durchgeführt: Business Logic, Technical Aspects, Interfaces und Issue Detection. Diese Aufteilung entwickelte sich iterativ, da ein einzelner Prompt nicht ausreichend fokussiert war.

Die technische Umsetzung erfolgte mit Python, Gradio und Mistral Small 2506 als lokale LLM. Die Entscheidung für ein lokales Modell war notwendig, um die große Anzahl von LLM-Anfragen ohne API-Limits durchführen zu können. Das finale Tool umfasst 5000-6000 Zeilen Code in 6 Python-Dateien.

Der Entwicklungsprozess#

Spezifikationsphase (1 Stunde): In enger Zusammenarbeit mit verschiedenen LLMs wurden Requirements und Constraints erarbeitet. Der Dialog war bewusst so gestaltet, dass das LLM Fragen stellen und Klarstellungen einfordern konnte. Ein zentraler Aspekt war die aktive Steuerung gegen Overengineering (KISS-Prinzip: Keep It Small and Simple), da LLMs dazu neigen, eher komplexe Lösungen vorzuschlagen.

Implementierungsphase (2 Stunden): Die Code-Generierung erfolgte in 4-5 Iterationen ohne späteres Refactoring. Der Workflow folgte einem klaren Muster: Funktionale Anforderungen → UI-Struktur → Technologiewahl → Architektur. Technische Rahmenbedingungen wurden teils vorgegeben, teils in Diskussion entwickelt.

Zentrale Ergebnisse#

Spezifikation als Erfolgsfaktor: LLM-gestützte Entwicklung funktioniert über Spezifikationen. Je klarer, widerspruchsfreier und vollständiger die Spezifikation, desto besser der generierte Code. Diese Klarheit kann in einem Dialog mit dem LLM erarbeitet werden, da das LLM durch gezielte Fragen Lücken aufdecken kann.

Beobachtete Grenzen: LLMs generierten Code zuverlässig bis etwa 1000-1500 Zeilen pro Komponente. Darüber hinaus nahm die Qualität ab. Der Prozess erforderte zudem ein fundiertes Verständnis von Software-Architektur – nicht um selbst zu codieren, aber um realistische und kontrollierbare Lösungen zu spezifizieren.

Overengineering-Problem: LLMs überschätzen häufig ihre Entwicklungskompetenz und schlagen zu komplexe Lösungen vor. Die konsequente Anwendung des KISS-Prinzips (Keep It Small and Simple) erwies sich als hilfreich.

Veränderter Workflow: Die Rolle der Entwickelnden verschiebt sich: Anforderungsklärung und Architektur-Entscheidungen werden zum Kern-Skill, während Implementierungs-Details delegiert werden können. Dies ermöglichte es Fachexperten ohne tiefe Programmierkenntnisse, spezialisierte Tools für ihre Domäne zu entwickeln.

Technische Validierung#

Das Tool wurde auf ein reales Java-Projekt mit ca. 1,2 Millionen Zeilen Code angewendet (inklusive XML und XSD). Die Analyse funktionierte:

Code lief ohne Abstürze komplett durch
Projekt-Struktur mit Architekturstil wurde erkannt
Package-Hierarchie mit Layer-Zuordnung wurde generiert
REST- und SOAP-Schnittstellen wurden katalogisiert
Issues wurden kategorisiert

Die LLM-generierten Beschreibungen waren sprachlich lesbar, erkannte Architekturmuster erschienen plausibel. Eine detaillierte fachliche Validierung war nicht Ziel – es ging um methodische Erkenntnisse, nicht um Produktivsoftware.

Fazit: Erkenntnisse aus dem Projekt#

Das Experiment übertraf die Erwartungen: Ein in 3 Stunden entwickeltes Tool lieferte praktisch nutzbare Ergebnisse. Dies zeigt das Potenzial von LLM-basierter Entwicklung für explorative Entwicklung und Rapid Prototyping.

Wichtige Klarstellung: In der professionellen Softwareentwicklung würde ein kritisches Produktivtool nicht in 3 Stunden entwickelt – genau deshalb war dies ein Experiment. Die Frage war: Wie weit kommt man überhaupt? Die Antwort: Weiter als erwartet, aber mit klaren Grenzen.

Der Ansatz eignet sich für Prototypen, Analyse-Tools, interne Utilities, Machbarkeitsstudien, explorative Entwicklung und eher nicht für Produktivsysteme und sicherheitskritische Komponenten.

Ein fundiertes Verständnis für Software-Architektur bleibt Voraussetzung – nicht um selbst zu codieren, aber um realistische Lösungen zu spezifizieren. LLM-gestützte Entwicklung erweitert die Möglichkeiten von Fachexperten ohne tiefe Programmierkenntnisse, ersetzt aber nicht die professionelle Software-Entwicklung für kritische Systeme, sondern ergänzt sie um eine neue Dimension der Exploration.

Technische Details#

Technologie-Stack: Python, Gradio, Mistral Small 2506 (lokal)
Architektur: Asynchrone Verarbeitung mit Semaphore-basiertem Rate Limiting
Datenhaltung: YAML-basierte Speicherung für weitere LLM-Verarbeitung
Zeitaufwand: 3 Stunden (1h Spezifikation + 2h Implementierung), verteilt über mehrere Tage
Code-Umfang: 5000-6000 LOC in 6 Dateien
Analysiertes Projekt: 1,2 Millionen LOC