Ein Prompt-File liegt im Projektordner, ein Agent liest die Jira- und Confluence-Aktivität der letzten 24 Stunden und verschickt daraus eine E-Mail an einen Verteiler. Rund sechs Stunden Arbeit, vier bis fünf Durchläufe, am Ende ein Briefing, das technische und kaufmännische Leser gleichzeitig bedienen soll.
Für sich genommen ist das ein kleines Wochenendprojekt, eines von vielen in diesen Monaten. Interessant ist weniger der Agent als die Frage dahinter: Lässt sich die Arbeit so aufteilen, dass die KI ihren Prompt selbst schreibt und der Mensch nur noch entscheidet, was ein gutes Ergebnis ist? Bandan Singh beschreibt das als Delegieren statt Prompten. Damit ist keine neue Software gemeint, sondern eine andere Rollenverteilung.
Die Analogie im Text ist die von Bauherr und Architekt. Wer promptet, steht mit dem Handwerker auf der Baustelle und gibt jeden Handgriff vor: hier die Leiste, dort der Anschluss, bitte drei Zentimeter tiefer. Wer delegiert, beschreibt das Haus, die Menschen, die darin wohnen, und was es aushalten muss – und lässt sich den Bauplan zeichnen. Prüfen muss man den Plan trotzdem, nur nicht mehr jede Fuge. Genau dieser Wechsel ist der Kern.
Ein Agent für Jira und Confluence, in fünf Runden gebaut
Ausgangspunkt war eine einzige Zeile in einer Prompt-Datei: wichtige Jira-Aktivität der letzten 24 Stunden prüfen und die relevanten Änderungen per E-Mail schicken. Diese Datei liest Claude Code ein, ausgeführt wurde sie über Windows PowerShell, danach las Singh die Ausgabe und ließ ein anderes Modell die Datei neu schreiben. Vier oder fünf solcher Runden. Der Großteil der Formulierungen kam am Ende von der KI; die Entscheidung, was zählt, blieb beim Menschen.
Mit jeder Runde wurde der Prompt konkreter. Tickets wurden zu Geschäftsthemen gebündelt statt einzeln abgearbeitet, Risiken bei Kunde, Zahlung, Umsatz, Sicherheit und Compliance rückten nach vorn, Fachbegriffe mussten in Alltagsdeutsch erklärt werden, unbelegte Aussagen waren als solche zu kennzeichnen. Später kam dazu, dass ein großer Teil der relevanten Änderungen nicht in Jira steht, sondern in Confluence: Architekturseiten, Security- und Governance-Dokumente, Runbooks, Release-Pläne. Diese Quellen wurden ergänzt, reine Formatierungsänderungen ausdrücklich ausgeschlossen. Heute zieht der Agent fünf Themen aus beiden Quellen, ergänzt eine Watchlist für das Management, benennt Fortschritte und weist auf die Grenzen der Datenqualität hin.
Der erste Entwurf war sauber – und wertlos
Die erste Ausgabe war technisch einwandfrei und für den Empfänger weitgehend Rauschen. Der Agent hatte exakt das getan, was verlangt war, und genau darin lag das Problem. Er führt Anweisungen aus, er verfolgt keine Absicht. Ob das Briefing jemandem hilft, eine Entscheidung zu treffen, gehört nicht zu seinem Auftrag, also taucht es in der Ausgabe nicht auf.
Niemand hatte dem System gesagt, wer da liest und was mit dem Ergebnis passiert. Bandan Singh arbeitet in Produkt und Business, nicht in der Technik, und nutzt das Briefing als Grundlage für Entscheidungen, nicht als technisches Protokoll. Diese Information fehlte komplett. Ein Modell kann sie nicht erraten, weil sie nirgends in den Tickets steht.
Damit verschob sich der Schwerpunkt. Der größte Teil der sechs Stunden floss nicht in Technik, sondern in die Beschreibung, was ein gutes Briefing ausmacht und welche Entscheidung es stützen soll. Im Bild vom Bau: Der Plan war ordentlich gezeichnet, nur wusste der Architekt nicht, wer einziehen und was im Erdgeschoss passieren würde.
Der Judgment Loop: entscheiden, was gut ist, und es prüfen lassen
Für den Ablauf, der dabei entstanden ist, hat Singh einen Namen: Judgment Loop. Man definiert, was ein gutes Ergebnis ist, die KI entwirft daraus den Prompt, man führt ihn aus, prüft die Ausgabe, lässt die KI reparieren, was nicht funktioniert hat – und automatisiert erst, wenn man dem Ergebnis traut. Der Schritt, der gern übersprungen wird, ist der letzte. Vertrauen ist keine Einstellung, sondern das Ergebnis mehrerer Durchläufe, in denen nichts mehr schiefgegangen ist.
Bandan Singh beschreibt sich selbst als irgendwo zwischen „läuft“ und „dem kann ich trauen“. Eine ehrliche Position, und wahrscheinlich die realistischste in diesem Feld. Ein KI-Agent, der das Prompting selbst übernimmt, wird nicht besser, weil man ihn freigibt, sondern weil man die Fälle kennt, in denen er falsch liegt.
Was den Loop von normalem Prompt Engineering unterscheidet, ist die Ebene. Beim klassischen Prompten formuliert man eine Anweisung und schleift sie so lange, bis die Ausgabe passt. Hier formuliert man die Anforderung an das Ergebnis, und die Anweisung selbst schreibt die KI. Erst dadurch wird Prompting mit KI zu einer Entlastung – nicht weil weniger gedacht wird, sondern weil anders.
Die wichtigste Zeile im Prompt: keine erfundenen Fakten
Im fertigen Prompt steht eine Regel, die wichtiger ist als alle Formatvorgaben: Wenn Kundenwirkung, Zuständigkeit, Freigabestatus oder Deployment-Stand nicht belegbar sind, muss der Agent das sagen. Sie existiert wegen einer konkreten Angewohnheit. Das Modell liest ein einzelnes Ticket und zieht einen Schluss. Hochkritisch, heißt es dann. Vielleicht stimmt es, vielleicht auch nicht. Der weitere Geschäftskontext fehlt, und der Ton bleibt trotzdem souverän.
Ein Bericht, der Unsicherheit verschweigt, ist im Management gefährlicher als einer mit Lücken. Deshalb ist diese Regel keine Vorsichtsmaßnahme am Rand, sondern Teil der Qualitätsdefinition. Sie gehört zu dem, was der Mensch vorgibt und die KI nicht selbst erfinden kann – und sie ist der beste Beleg dafür, dass Delegieren nicht heißt, das Urteil abzugeben.
Die Prompt Tax und warum Prompt-Bibliotheken selten halten
Für den wiederkehrenden Aufwand hat Singh ebenfalls einen Begriff: Prompt Tax. Gemeint ist die Zeit, die man damit verbringt, dieselbe Anweisung neu zu formulieren, um auszugleichen, was die KI über die eigene Aufgabe nicht weiß. Beim PRD-Review fällt sie an, beim Weekly Update, bei der Wettbewerbsanalyse. Jedes Mal wird das Framework neu getippt, jedes Mal zahlt man denselben Betrag.
Der Ausweg ist unspektakulär: Kontext einmal liefern. Zweck, Publikum, die Entscheidung, die das Ergebnis stützen soll, das eigene Framework, das Format, dazu ein gutes und ein schlechtes Beispiel. Aus diesem Material lässt man die KI einen arbeitsfähigen Prompt bauen, prüft ihn einmal und verwendet ihn wieder. Der Aufwand sinkt damit deutlich, ohne dass Qualität verloren geht.
Das erklärt auch, warum Prompt-Bibliotheken bei vielen nie hängen geblieben sind. Eine Sammlung fertiger Prompts ist fremder Kontext. Sie kennt weder das Publikum noch die eigene Definition von Qualität, und sie kennt die Entscheidung nicht, um die es geht. Ein Rezeptbuch hilft beim Kochen, aber es weiß nicht, wer am Tisch sitzt.
Was die Studien sagen – und womit du anfängst
Bandan Singh hat sich nicht auf seine eigene Erfahrung verlassen wollen und die Forschung durchgesehen. Im APE-Paper von 2022 (Zhou et al.) schnitten von einem Modell geschriebene Instruktionen in 19 von 24 Aufgaben gleich gut oder besser ab als menschlich geschriebene. VMware-Forscher fanden, dass KI-optimierte Prompts in fast allen getesteten Fällen mindestens so gut waren wie handgeschriebene. Eine Studie von 2025 kam zu dem Ergebnis, dass LLM-Prompts näher an menschlichen Bewertungen lagen und weniger streuten als die Prompts von 15 menschlichen Experten. Es gibt außerdem Hinweise, dass Persona-Zeilen wie „handle als Experte“ die faktische Genauigkeit senken können – unangenehm für alle, die jeden Prompt so beginnen.
Alle diese Arbeiten betreffen Forschungsaufgaben, nicht die eigene Produktentscheidung. Sie taugen als Richtung, nicht als Beweis. Wer daraus ableitet, Prompten sei erledigt, hat den Punkt verfehlt. Wer daraus ableitet, dass die Formulierung nicht mehr die Hauptarbeit ist, liegt näher dran.
Der pragmatische Vorschlag des Autors lässt sich an einem Abend umsetzen. Nimm eine Aufgabe, die du jede Woche wiederholst. Sag der KI, für wen die Ausgabe gedacht ist und was daran gut aussieht, und lass sie den Prompt schreiben. Fordere sie ausdrücklich auf, dich zu befragen, wo ihr Kontext fehlt. Den ersten Durchlauf liest du mit Misstrauen, so wie du einen Bauplan prüfst, bevor du unterschreibst – nicht weil der Architekt schlecht wäre, sondern weil die Abnahme deine Aufgabe bleibt.
Der Gewinn liegt nicht darin, dass weniger Arbeit übrig bleibt, sondern dass sich die Art der Arbeit verschiebt. Formulieren ist nicht mehr die Hauptarbeit, entscheiden schon. Wer KI-Aufgaben delegieren will, muss vor allem eines klar sagen können: was für ihn ein gutes Ergebnis ist. Abgeben lassen sich die Beschreibung des Hauses, der Bauplan, die Ausführung. Die Abnahme nicht.
Quelle: productify.substack.com
