LLM-gestützte Softwareentwicklung: Methodische Erkenntnisse aus der Praxis#

Eine Experimentserie zur Exploration neuer Entwicklungsansätze#

Seit der Verfügbarkeit leistungsfähiger Large Language Models stellt sich die Frage: Wie verändert sich der Softwareentwicklungsprozess? Wo liegen die praktischen Möglichkeiten – und wo die Grenzen? Diese Serie dokumentiert methodische Beobachtungen aus verschiedenen Experimenten und Entwicklungsprojekten, die mit LLM-Unterstützung realisiert wurden.

Als Comic#

Übersicht der KI-Tools#

Der experimentelle Ansatz#

Die dokumentierten Projekte umfassen Tools unterschiedlicher Komplexität: Von Dokumenten-Verarbeitungssystemen über Übersetzungs-Pipelines bis zu Code-Analyse-Werkzeugen. Die Entwicklungszeiten bewegten sich zwischen einer und sieben Stunden für funktionsfähige Prototypen – ein Zeitrahmen, der in erheblichem Kontrast zu konventionellen Entwicklungsansätzen steht.

Dabei geht es explizit nicht um Produktivsoftware für kritische Systeme, sondern um explorative Entwicklung: Rapid Prototyping, Machbarkeitsstudien, interne Werkzeuge und spezialisierte Analyse-Tools. Der Fokus liegt auf der Frage, wie weit man mit systematischer LLM-Unterstützung kommt – und wo methodische Grenzen sichtbar werden.

Zentrale Erkenntnisse#

Spezifikation als Erfolgsfaktor: Über alle Projekte hinweg erwies sich die Qualität der Spezifikation als entscheidend. Je klarer funktionale Anforderungen, technische Abhängigkeiten und Architekturentscheidungen vorab herausgearbeitet wurden, desto fehlerfreier verlief die Umsetzung. Die Investition in Spezifikationsqualität – typischerweise 20 bis 90 Minuten – zahlte sich in drastisch reduziertem Implementierungsaufwand und erhöhter Code-Qualität aus.

Aktive Steuerung erforderlich: LLMs neigen zu komplexen Lösungen, die vermutlich in ihren Trainingsdaten enthalten sind, aber nicht immer sauber repliziert werden können. Das konsequente Einfordern einfacher Ansätze (KISS-Prinzip) erwies sich als notwendige Steuerungsaufgabe während der Spezifikationserstellung.

Strukturierung für Wartbarkeit: Klare Modularisierung mit Größenlimits pro Datei (typischerweise unter 1000 Zeilen) verbesserte sowohl die Code-Qualität als auch die Wartbarkeit durch LLMs. Größere Komplexität musste in handhabbare Teile zerlegt werden – eine Dekomposition, die LLMs noch nicht immer sinnvoll leisten können.

Veränderte Entwicklerrolle: Der Workflow verschiebt sich: Anforderungsklärung, Architekturentscheidungen und kritische Bewertung von LLM-Vorschlägen werden zu Kern-Kompetenzen, während Implementierungsdetails für diese Art Aufgaben weniger Gewicht haben.

Grenzen und Anwendungsfelder#

Die Projekte erreichten verschiedene Komplexitätsstufen: Von 2.000 Zeilen Code für fokussierte Tools bis zu fas 20.000 Zeilen für komplexere Systeme. Dabei wurde deutlich, dass die Methodik ihre Stärken im Bereich von Prototypen, Analyse-Werkzeugen und internen Utilities entfaltet – nicht jedoch für sicherheitskritische Produktivsysteme oder Komponenten mit hohen Qualitätsanforderungen.

Ein fundiertes Verständnis für Software-Architektur bleibt Voraussetzung: Nicht um selbst zu codieren, aber um realistische und kontrollierbare Lösungen zu spezifizieren und die Angemessenheit von LLM-Vorschlägen zu bewerten.

Ziel dieser Dokumentation#

Diese Serie fokussiert auf womöglich übertragbare Patterns und methodische Limitierungen, nicht auf die entwickelten Tools selbst. Die Erkenntnisse sollen anderen Entwickelnden und Teams helfen, LLM-gestützte Entwicklungsansätze realistisch einzuschätzen und effektiv einzusetzen.

Die dokumentierten Projekte zeigen: LLM-gestützte Entwicklung ist kein Ersatz für professionelle Softwareentwicklung, aber eine wertvolle Ergänzung für explorative Phasen, Rapid Prototyping und die schnelle Validierung von Tool-Ideen.

In den folgenden Beiträgen werden konkrete Projekte und ihre spezifischen methodischen Erkenntnisse detailliert dokumentiert.