Spezifikation als Schlüssel: Ein Experiment zur LLM-gestützten Entwicklung eines Text-Stil-Editors#

Teil einer Serie über methodische Erkenntnisse aus LLM-gestützten Entwicklungsprojekten

Ausgangslage und Motivation#

Im Rahmen einer fortlaufenden Exploration von LLM-gestütztem Coding entstand ein Experiment mit der Frage: Wie lässt sich Textstil-Transformation anders umsetzen als über komplexe Stilprofile? Ein Vorgängerprojekt hatte einen profilbasierten Ansatz verfolgt, bei dem Stilmerkmale aus Referenztexten extrahiert und auf neue Texte angewendet wurden. Dieser Ansatz funktionierte, war aber komplex und bot wenig direkte Kontrolle über einzelne Stilparameter.

Das neue Experiment verfolgte einen anderen Weg: Statt Stile zu analysieren und zu kopieren, sollten Nutzer gewünschte Stilmerkmale über Schieberegler direkt einstellen können. Das Ziel war nicht primär ein fertiges Produkt, sondern das Ausloten eines alternativen Konzepts und die Weiterentwicklung der eigenen LLM-Coding-Methodik.

Was das Tool macht#

Der Text-Stil-Editor ist eine Webanwendung, die Texte in verschiedene Sprachstile transformiert. Das Konzept basiert auf zwei Schritten: Zunächst kann ein Eingabetext optional neutralisiert werden, um stilistische Eigenheiten zu entfernen. Anschließend werden über 34 Regler in sieben Kategorien die gewünschten Stilmerkmale eingestellt – von Formalität und Emotionalität über Klarheit bis hin zu kreativen Elementen wie Ironie oder Poetik.

Die Regler funktionieren nach drei Typen: Polare Regler spannen ein Spektrum auf (etwa förmlich bis informell), Intensitätsregler steuern die Ausprägung eines Merkmals (etwa Ironie von 0 bis 10), und Stufenregler bieten diskrete Optionen (etwa Sprachniveau A1 bis C2). Für den schnellen Einstieg stehen 23 Presets zur Verfügung, die vordefinierte Regler-Kombinationen für typische Anwendungsfälle bereitstellen.

Der Entwicklungsprozess#

Die Entwicklung folgte einem zweiphasigen Ansatz: Zunächst eine ausführliche Spezifikationsphase im Dialog mit verschiedenen LLMs, anschließend die Code-Generierung in einem Durchgang.

Die Spezifikation umfasste etwa 1.400 Zeilen und 50.000 Zeichen – nahezu so umfangreich wie der resultierende Code selbst. In dieser Phase wurden Ziele, funktionale Anforderungen, UI-Konzept und technische Details im Dialog mit dem LLM erarbeitet. Erst nach Abschluss dieser Spezifikation wurde der Code generiert.

Die gesamte Entwicklung dauerte etwa zwei Stunden: eine Stunde für die Spezifikation, der Rest für Implementierung, Deployment und spätere Erweiterungen. Das Projekt wurde an einem Tag nebenher durchgeführt und umfasste drei Haupt-Iterationen: die initiale Entwicklung, eine Anpassung der Intensitätsstufen nach ersten Tests, sowie die Ergänzung von History-Funktion und Einstellungs-Export.

Methodische Erkenntnisse#

Die zentrale Erkenntnis dieses Experiments: Die Qualität der Spezifikation bestimmt die Qualität des generierten Codes. Eine präzise, umfassende Spezifikation ermöglicht die Code-Generierung in einem Durchgang, während ein vages “baue mir ein Tool für X” zu iterativen Korrekturschleifen führt.

Die Intensitätsstufen der Regler (leicht, moderat, deutlich, stark, extrem) entstanden nicht in der initialen Spezifikation, sondern durch Tests. Die ersten generierten Prompts setzten die Stilmerkmale nicht deutlich genug um. Die Lösung wurde erneut im Dialog mit dem LLM erarbeitet – das Problemverständnis kam vom Entwickler, die technische Lösung aus der Zusammenarbeit.

Ein weiterer Aspekt: Die bewusst flache Architektur des neuen Tools (sechs Python-Module statt verschachtelter Struktur) war eine direkte Konsequenz aus Erfahrungen mit dem komplexeren Vorgänger. Weniger Abstraktion bedeutete hier schnellere Entwicklung bei vergleichbarer Funktionalität.

Aktueller Stand#

Das Tool wird derzeit von mehreren Personen mit unterschiedlichen Perspektiven evaluiert. Erste Erkenntnisse zeigen, dass es auch für feinere Stilanpassungen gut funktioniert, nicht nur für drastische Transformationen. Für einen Produktiveinsatz wäre allerdings eine Vereinfachung der UI nötig – 34 Regler sind für durchschnittliche Nutzer zu komplex.

Vergleich zum Vorgängerprojekt#

Der Vorgänger verfolgte einen profilbasierten Ansatz: Stilmerkmale wurden aus Referenztexten extrahiert – etwa aus Texten von Goethe oder Steve Jobs – und als JSON-Profile mit detaillierten linguistischen Metriken gespeichert. Satzlänge, Passiv-Anteil, Hedging-Level, Konnektoren-Häufigkeiten wurden analysiert und quantifiziert.

Dieser Ansatz war technisch interessant, hatte aber praktische Einschränkungen: Die extrahierten Profile waren komplex und für Nutzer schwer nachvollziehbar. Man sah zwar, dass ein Profil “68% Nominalstil” oder “28,4 Wörter durchschnittliche Satzlänge” vorsah, aber die direkte Kontrolle fehlte. Das neue Tool adressiert genau diesen Punkt: Nutzer entscheiden selbst, wie förmlich, wie emotional, wie komplex ihr Text werden soll.

Bemerkenswert ist, dass beide Tools trotz unterschiedlicher Konzepte ähnliche Codegrößen haben (Vorgänger: ~2.250 Zeilen, neues Tool: ~2.000 Zeilen). Der Vorgänger analysiert und synthetisiert, das neue Tool nur synthetisiert – dennoch war aktives Gegensteuern gegen Overengineering durch das LLM nötig.

Fazit#

Das Experiment bestätigt eine Beobachtung aus früheren Projekten: Mit zunehmender Erfahrung werden die Spezifikationen länger und präziser. Das Verhältnis von Spezifikationsaufwand zu Implementierungsaufwand verschiebt sich. Die eigentliche Entwicklungsarbeit findet zunehmend in der Konzeptionsphase statt – die Code-Generierung wird zum Ausführungsschritt einer bereits durchdachten Lösung.

Ein weiterer Aspekt verdient Beachtung: Der Dialog mit dem LLM ist nicht nur für die Implementierung nützlich, sondern bereits für die Erarbeitung der Spezifikation selbst. Das LLM fungiert als Diskussionspartner, der Konzepte hinterfragt, Alternativen vorschlägt und bei der Präzisierung hilft. Die resultierende Spezifikation ist umfassender und konsistenter als sie in reiner Eigenarbeit vermutlich gewesen wäre.

Für die Praxis bedeutet das: Die Rolle des Entwicklers verschiebt sich von der Implementierung zur Konzeption, von der Programmierung zur präzisen Anforderungsdefinition. Wer LLM-gestützt entwickelt, sollte den größten Teil der Zeit in die Spezifikation investieren – nicht in die Korrektur von generiertem Code.

Metriken: ~2.000 Zeilen Code, ~500 Zeilen JSON-Konfiguration, ~1.400 Zeilen Spezifikation, ~2 Stunden Entwicklungszeit, 3 Iterationen