Vier Primitive, eine bewusste Wahl

▸MODUL 1 / PRIMITIV-WAHL

Worüber wir hier reden

Bevor du einen einzigen autonomen Loop baust, triffst du eine Entscheidung, die über Erfolg oder stilles Scheitern entscheidet: Welche Form von Wiederholung braucht deine Aufgabe überhaupt? Ein Loop, also eine Aufgabe, die sich selbst wieder und wieder anstößt, bis ein Ziel erreicht ist, ist nur eines von vier Werkzeugen. Wer das überspringt, baut oft eine schwere Maschine für etwas, das ein einziger Lauf erledigt hätte.

Du kommst aus der Multi-Agent-Orchestrierung und beherrschst das Werkzeug im Terminal. Genau deshalb fangen wir nicht beim Setup an, sondern beim Denken. Diese Lektion gibt dir ein Entscheidungsraster mit vier Achsen, mit dem du jede neue Aufgabe in Sekunden dem richtigen Primitiv zuordnest. Ein Primitiv ist hier schlicht ein Grundbaustein, eine Betriebsart, in der dein Tool eine Aufgabe ausführt.

Die vier Achsen, an einer Werkstatt erklärt

Stell dir eine Werkstatt vor, in der vier verschiedene Arten von Arbeit anfallen. Jede Art will anders angefasst werden, und genau so ist es bei den Primitiven.

Das finite-objective-Primitiv ist die Arbeit mit einem klaren Ende. Du sagst, was fertig sein soll, und das Tool läuft darauf zu, bis es erreicht ist. Das ist die Holzplatte, die du sägst, bis sie die richtige Länge hat. In Claude Code ist das der /goal-Modus: ein Ziel, das angesteuert wird, nicht ein Plan, den du Schritt für Schritt diktierst.

Das Stream-Primitiv ist das Lauschen. Du wartest nicht aktiv, du wirst geweckt, wenn etwas passiert. Das ist die Türklingel, die läutet, statt dass du alle paar Minuten zur Tür gehst und nachschaust. Technisch heißt das, auf ein Event zu reagieren, das ein laufender Prozess meldet, statt ihn blind abzufragen.

Das periodische Primitiv ist die wiederkehrende Runde. Etwas läuft in einem Takt, immer wieder, solange du es laufen lässt. Das ist der Kontrollgang durch die Werkstatt, alle paar Minuten dieselbe Prüfung. Das ist der Loop im engeren Sinn, der /loop.

Das durable Primitiv ist der feste Termin. Etwas passiert verlässlich zu einer bestimmten Zeit, auch wenn niemand zuschaut und kein Terminal offen ist. Das ist der Müll, der jeden Dienstag rausgebracht wird. Technisch sind das Routines oder ein Cron-Job, also ein zeitgesteuerter Eintrag, der vom System selbst angestoßen wird.

Pro Achse ein Kriterium und ein Alltagsfall

Du musst dir die Trennung nicht merken, du musst sie entscheiden können. Für jede Achse gibt es eine einzige Frage, die dich hinführt.

Frag bei finite-objective: Gibt es einen Zustand, an dem die Arbeit nachweislich fertig ist? Beispiel: Alle Tests sind grün, dann ist Schluss. Frag bei Stream: Wartest du gerade auf ein bestimmtes Ereignis? Beispiel: Ein langer Build läuft, und du willst erst handeln, wenn er meldet, ob er bestanden hat. Frag bei periodisch: Soll dieselbe Prüfung in einem Takt wiederholt werden, bis sich ein Zustand ändert? Beispiel: Solange ein Deploy noch nicht durch ist, alle paar Minuten den Status holen. Frag bei durable: Muss das auch laufen, wenn dein Rechner zu ist? Beispiel: Jeden Morgen ein Report, ob du am Schreibtisch sitzt oder nicht.

Das Anti-Pattern: Loop-by-default

Der häufigste Fehler ist nicht, das falsche Primitiv zu wählen, sondern überhaupt eines zu wählen, wo keines nötig ist. Loop-by-default heißt: aus Gewohnheit jede Aufgabe in einen Loop zu packen, weil Loops nach Können aussehen. Oft reicht ein einzelner, gut geführter Lauf. Wenn deine Aufgabe ein klares Ende hat und kein Warten und keinen Takt braucht, dann ist sie kein Loop. Sie ist ein einzelner /goal-Lauf oder schlicht ein normaler Auftrag, den du einmal gibst.

Diese Zurückhaltung ist kein Detail am Rand. Sie ist die teuerste Lektion des ganzen Kurses, vorgezogen: Ein unnötiger Loop kostet dich Tokens, also bezahlte Modell-Nutzung, und er kann still im Kreis laufen, ohne dass du es merkst. Ein einzelner Lauf kann das nicht.

Ordne deine eigenen Aufgaben zu

Such dir drei echte Aufgaben aus deinem Alltag und ordne sie zu. Den folgenden Prompt kopierst du in dein KI-Tool, er führt dich durch die Entscheidung.

Ich entscheide, welches Primitiv drei meiner Aufgaben brauchen.
Stell mir für jede Aufgabe diese vier Fragen einzeln und nenne am
Ende das passende Primitiv mit einer kurzen Begründung:

1. Gibt es einen Zustand, an dem die Arbeit nachweislich fertig ist?
   (Wenn ja, deutet das auf finite-objective.)
2. Warte ich auf ein bestimmtes Ereignis, statt aktiv nachzufragen?
   (Wenn ja, deutet das auf Stream.)
3. Soll dieselbe Prüfung in einem Takt wiederholt werden, bis sich
   etwas ändert? (Wenn ja, deutet das auf periodisch.)
4. Muss das laufen, auch wenn mein Terminal zu ist?
   (Wenn ja, deutet das auf durable.)

Wenn keine Frage klar Ja ergibt: Es ist wahrscheinlich gar kein Loop,
sondern ein einzelner Lauf. Sag mir das ehrlich.

Wenn du am Ende für jede deiner drei Aufgaben sagen kannst, welches Primitiv sie braucht und warum, hast du das Ziel dieser Lektion erreicht. Und wenn eine davon gar kein Primitiv braucht, ist das die wertvollste Antwort.

Die ehrliche Einordnung

Die vier Primitive selbst stehen nicht im Verborgenen. Welche Modi dein Tool kennt und wie ihre Syntax aussieht, findest du in der jeweiligen Dokumentation, und die solltest du als Stand jetzt lesen, denn Tool-Oberflächen ändern sich monatlich. Was dieser Kurs liefert, ist nicht die Liste der Modi, sondern die Entscheidungslogik davor: zu wissen, wann du welches nimmst und wann du gar keines nimmst.

Dieses Raster ersetzt kein Urteil. Es gibt Mischfälle, etwa eine Aufgabe, die periodisch prüft und bei einem bestimmten Ereignis in einen finite-objective-Lauf kippt. Solche Fälle löst du, indem du die Achsen kombinierst, nicht indem du sie ignorierst. Und die Versuchung, alles zu einem Loop zu machen, bleibt bestehen, auch wenn du das Raster kennst. Die Disziplin, manchmal nichts zu bauen, ist Übungssache.

In den nächsten Lektionen von Modul 1 schauen wir uns jede Achse einzeln an, mit einem typischen Fall pro Primitiv, und danach baust du dein erstes echtes finite-objective-Ziel.