Ich beschäftige mich immer weniger damit, den perfekten Prompt zu schreiben. Natürlich versuche ich weiterhin, einen Auftrag klar zu formulieren. Aber ich glaube nicht mehr, dass bessere KI-Arbeit hauptsächlich dadurch entsteht, dass ich noch mehr Details in einen einzelnen Prompt packe. Mich beschäftigt inzwischen eine andere Frage: Wie muss der Arbeitsprozess rund um die KI aussehen? Für komplexere Aufgaben arbeite ich dafür auf ungefähr diesen Ablauf hin:
Request → Task Contract → Context Routing → Execution → Verification → Run Receipt
Das ist heute noch nicht mein vollständiger Workflow, aber das Modell, auf das ich gerade hinarbeite. Was dahintersteckt, lässt sich am besten an den einzelnen Stationen zeigen.
Request: Ein guter Prompt löst noch keinen guten Arbeitsprozess
Meine Arbeit mit KI läuft oft noch sehr klassisch: Ich beschreibe eine Aufgabe, ergänze Kontext, bekomme eine Antwort, korrigiere, ergänze weitere Informationen, ändere die Richtung. Irgendwann ist aus einem einzelnen Auftrag ein langer Gesprächsverlauf geworden. Das funktioniert, aber bei komplexeren Aufgaben entstehen dabei Probleme. Der ursprüngliche Auftrag verschwimmt, Entscheidungen aus früheren Schritten liegen irgendwo im Gespräch, neue Anforderungen kommen dazu, der Kontext wird immer größer. Und irgendwann muss nicht nur die KI rekonstruieren, was eigentlich gilt, sondern ich selbst auch. Genau das möchte ich anders organisieren.
Task Contract: etwas Verbindlicheres als ein Startprompt
Ein Gedanke, der mich gerade beschäftigt, ist eine Art Task Contract. Den habe ich in dieser Form noch nicht durchgängig umgesetzt, aber ich halte die Idee inzwischen für wichtig. Ein Auftrag sollte nicht nur aus einem ersten Prompt bestehen, der anschließend durch fünfzig weitere Nachrichten ergänzt wird. Er sollte eine klar definierte Basis bekommen: Was soll am Ende entstanden sein? Welche Ausgangslage gilt? Welche Regeln gelten? Was darf verändert werden, was nicht? Welche Ergebnisse werden erwartet? Woran erkenne ich, dass die Aufgabe abgeschlossen ist? Teile davon mache ich heute bereits – gerade bei Entwicklungsaufträgen formuliere ich Ziele, Grenzen und Tests inzwischen deutlich konkreter als früher. Was mir noch fehlt, ist eine echte verbindliche Vertragsbasis pro Auftrag, die über den gesamten Lauf hinweg bestehen bleibt.
Context Routing: weg von “alles mitgeben”
Mein früherer Reflex war häufig: Je mehr Informationen das Modell bekommt, desto besser. Das stimmt nicht automatisch. Ein Agent braucht nicht alles, was ich jemals über ein Projekt gedacht habe – er braucht die Informationen, die für den konkreten Auftrag relevant sind. Wenn ich einen Blogartikel überarbeite, braucht der Redakteur den Artikel, meinen Schreibstil und vielleicht die unmittelbar vorherigen Beiträge, nicht gleichzeitig die komplette Architektur von Verksum. Wenn ein Builder an einem bestimmten Teil einer Anwendung arbeitet, braucht er den relevanten Code, die Architekturregeln und die passenden Tests, nicht jedes Dokument, das jemals zu diesem Projekt entstanden ist. Ich denke deshalb zunehmend in Context Routing: nicht “hier ist alles, such dir das Relevante heraus”, sondern “welcher Kontext gehört zu genau diesem Auftrag?”. Auch das ist bei mir noch kein vollständig automatisiertes System, aber die Richtung ist für mich klar.
Execution: die Arbeit tatsächlich abgeben
Gerade beim Coding hat sich meine Arbeitsweise bereits verändert. Ich möchte einem Coding-Agenten nicht sagen: Öffne diese Datei, ändere diese Funktion, führe danach diesen Test aus. Wenn ich jeden einzelnen Schritt bereits selbst planen muss, bleibt die eigentliche Arbeit bei mir. Ich möchte einen Auftrag beschreiben können – das Ziel, die Grenzen, die Anforderungen – und dann soll der Agent den Weg selbst finden. Genau deshalb arbeite ich inzwischen gern mit längeren Entwicklungsaufträgen: Ich gebe das Problem hinein und erwarte am Ende nicht nur Code, sondern ein überprüfbares Ergebnis.
Verification: Je mehr Arbeit ich abgebe, desto weniger reicht mir “Fertig”
Ein Agent kann sehr überzeugend behaupten, dass etwas funktioniert – das ist kein Beweis. Bei Software möchte ich Tests sehen, bei Berechnungen brauche ich Kontrollwerte, bei Dokumenten möchte ich prüfen können, ob die Anforderungen tatsächlich eingehalten wurden. Bei einer Website kann ein Build erfolgreich durchlaufen und die erwartete Seite tatsächlich erreichbar sein. Das ist ein Punkt, den ich bereits sehr stark in meine Entwicklung eingebaut habe. Ich verlasse mich nicht darauf, dass ein Agent sagt, er sei fertig – ich möchte einen Zustand haben, den ich überprüfen kann.
Run Receipt: ein sauberer Abschluss statt eines langen Verlaufs
Wenn ein längerer Auftrag abgeschlossen ist, möchte ich nicht den kompletten Verlauf lesen müssen. Ich möchte am Ende eine kompakte Antwort auf ein paar Fragen haben: Was wurde tatsächlich gemacht? Was wurde verändert? Welche Prüfungen wurden durchgeführt? Welche Ergebnisse liegen vor? Was ist offen? Wo gibt es Unsicherheiten? Welche Artefakte sind entstanden? Auch das ist noch kein vollständig umgesetzter Bestandteil meiner Arbeitsweise, aber genau so möchte ich einen autonomen Lauf irgendwann abschließen können – nicht mit “Hat funktioniert”, sondern mit einem nachvollziehbaren Beleg dafür, was passiert ist.
Meine Rolle verschiebt sich dadurch
Das ist für mich wahrscheinlich die wichtigste Veränderung. Ich möchte weniger Zeit damit verbringen, die jeweils nächste Anweisung zu formulieren. Meine Arbeit soll stärker am Anfang und am Ende liegen: Am Anfang, was erreicht werden soll, welche Regeln gelten, welche Informationen der Auftrag braucht. Am Ende, ob das Ergebnis richtig ist, ob ich es verwenden kann, was daraus folgt. Das Dazwischen möchte ich immer stärker delegieren.
Mein Blog hat mir das gerade noch einmal sehr deutlich gezeigt
Bei meinen Blogartikeln habe ich aktuell einen einfachen Anwendungsfall: Ich bespreche den Text, ein Redakteur überarbeitet ihn, ich gebe ihn frei. Danach sollte eigentlich keine weitere Diskussion mehr notwendig sein – Markdown prüfen, Metadaten prüfen, Build ausführen, veröffentlichen. Dafür brauche ich nicht drei weitere Agenten, die miteinander diskutieren, und ich brauche auch keinen Technical Lead, solange technisch alles funktioniert. Genau daran habe ich gemerkt, dass ich in meinen bisherigen Agenten-Workflows teilweise zu viel KI eingebaut habe. Nur weil ich mehrere Agenten einsetzen kann, heißt das nicht, dass ich es auch tun sollte. Ein sauberer Arbeitsprozess kann an vielen Stellen viel einfacher sein.
Das Harness hält die Stationen zusammen
Ich benutze den Begriff Harness inzwischen immer häufiger, weil er ziemlich gut beschreibt, was rund um das Modell passieren muss. Das Modell allein löst meinen Arbeitsprozess nicht. Das Harness muss dafür sorgen, dass ein Agent den richtigen Auftrag bekommt, den richtigen Kontext erhält, die notwendigen Werkzeuge verwenden kann, definierte Grenzen einhält, Ergebnisse prüfen kann und am Ende einen nachvollziehbaren Zustand hinterlässt. Einige dieser Teile habe ich in Verksum bereits, andere fehlen noch. Vor allem eine echte Vertragsbasis pro Auftrag möchte ich deutlich sauberer einbauen.
Wahrscheinlich liegt genau darin für mich gerade der größere Fortschritt – nicht darin, den nächsten Prompt noch besser zu formulieren, sondern darin, dafür zu sorgen, dass ein guter Auftrag auch dann noch klar bleibt, wenn die eigentliche Arbeit längst begonnen hat.