LLM-gestützte Entwicklung: Textbearbeitung ohne Prompt-Dialog#
Das Tool und seine Funktionsweise#
Im Rahmen einer Experimentserie zur Exploration von LLM-gestütztem Coding wurde ein Gradio-basiertes Interface für Textbearbeitung entwickelt. Das Tool unterscheidet sich von konventionellen LLM-Interfaces durch seinen Verzicht auf dialogische Prompts: Die Nutzenden arbeiten ausschließlich mit einem Eingabe- und einem Ausgabebereich, zwischen denen kuratierte Tools (Korrigieren, Übersetzen, Zusammenfassen, Analysieren, etc.) operieren.
Die Architektur umfasst 12 vordefinierte Tools, die über Buttons aktiviert werden. Jedes Tool basiert auf einem kuratierten Prompt, der darauf optimiert ist, ausschließlich den bearbeiteten Text ohne Meta-Kommentare zurückzugeben. Nutzende können Tools mit Zusatz-Anweisungen modifizieren oder vollständig eigene Befehle formulieren. Eine History-Funktion speichert bis zu 15 Bearbeitungsschritte mit automatisch generierten Titeln, die durch separate LLM-Calls nach jeder Aktion erzeugt werden.
Experimentelles Ziel#
Das primäre Lernziel bestand darin zu evaluieren, ob Textbearbeitungs-Tools ohne explizite User-Prompts praktikabel sind. Hintergrund war die Beobachtung, dass Prompting für Alltagsaufgaben häufig als aufwendig und fehlerträchtig wahrgenommen wird. Das Tool adressiert gezielt die häufigsten Use-Cases allgemeiner Textbearbeitung und sollte klären, ob ein artefakt-zentrierter Ansatz (Eingabe-/Ausgabebereich statt Chat) für wiederkehrende Aufgaben geeignet ist.
Technische Umsetzung und Entwicklungsprozess#
Die Entwicklung folgte einem Spezifikations-erst-Prinzip: In 90 Minuten wurde eine detaillierte, 14-seitige Spezifikation durch strukturierte Interaktion mit einer LLM erstellt. Der Prozess umfasste die Beschreibung benötigter Funktionalitäten, die Diskussion von Umsetzungsoptionen und deren systematische Auswahl. Besonderer Fokus lag auf der Vermeidung von Overengineering, insbesondere bei Heuristiken.
Für dieses Projekt wurde erstmals ein “Implementation_Status”-Dokument eingeführt, das die LLM nach jedem Umsetzungsschritt aktualisierte. Dieses Artefakt ermöglicht jederzeit einen vollständigen Überblick zum Implementierungsstand und erlaubt state-less Entwicklung: Jede neue Prompt-Interaktion kann mit vollständigem Kontext beginnen.
Die Implementierung erfolgte modular nach der Spezifikation. Der finale Code umfasst etwa 2000 Zeilen, verteilt auf Anwendungslogik (800), Export-Funktionen (500) und Prompt-Definitionen (200). Die Gesamtentwicklungszeit betrug rund 3 Stunden: 90 Minuten Spezifikation, 30 Minuten Prompt-Entwicklung, 60 Minuten Implementierung, Deployment und Dokumentation. Die Spezifikation durchlief 2-3 Iterationen über zwei Tage.
Methodische Kernerkenntnisse#
Spezifikationsqualität als Erfolgsfaktor: Die Qualität der Spezifikation erwies sich als wichtig für die Umsetzbarkeit. Eine präzise Spezifikation reduziert Implementierungsiterationen erheblich.
Implementation_Status-Artefakt: Die Einführung eines systematisch gepflegten Status-Dokuments hat sich als workflow-verbesserndes Element bewährt. Es ermöglicht state-less Entwicklung und jederzeit vollständig kontextualisierte neue Prompts.
Code-Strukturierung: LLMs verwalten Code-Dateien gut, wenn diese unter 1000 Zeilen bleiben (maximal 1500 Zeilen). Klare Modularisierung erwies sich für LLM-gestütztes Coding als zentral.
Heuristiken als Ergänzung: Auch beim Einsatz von LLMs sind in Maßen eingesetzte Heuristiken hilfreich. Die Kombination aus Prompt-Engineering (für LLMs mit gutem Prompt-Following) und nachgelagertem Filtering erwies sich als effektiv zur Vermeidung von Meta-Antworten.
Prompt-Engineering-Strategie: Bei LLMs mit gutem Prompt-Following funktioniert klare Strukturierung in einzelne Aspekte gut. Bei schwächerem Prompt-Following sind präzise Fließtext-Anweisungen effektiver.
Validierung und Nutzung#
Das Tool wurde an mehrere Testpersonen weitergegeben. Initiale Rückmeldungen zu Einschränkungen konnten durch geringfügige Anpassungen (primär Prompt-Verfeinerungen) behoben werden. Die Implementierung erwies sich als robust; wesentliche strukturelle Änderungen waren nicht erforderlich.
Das Tool wird produktiv für Alltags-Aufgaben eingesetzt: Übersetzungen, Textkorrekturen, stilistische Anpassungen und sprachliche Analysen. Die Akzeptanz des prompt-freien Ansatzes bestätigte die Hypothese: Der Vorteil liegt nicht in der Vermeidung eigener Prompts (diese Möglichkeit bleibt über “Eigener Befehl” verfügbar), sondern in der Arbeit mit Eingangs- und Ausgangstexten statt dialogischer Interaktion. Das Tool eignet sich besonders für schnelle, wiederkehrende Aufgaben mit kleineren bis mittleren Textlängen.
Fazit#
Das Experiment demonstriert, dass artefakt-zentrierte Tools ohne primären Prompt-Dialog für definierte Use-Cases praktikabel und nutzerakzeptiert sind. Die methodischen Erkenntnisse – insbesondere zum Spezifikations-erst-Prinzip, zum Implementation_Status-Artefakt und zur Code-Strukturierung – könnten auf andere LLM-gestützte Entwicklungsprojekte übertragbar sein. Die kurze Entwicklungszeit von 3 Stunden bei funktionaler Robustheit illustriert das Potenzial systematisch spezifikationsgesteuerter LLM-Entwicklung.