LLM-gestützte Softwareentwicklung: Eine Experimentserie zu Möglichkeiten und Grenzen#

Von der Demokratisierung früherer IT-Werkzeuge zur Demokratisierung der Code-Erzeugung

Digitale Musikproduktion, Fotografie und Videobearbeitung demokratisierten Studios und Dunkelkammern. Content-Management-Systeme machten Web-Entwicklung zugänglich. Die Möglichkeiten von LLM-unterstützter Software-Entwicklung deuten in Teilen auf eine vergleichbare Demokratisierung hin. Die zentrale Frage: Wo liegen die praktischen Grenzen dieser neuen Möglichkeiten – und welche Expertise bleibt weiterhin essentiell?

Um diese Fragen zu erkunden, wurden in loser Folge Experimente durchgeführt. Entwickelt wurden dabei Tools unterschiedlicher Komplexität: Von einfachen Interfaces über Multi-Agent-Systeme bis zu Code-Analyse-Werkzeugen. Die Ergebnisse dokumentieren sowohl interessante Möglichkeiten als auch klare Grenzen.

Ergebnisse: Entwicklungen im Bereich von 90 Minuten bis hin zu mehreren Tagen#

Die Entwicklungszeiten variierten dabei je nach Projektkomplexität:

Ein Chat-Interface mit History-Funktion: 90 Minuten für 800 Zeilen Code
Ein Code-Analyse-Tool, das 1,2 Millionen Zeilen Java hierarchisch analysiert: 3 Stunden für 5.000-6.000 Zeilen
Ein Präsentations-Tool mit Zwei-Agenten-Architektur: 2 Stunden Planung plus 30-60 Minuten Coding für 3.000 Zeilen
Ein Dokumenten-Übersetzungssystem mit Kontext-Management: 6-7 Stunden für 12.000 Zeilen (initial wurden 4-6 Wochen geschätzt)

Die Zeitersparnis bewegt sich im Bereich von Stunden zu Tagen gegenüber klassischer Entwicklung. Alle entwickelten Tools erwiesen sich als nützlich für ihren jeweiligen Aufgabenzweck.

Spezifikationsqualität 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 und geklärt wurden, desto fehlerfreier verlief die Umsetzung. Eine Investition von 20 bis 90 Minuten in eine strukturierte Spezifikation reduzierte den Implementierungsaufwand erheblich.

Dabei kommt es auf die Tiefe der Spezifikation an: Sie sollte die genaue Gestaltung des User-Interfaces bis hin zu einzelnen Elementen umfassen, die einzusetzenden Technologien benennen und die gewünschte Architektur definieren. Diese Präzision ermöglicht dem LLM eine deutlich genauere Umsetzung als vage Anweisungen.

Wo die Methodik an ihre Grenzen stößt#

Die Experimente deuten einige Limits an:

Etwa 1.000-1.500 Zeilen Code pro Datei sollten nicht überschritten werden, um die Wartbarkeit für LLMs zu erhalten.
Mit guter Spezifikation können bis zu 12.000 Zeilen Code für solche Anwendungen kontrolliert werden.
Mit zusätzlicher Architektur-Strukturierung sind bis etwa 20.000 Zeilen erreichbar.
Wie darüber hinaus mit größeren Anwendungen zu arbeiten ist, muss noch erkundet werden

Derzeit ist ein fundiertes Verständnis für Software-Architektur für erfolgreiche LLM-gestützte Entwicklung noch wesentlich. IT-Fachkräfte mit Erfahrung in Systemarchitekturen können solche Entwicklungen aktuell leichter durchführen. Es ist jedoch zu erwarten, dass diese Möglichkeiten perspektivisch auch weiteren Personenkreisen zugänglich werden – ähnlich wie bei früheren Demokratisierungswellen.

Das Konzept des “Casual Code”#

Die reduzierten Entwicklungszeiten führen zu einem veränderten Charakter von Software: Code ist nicht mehr ausschließlich ein sorgfältig gepflegtes Artefakt, sondern bekommt zunehmend transiente und ephemerale Aspekte. Code kann für eine Nutzung über nur einige Stunden, Tage oder Wochen erstellt werden – als Wegwerf-Prototyp oder experimentelles Werkzeug.

Gleichzeitig stellt eine verstärkte Nutzung kurzlebiger Code-Komponenten etablierte Betriebsprozesse vor neue Herausforderungen. Während traditionelle Qualitätssicherung auf stabile, langfristige Systeme ausgelegt ist, müssen nun neue Ansätze für dynamische Code-Bestände entwickelt werden. Deshalb empfiehlt sich, Technologien zu wählen, deren Verhalten im Betrieb bereits bekannt ist. Auch bedarf es spezialisierter Deployment-Logik, die effizient mit vielen kleinen, kurzlebigen Services umgehen kann – ohne dabei die notwendige Qualitätssicherheit zu vernachlässigen.

Anwendungsfelder und Abgrenzungen#

Diese Methodik eignet sich für:

Rapid Prototyping und Machbarkeitsstudien
Interne Werkzeuge und Analyse-Tools
Explorative Entwicklung und didaktische Szenarien
Software-Untersuchungen
Demonstratoren unter Nutzung von Schnittstellen

und eignet sich eher weniger für:

Sicherheitskritische Produktivsysteme
Hochqualitative Produktivsoftware mit strengen Qualitätsanforderungen
Komplexe Systeme mit umfangreichen Abhängigkeiten

Auswirkungen für den IT-Alltag#

Die beobachteten Möglichkeiten werfen viele weitere Fragen auf:

Wie integriert man rapid prototyping in bestehende Entwicklungsprozesse?
Welche Qualifikationen werden wichtiger? (Spezifikation, Architektur-Verständnis, Technologie-Kenntnis) Welche weniger zentral? (Detail-Implementierung, Syntax-Kenntnisse)
Wie geht man mit der steigenden Menge an “Casual Code” um?
Welche Governance-Richtlinien gelten für LLM-entwickelten Code?
Welche Deployment-Strategien sind für viele kleine, kurzlebige Tools angemessen?

Fazit#

LLM-gestützte Entwicklung ersetzt nicht professionelle Softwareentwicklung – sie ergänzt sie für explorative Phasen und Rapid Prototyping. Die Demokratisierung folgt historischen Mustern der Ermöglichung von einfachen zu komplexeren Szenarien. Hierdurch erweitert sich gleichzeitig der Kreis derer, die funktionale Tools entwickeln können.

Ihre Perspektive ist gefragt: Welche Erfahrungen haben Sie mit LLM-gestützter Entwicklung gemacht? Wo sehen Sie die größten Chancen – und die kritischsten Herausforderungen?

Die Serie fokussiert auf übertragbare Patterns und methodische Limitierungen, nicht auf die entwickelten Tools selbst.