Dein KI-Workflow braucht keine besseren Prompts. Er braucht weniger KI.
Die erste Phase von KI-Arbeit ist Prompting.
Die letzte Phase ist, das Modell aus den meisten Schritten des Workflows zu entfernen.
Das klingt verkehrt herum.
Ist es nicht.
Wenn ein Workflow neu ist, ist das LLM nützlich, weil die Arbeit noch unscharf ist. Du findest gerade heraus, wie “gut” aussieht. Du probierst einen Prompt, liest das Ergebnis, passt die Beispiele an, änderst den Ton, fügst Constraints hinzu, und lässt es noch einmal laufen.
Das ist eine gute Nutzung von KI.
Aber wenn derselbe Workflow immer wieder zurückkommt und du dem Modell jedes Mal aufs Neue erklärst, was zu tun ist, baust du keine Capability auf. Du wiederholst dich, nur mit einem besseren Interface.
Der reife Workflow ist nicht der, in dem das LLM alles macht.
Der reife Workflow ist der, in dem das LLM nur den Teil übernimmt, in dem Mehrdeutigkeit nützlich ist.
Alles andere wird zu Prozess.
Prompting ist Erkundung
Prompting ist da, wo die meisten anfangen, weil es der schnellste Weg zu Feedback ist.
Du fragst:
- “Schreib diesen Artikel.”
- “Mach es weniger generisch.”
- “Übernimm meinen Stil.”
- “Füg Beispiele hinzu.”
- “Mach den Einstieg stärker.”
In dieser Phase hilft dir das Modell, die Form der Aufgabe zu verstehen.
Du kennst das Ziel noch nicht vollständig. Du erkundest. Du testest, ob die Idee überhaupt funktioniert. Du nutzt das Modell als Sparringspartner, als Drafter, als Kritiker, manchmal auch als Spiegel.
Das ist okay.
Der Fehler ist, das als finale Form zu behandeln.
Wenn du immer wieder dasselbe sagen musst, hast du keinen Workflow. Du hast eine wiederkehrende Unterhaltung.
Bessere Prompts haben trotzdem eine Obergrenze
Die nächste Stufe ist meistens besseres Prompting.
Du fügst Beispiele hinzu. Du fügst Constraints hinzu. Du definierst die Zielgruppe. Du sagst dem Modell, was es vermeiden soll. Du legst das Output-Format fest. Du schreibst einen längeren System-Prompt.
Der Output wird besser.
Eine Zeit lang fühlt sich das nach Fortschritt an.
Aber lange Prompts haben einen versteckten Failure-Mode: das Modell muss sich trotzdem alles gleichzeitig merken und ausbalancieren.
Stilregeln. Faktische Constraints. Tonalität. Zielgruppe. Plattform-Konventionen. Beispiele. Edge Cases. Verbotene Phrasen. Review-Kriterien.
Alles landet in einem einzigen großen Anweisungsblock.
Der Prompt wird zu einem Berg von Erwartungen, und das Modell ist immer noch dasjenige, das im Moment entscheidet, welche Erwartungen wichtig sind.
Das ist fragil.
Irgendwann hört “den Prompt besser machen” auf, der richtige Schritt zu sein.
Skills sind Wiederholung
Die nächste Stufe ist, wiederholtes Prompting in einen Skill zu verwandeln.
Ein Skill verpackt Kontext und Prozess:
- welche Dateien oder Quellen gelesen werden müssen
- welche Beispiele zählen
- welche Tonalität verwendet wird
- welche Skripte laufen müssen
- welches Output-Format erwartet wird
- welche Review-Kriterien greifen
- welcher Fallback-Pfad gilt, wenn etwas bricht
Das ist eine echte Verbesserung.
Der Workflow wird portabel. Du erklärst nicht mehr alles von Null. Das Modell bekommt schneller den richtigen Kontext. Du verlässt dich nicht mehr auf das, was zufällig im aktuellen Chat-Thread steht.
Für viele KI-Workflows ist das der erste ernsthafte Produktivitätssprung.
Aber Skills haben ihren eigenen Failure-Mode.
Sie können zu groß werden.
Wenn Skills zu Prompt-Monstern werden
Ein Skill kann als sauberer, wiederverwendbarer Prozess starten und sich langsam in einen weiteren Riesen-Prompt verwandeln.
Mehr Anweisungen.
Mehr Ausnahmen.
Mehr “mach das immer”.
Mehr “mach das nie”.
Mehr Beispiele.
Mehr Skripte.
Mehr persönliche Vorlieben.
Irgendwann macht der Skill den Workflow nicht mehr verlässlich. Er gibt dem Modell nur noch mehr Dinge zu interpretieren.
Das Modell muss immer noch entscheiden, was zählt.
Das Modell muss immer noch beurteilen, ob der Output gut genug ist.
Das Modell prüft immer noch seine eigenen Hausaufgaben.
Das ist der Punkt, an dem der Workflow aus dem LLM raus muss.
Nicht alles davon.
Die stabilen Teile.
Das Modell darf den Code schreiben. Es entscheidet nicht, ob er besteht.
Entwickler:innen verstehen das längst, wenn es um Code geht.
Wir fragen Entwickler:innen, ob menschlich oder KI, nicht:
“Sieht der Code richtig aus?”
Wir lassen den Formatter laufen.
Wir lassen den Linter laufen.
Wir lassen die Tests laufen.
Wir lassen den Type-Checker laufen.
Wir lassen CI laufen.
Wir nutzen Pre-Commit-Hooks.
Das Modell darf Code generieren, aber es entscheidet nicht, ob der Code besteht.
Das Gate entscheidet.
Das ist die wichtige Verschiebung.
Wenn eine Regel deterministisch geprüft werden kann, sollte sie nicht nur in einem Prompt leben.
Bei Code sind die Gates offensichtlich:
- Formatierung
- Linting
- Type Checks
- Unit Tests
- Integration Tests
- Golden Files
- JSON-Schema-Validierung
- Pre-Commit-Hooks
- CI Checks
Der Agent kann immer noch nützliche Arbeit machen. Er kann den Patch entwerfen, einen Tradeoff erklären, einen Test schreiben, einen Failure debuggen oder einen kleineren Pfad vorschlagen.
Aber der Agent sollte nicht die finale Instanz sein, die entscheidet, ob die Arbeit den Standard erfüllt.
Diese Instanz gehört außerhalb des Modells.
Das gilt auch für Content
Content fühlt sich weniger deterministisch an als Code, also bleibt mehr vom Workflow innerhalb des Prompts.
Aber dasselbe Prinzip gilt.
Wenn du eine Content-Formel gefunden hast, die funktioniert, bitte das Modell nicht einfach, sich daran zu erinnern.
Verwandle sie in Gates.
Zum Beispiel, bevor ein Artikel veröffentlicht wird:
- Passt der Titel zum tatsächlichen Versprechen des Artikels?
- Erzeugt der erste Abschnitt schnell Spannung?
- Ist die Lesergruppe klar?
- Gibt es genau ein klares Argument?
- Bringt jeder Abschnitt das Argument voran?
- Stehen generische KI-Phrasen drin, die raus müssen?
- Enthält der Artikel eine echte Beobachtung oder nur recycelten Rat?
- Gibt es eine konkrete nächste Aktion für die Lesenden?
- Passt die Tag-Strategie zum Artikel und nicht nur zum groben Thema?
Diese Checks sind nicht perfekt.
Aber sie sind besser als “mach es gut”.
“Mach es gut” ist ein Vibe.
Ein Gate ist ein Standard.
Je öfter ein Workflow zählt, desto mehr verdient er Standards, die nicht von der Laune des Modells abhängen.
Der 20-%-LLM-Workflow
Die reife Version eines KI-Workflows ist nicht:
“Das LLM macht alles.”
Sondern:
“Das LLM macht den Teil, in dem Mehrdeutigkeit nützlich ist. Das System macht den Rest.”
Das kann bedeuten, dass das Modell nur 20 % des Workflows übernimmt.
Und das ist gut so.
Bei einem Content-Workflow könnte das LLM:
- Angles vorschlagen
- mögliche Hooks vergleichen
- Abschnitte entwerfen
- unklare Absätze umschreiben
- Widersprüche finden
- Beispiele vorschlagen
Aber das System sollte erledigen:
- Quell-Notes laden
- Zielplattform auswählen
- Tag-Strategie anwenden
- Title/Promise-Match prüfen
- Verbotene Phrasen scannen
- Links verifizieren
- Formatierung erzwingen
- Publishing-Task anlegen
Bei einem Coding-Workflow könnte das LLM:
- die Codebase inspizieren
- die Änderung implementieren
- Tests schreiben
- einen Failure erklären
- einen Patch verkleinern
Aber das System sollte erledigen:
- Formatierung
- Linting
- Type Checking
- Test-Ausführung
- Schema-Validierung
- Contract Checks
- CI Gates
Das ist nicht weniger KI nutzen, weil KI schwach wäre.
Es ist weniger KI nutzen, weil der Workflow stärker wird.
Das LLM sollte der Eskalationspfad sein, nicht der Reflex
Es gibt eine einfache Regel, zu der ich immer wieder zurückkomme:
Wenn Code es prüfen kann, frag das Modell nicht, sich daran zu erinnern.
Wenn ein Skript es bereinigen kann, verbrenne keine Tokens fürs Drüber-Nachdenken.
Wenn ein Test es fangen kann, verlass dich nicht auf einen Satz im Prompt.
Das LLM sollte eingesetzt werden, wenn Mehrdeutigkeit übrig bleibt.
Es sollte nicht die erste Verteidigungslinie für Dinge sein, die längst messbar sind.
Hier verschwenden viele KI-Workflows Aufwand. Sie bitten das Modell, alles zu machen:
- die Aufgabe klassifizieren
- die Regeln merken
- den Output erzeugen
- den Output prüfen
- entscheiden, ob der Output fertig ist
- erklären, warum er fertig ist
Das ist zu viel Verantwortung in einem einzigen probabilistischen Schritt.
Teil die Arbeit auf.
Lass das Modell den mehrdeutigen Teil machen.
Lass deterministische Systeme den stabilen Teil machen.
Ein Selbsttest für deinen KI-Workflow
Wenn du wissen willst, wo dein Workflow noch unreif ist, stell diese Fragen:
- Was erkläre ich dem Modell immer wieder?
Das gehört wahrscheinlich in einen Skill.
- Worüber urteilt das Modell immer wieder selbst?
Das gehört wahrscheinlich in ein Gate.
- Welche Failures wären offensichtlich für ein Skript, einen Linter, einen Test, ein Schema oder eine Checkliste?
Das sollte nicht nur im Prompt leben.
- Wenn ich das LLM morgen rausnähme, welche Teile des Workflows wären trotzdem klar?
Das sind echter Prozess.
- Welche Teile funktionieren nur, weil das Modell großzügig ist?
Das ist Risiko.
Dieser Selbsttest ist unbequem, weil er aufzeigt, wie viel “Automatisierung” einfach Vertrauen in einen Modell-Call ist.
Aber genau das ist der Punkt.
Capability ist nicht, wie viel Arbeit du dem Modell geben kannst.
Capability ist, wie viel vom Workflow noch hält, wenn das Modell nur den Teil macht, in dem es wirklich gut ist.
Die Reifekurve
Das Muster sieht so aus:
Prompt -> Skill -> Gate -> System
Oder:
Fragen -> Verpacken -> Validieren -> Automatisieren
Wenn die Aufgabe neu ist, prompte.
Wenn die Aufgabe sich wiederholt, bau einen Skill.
Wenn der Skill funktioniert, verschiebe die stabilen Checks in Gates.
Wenn die Gates stabil sind, reduziere die Verantwortung des LLM.
Das ist der Weg vom Anfänger-Prompting zu einem 20-%-LLM-Workflow.
Es macht das Modell nicht irrelevant.
Es bringt das Modell an die richtige Stelle.
Das falsche Ziel ist Prompt-Optimierung für immer
Es gibt viele Ratschläge zu besseren Prompts.
Manche davon sind nützlich.
Aber besseres Prompting ist nicht das Ziel.
Besseres Prompting hilft dir, den Workflow zu entdecken.
Skills helfen dir, den Workflow zu wiederholen.
Gates helfen dir, dem Workflow zu vertrauen.
Systeme helfen dir, den Workflow zu skalieren.
Wenn du beim Prompting stehen bleibst, bleibt jede Aufgabe eine Verhandlung.
Wenn du bei Skills stehen bleibst, hängt jeder Prozess davon ab, dass das Modell den Skill richtig interpretiert.
Wenn du Gates dazunimmst, hat das Modell etwas, das es bestehen muss.
Das ist der Unterschied zwischen einem hilfreichen Assistenten und einem verlässlichen Workflow.
Die nützliche Frage
Die nützliche Frage ist nicht mehr:
“Wie schreibe ich einen besseren Prompt?”
Die nützliche Frage ist:
“Welcher Teil davon sollte aufhören, ein Prompt zu sein?”
Wenn es wiederholter Kontext ist, mach einen Skill draus.
Wenn es eine stabile Regel ist, mach eine Checkliste draus.
Wenn es messbar ist, mach einen Test draus.
Wenn es nicht verhandelbar ist, mach ein Gate draus.
Lass das LLM Mehrdeutigkeit erledigen.
Lass das System Standards erledigen.
Nutze Prompts, um zu entdecken.
Nutze Skills, um zu wiederholen.
Nutze Gates, um zu skalieren.
Und wenn der Workflow reif ist, lass das LLM weniger machen.
Das ist kein Downgrade.
Das ist Capability, die real wird.
Welcher Teil deines KI-Workflows sollte aufhören, ein Prompt zu sein?