LLM-Enabled Development: Von der Demokratisierung des Codings zur veränderten IT-Praxis#

Erkenntnisse aus einer Experimentserie#

Eine weitere Welle der Demokratisierung#

Die Geschichte der IT-Werkzeuge zeigt wiederkehrende Muster der Demokratisierung: Digitale Musikproduktion ersetzte teure Tonstudios, digitale Fotografie die Dunkelkammer, digitale Videobearbeitung kostspielige Schnittplätze. Webseiten-Erstellung, die HTML-Kenntnisse erforderte, ermöglichen heute Content-Management-Systeme auch ohne Programmierkenntnisse. Diese Entwicklungen ersetzten nicht die Expertise professioneller Tontechniker, Fotografen, Cutter oder Web-Entwickler – sie verschoben deren Fokus auf komplexere, anspruchsvollere Projekte, während einfachere Aufgaben von einem größeren Personenkreis bewältigt werden konnten.

Die Möglichkeiten von LLM-unterstützter Software-Entwicklung deuten auf eine vergleichbare Entwicklung hin. Erstmals wird es möglich, in kurzer Zeit funktionsfähige Software zu entwickeln, ohne selbst Code schreiben zu müssen. Die zentrale Frage ist nicht, ob professionelle Softwareentwicklung obsolet wird – sondern wo die praktischen Grenzen dieser neuen Möglichkeiten liegen, welche Expertisen weiterhin hilfreich bleiben und wie sich der Zugang zu Softwareentwicklung erweitert.

Die Experimentserie: Systematische Exploration der Möglichkeiten#

Um diese Fragen empirisch zu untersuchen, wurde eine Serie von Entwicklungsprojekten unterschiedlicher Komplexität durchgeführt. Die entwickelten Tools reichten von einfachen Textbearbeitungs-Interfaces über Multi-Agent-Systeme bis zu Code-Analyse-Werkzeugen. Die Entwicklungszeiten bewegten sich zwischen einer und sieben Stunden, die Code-Umfänge zwischen 800 und 18.000 Zeilen.

Beispiele aus den Projektergebnissen:

• Chat-Interface (90 Minuten, 800 Zeilen): Ein Interface für lokale LLMs mit History-Funktion und automatischer Titel-Generierung
• Code-Analyse-Tool (3 Stunden, 5.000-6.000 Zeilen): Hierarchische Analyse von 1,2 Millionen Zeilen Java-Code auf Datei-, Paket-, Modul- und System-Ebene
• Präsentations-Tool (2 Stunden Planung + 30-60 Minuten Coding, 3.000 Zeilen): Multi-Agent-System zur Strukturierung von Präsentationen basierend auf hochgeladenen Dokumenten
• Textaufbereitungs-Tool (6-8 Stunden, 1.100 Zeilen): Dreistufige Pipeline zur Transformation von Transkripten in professionelle Texte
• Übersetzungssystem (6-7 Stunden, 12.000 Zeilen): Intelligente Dokumenten-Übersetzung mit Kontext-Management und Struktur-Erhaltung
• Migrations-Tool (20 Minuten Spezifikation + 1 Stunde Entwicklung): Content-Migrations-Unterstützung für Website-Umzüge

Diese Zeitangaben stehen in erheblichem Kontrast zu konventionellen Entwicklungsansätzen. Für das Übersetzungssystem wurden initial 4-6 Wochen veranschlagt – realisiert in 6-7 Stunden. Die Zeitersparnis bewegt sich im Bereich von Stunden zu Tagen gegenüber klassischer Entwicklung, wobei die Code-Qualität bei Entwicklung durch erfahrene Entwickler möglicherweise höher ausfallen würde. Wichtig ist jedoch: Alle entwickelten Tools erwiesen sich als nützlich für ihren jeweiligen Aufgabenzweck.

Methodische Erkenntnisse#

1. Spezifikationsqualität als wichtiger Erfolgsfaktor

Über alle Projekte hinweg erwies sich die Qualität der Spezifikation als besonders wichtiger Faktor für die Umsetzbarkeit. Je klarer funktionale Anforderungen, technische Abhängigkeiten und Architekturentscheidungen vorab herausgearbeitet wurden, desto fehlerfreier verlief die Implementierung. Die Investition in Spezifikationsqualität – typischerweise zwischen 20 und 90 Minuten – zahlte sich in deutlich reduziertem Implementierungsaufwand aus.

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

Der Entwicklungsprozess selbst verändert sich: Die Klärung von Anforderungen, Architekturentscheidungen und die kritische Bewertung von LLM-Vorschlägen werden zu wichtigen Aufgaben, während Implementierungsdetails an das LLM delegiert werden können. Dies bedeutet jedoch nicht, dass IT-Expertise überflüssig wird – im Gegenteil.

2. Aktive Steuerung gegen Overengineering hilfreich

LLMs tendieren häufig zu komplexen Lösungen, die aus ihren Trainingsdaten bekannte Code-Muster nutzen. Problematisch wird dies, wenn die vorgeschlagenen Architekturen die Fähigkeiten des LLMs zur Replizierung übersteigen – das Modell “kennt” komplexe Muster, kann sie aber nicht zuverlässig umsetzen. Das konsequente Einfordern einfacher Ansätze (KISS-Prinzip: Keep It Small and Simple) erwies sich daher als hilfreiche Methode während der Spezifikationserstellung.

Besonders wirksam war die Konzentration auf einfache Ansätze, die vollständig und klar in einer technischen Spezifikation beschrieben werden können. Je präziser die gewünschte Lösung vorab ausformuliert wird, desto weniger Raum bleibt für über-komplexe Vorschläge des LLMs oder ausufernde Heuristiken. Ohne diese aktive Steuerung schlagen LLMs häufig aufwendige Lösungen vor, die zwar theoretisch elegant erscheinen, in der Praxis aber nicht sauber funktionieren.

3. Strukturierung für LLM-Wartbarkeit

Klare Modularisierung mit Größenlimits pro Datei verbesserte sowohl die Code-Qualität als auch die Wartbarkeit durch LLMs erheblich. Bei der Entwicklung hat sich gezeigt, dass Dateien mit 1.000-1.500 Zeilen Code eine praktische Grenze für gute Wartbarkeit und Erweiterbarkeit darstellen. Die Anwendung sollte deshalb von Beginn an in eindeutige Module zerlegt werden, um alle Dateien unterhalb dieser Größe zu halten. Diese Richtwerte sind auch im weiteren Verlauf der Entwicklungen hilfreich, da LLMs dazu neigen, bestehende Code-Dateien sukzessive zu erweitern – bis zu einer Größenordnung, die sie nicht mehr sorgfältig bearbeiten können oder die den verfügbaren Kontext sprengt.

Größere Komplexität sollte daher bewusst in handhabbare Teile zerlegt werden – eine Dekomposition, die LLMs noch nicht zuverlässig selbst leisten können. Ein gutes Verständnis für Software-Architektur ist dabei hilfreich: Nicht um selbst zu codieren, aber um realistische und kontrollierbare Lösungen zu spezifizieren und angemessene Modulgrenzen zu definieren.

4. Iterative Entwicklung mit spezifischen Patterns

Erfolgreiche Projekte folgten typischerweise einem klaren Ablauf: Funktionale Spezifikation → Technische Spezifikation → Implementierung → Tests in wenigen Iterationen (2-5). Die Verwendung von “Implementation_Status”-Dokumenten, die nach jedem Schritt aktualisiert wurden, ermöglichte state-less Entwicklung und jederzeit vollständig kontextualisierten Wiedereinstieg.

Beobachtete Grenzen und Skalierung#

Die Experimente zeigen folgende Muster:

• Ohne detaillierte Spezifikation: Etwa 1.000-1.500 Zeilen Code
• Mit guter Spezifikation: Bis etwa 12.000 Zeilen Code konnten erreicht werden
• Mit durchdachter Architektur-Strukturierung: Es deutet sich an, dass bis etwa 20.000 bis 25.000 Zeilen Code erreichbar sind
• Darüber hinaus: Weitere Ansätze müssen erkundet werden. Es deutet sich an, dass mit weiteren Hilfsdokumenten auch noch größere Anwendungen möglich sein können.

Dabei wurde deutlich, dass die Projekte für heutige LLMs ab einer gewissen Größe zu umfangreich werden: Der inhaltliche Kontext, der Zusammenhang auf Dateiebene, das Zusammenspiel der eingesetzten Technologien und der grundlegende Aufbau der Anwendung müssen von der entwickelnden Person vollständig im Kopf behalten werden, wenn der Kontext der LLM überschritten wird. Hierfür muss sichergestellt werden, dass die Umsetzung und Architektur der Anwendung auch bei sukzessiver Weiterentwicklung weiterhin verstanden wird.

Neue Möglichkeiten: Das Konzept des “Casual Code”#

Die deutlich reduzierten Entwicklungszeiten eröffnen neue Anwendungsfelder – und verändern gleichzeitig den Charakter von Software-Code. Code ist nicht mehr ausschließlich ein sorgfältig erstelltes und gepflegtes Artefakt, sondern bekommt zunehmend auch transiente und ephemerare Aspekte. Code kann durchaus für eine Nutzung über nur einige Stunden, Tage oder Wochen erstellt werden – als Wegwerf-Prototyp, als experimentelles Werkzeug oder als temporäre Lösung.

Diese neue Kategorie des “Casual Code” ermöglicht:

Rapid Prototyping: Ideen lassen sich in funktionsfähige Demonstratoren überführen, die als Grundlage für fundierte Entscheidungen dienen. Das Migrations-Tool wurde zunächst als einstündiges Experiment entwickelt – und wird nun von mehreren Teams evaluiert.

Explorative Entwicklung: Die Frage “Funktioniert dieser Ansatz überhaupt?” lässt sich durch funktionierende Prototypen beantworten, nicht durch theoretische Überlegungen.

Didaktische Experimente: Die einfache Erprobung von Lehr-/Lernszenarien wird direkt möglich, ohne aufwendige Entwicklungszyklen.

Interne Werkzeuge und Speziallösungen: Entwicklung von Tools für spezifische Aufgaben, Software-Prüfungen, Implementierung von Schnittstellen zu Anwendungen, Web-Integration oder HTML-Simulatoren zur Veranschaulichung.

Darüber hinaus eröffnet sich eine neue Kategorie von Anwendungsfällen: Software-Entwicklung für alltägliche Arbeitsaufgaben, die bisher nicht mit Coding in Verbindung gebracht wurden. Die Zusammenführung verschiedener Datenquellen, die Visualisierung bestimmter Informationen oder die Automatisierung wiederkehrender Abläufe lassen sich nun in kurzer Zeit umsetzen – oft innerhalb einer Stunde. Das verändert die Dynamik der Zusammenarbeit: Ideen müssen nicht mehr theoretisch diskutiert werden, sondern können direkt in funktionierende Prototypen überführt und gemeinsam evaluiert werden. Diese unmittelbare Umsetzbarkeit ermöglicht neue Formen der iterativen Problemlösung in Teams.

Dies bedeutet: Es wird sehr viel mehr Code geben als früher – und sehr viel mehr Code mit begrenzter Lebensdauer. Diese Entwicklung wirft neue Fragen auf: Wie geht man mit der Qualitätssicherung solchen Codes um? Welche Standards gelten für Deployment und Wartung von temporärem Code? Wie dokumentiert man diese Art von Code angemessen?

Veränderte Anforderungen an Entwicklungs-Expertise#

Die Experimente zeigen: Derzeit ist ein gutes Verständnis für Software-Architektur, Technologie-Landschaften und Systemdesign für erfolgreiche LLM-gestützte Entwicklung hilfreich. 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.

Die Expertise wird dabei anders eingesetzt als in der klassischen Entwicklung und die folgenden Skills rücken dabei in den Fokus:

• Software-Architektur-Verständnis zur Spezifikation realistischer Lösungen und Definition angemessener Modulgrenzen
• Kenntnisse über Zwecke, Vorteile und Nachteile verschiedener Technologien
• Verständnis für die Komplexität verschiedener Technologien und deren Einsatzgebiete
• Sorgfältige Spezifikationsabstimmung zur Vermeidung von Unklarheiten
• Kritische Bewertung von LLM-Vorschlägen auf Angemessenheit und Umsetzbarkeit

Anwendungsfelder und Grenzen#

Die Methodik entfaltet ihre Stärken in spezifischen Bereichen:

Geeignet für:

• Rapid Prototyping und Machbarkeitsstudien
• Interne Werkzeuge und Utilities
• Analyse-Tools ohne sicherheitskritische Anforderungen
• Explorative Entwicklung und Experimente
• Didaktische Szenarien und Lernumgebungen
• Software-Prüfungen und Schnittstellenimplementierungen
• Web-Integration und HTML-Simulatoren zur Veranschaulichung

Nicht geeignet für:

• Sicherheitskritische Produktivsysteme
• Hochqualitative Produktivsoftware mit strengen Qualitätsanforderungen
• Komplexe Systeme mit umfangreichen Abhängigkeiten (ohne erheblichen manuellen Zusatzaufwand)
• Projekte, die langfristige Wartbarkeit durch verschiedene Entwickler erfordern

Die Deployment-Herausforderung#

Eine spezifische Herausforderung zeigt sich beim Deployment: Wenn mit Technologien gearbeitet wird, die nicht vollständig verstanden werden, wird die produktive Bereitstellung deutlich schwieriger. Deshalb empfiehlt es sich, in den Spezifikationen eher Technologien zu wählen, die bereits erfolgreich betrieben wurden und deren Auswirkungen, Vorteile und Nachteile im Betrieb bekannt sind.

Dieser Aspekt wird besonders relevant bei der steigenden Menge an “Casual Code”: Auch temporäre oder experimentelle Tools müssen oft irgendwo laufen – und die Frage nach angemessenen Deployment-Strategien für viele kleine, kurzlebige Anwendungen stellt sich neu.

Implikationen für IT-Organisationen#

Die beobachteten Möglichkeiten werfen auch zusätzliche Fragen für IT-Organisationen auf:

Entwicklungsprozesse: Wie integriert man rapid prototyping mit LLMs in bestehende Entwicklungsprozesse? Welche Qualitätsstandards gelten für explorativen Code?

Kompetenzentwicklung: Welche Qualifikationen werden wichtiger, welche weniger relevant? Wie qualifiziert man Fachexperten für die Entwicklung spezialisierter Tools in ihrer Domäne?

Deployment und Betrieb: Wie geht man mit der steigenden Menge an “Casual Code” um? Welche Infrastruktur-Strategien sind für viele kleine Tools angemessen?

Governance: Welche Richtlinien gelten für LLM-entwickelten Code? Wie bewertet man dessen Qualität und Sicherheit?

Fazit#

Die Experimentserie zeigt: LLM-gestützte Entwicklung ist kein Ersatz für professionelle Softwareentwicklung, aber eine Ergänzung für explorative Phasen, Rapid Prototyping und die schnelle Validierung von Tool-Ideen. Die deutlichen Zeitersparnisse – von Tagen auf Stunden – sind real und reproduzierbar, setzen aber derzeit noch spezifische methodische Kompetenzen und Architektur-Verständnis voraus.

Die Demokratisierung des Codings folgt historischen Mustern: Wie digitale Musikproduktion, Fotografie und Videobearbeitung Studios und Dunkelkammern zugänglicher machten, ohne Profis zu ersetzen, ermöglicht LLM-gestütztes Coding perspektivisch einer breiteren Nutzerschaft die Entwicklung funktionaler Tools – während professionelle Entwicklung auf komplexere, kritische Systeme fokussiert. Aktuell sind IT-Fachkräfte mit Architektur-Erfahrung noch im Vorteil, doch die Zugänglichkeit wird sich voraussichtlich weiter erhöhen.

Die Zukunft liegt nicht im Entweder-Oder, sondern in der differenzierten Nutzung verschiedener Entwicklungsansätze für verschiedene Anforderungskontexte. Die Exploration dieser Grenzen und Möglichkeiten bleibt eine wichtige Aufgabe für IT-Organisationen – ebenso wie die Entwicklung angemessener Strategien für Qualitätssicherung, Deployment und Governance des entstehenden “Casual Code”.