Vom Prompt zum Loop – Die vier Engineering-Disziplinen

Du hörst gerade vier Begriffe durcheinander. Prompt Engineering, Context Engineering, Harness Engineering, Loop Engineering. Jeder klingt nach der nächsten großen Sache. Jeder ist zwei Wochen später schon wieder anders belegt.

Diese Lesson gibt dir keine Begriffs-Sammlung. Sie gibt dir eine Landkarte. Die vier Begriffe sind nämlich nicht vier getrennte Themen. Sie sind vier Stationen desselben Problems.

Der Engpass ist viermal weitergewandert. Erst lag er im Wortlaut. Dann in der Information, die das Modell sieht. Dann im System, das das Modell umgibt. Jetzt im Ablauf über Zeit. Es ist immer dieselbe Aufgabe: die Fähigkeit eines Modells in verlässliches Verhalten übersetzen.

Die vier Zoomstufen auf einen Blick

Jede Stufe zoomt eine Ebene weiter raus. Vom einzelnen Satz bis zum Ablauf, der über Stunden läuft. Keine ersetzt die vorige. Sie stapeln sich.

Warum der Engpass überhaupt wandert

Die Reihenfolge ist keine Mode. Jede Stufe wurde zum Engpass, weil die vorige gelöst war. Erzähl es als Wanderung, nicht als Technik-Chronik:

1. Chat-Ära. Anweisung rein, Antwort raus. Der Hebel liegt im Wortlaut. So entsteht Prompt Engineering.
2. Anschluss an die Welt. Modelle bekommen Werkzeuge und können nachschlagen. Damit entstehen mehrstufige Abläufe. Noch keine neue Disziplin, aber die Ursache der nächsten.
3. Das Fenster wird zum Engpass. Viele Schritte produzieren Zwischenstände, Fehler, alte Outputs. Der Hebel wandert von "wie formuliere ich" zu "was sieht das Modell überhaupt". Context Engineering bekommt seinen Namen.
4. Autonomie wird zum Engpass. Agenten laufen Stunden allein und treffen hunderte Entscheidungen. Verlässlichkeit ist kein Wortlaut-Problem mehr, sondern ein Umgebungsproblem. Harness Engineering entsteht.
5. Der Ablauf wird zum Engpass. Wenn die Umgebung steht, entscheidet die Gestaltung des Zyklus: Ziel, Verifikation, Stopp. Loop Engineering bekommt seinen Namen.

Halt diese Pointe fest, wir kommen am Ende darauf zurück: Am Anfang beschreibst du eine Antwort. Am Ende beschreibst du einen Zustand von Fertig. Du formulierst heute Loops wie früher Prompts, nur eine Ebene höher.

Das Symptom. "Die Antworten sind unbrauchbar." Du tippst etwas ein, bekommst Mittelmaß zurück, änderst ein paar Wörter, hoffst auf Besseres. Das ist kein Workflow. Das ist Glücksspiel. Meistens ist die Anweisung selbst zu vage.

Prompt Engineering ist die Kunst, eine einzelne Anweisung so zu formulieren, dass das Modell die bestmögliche Antwort liefert. Das ist Grundhandwerk. Und es zahlt sich aus: Je durchdachter der Input, desto besser der Output. Nicht als Gefühl, sondern messbar.

Der Prompt-Baukasten: fünf Bausteine

Auf lernen.diy nutzen wir dafür einen festen Baukasten. Fünf Werkzeuge, die du bewusst kombinierst: Rolle, Aufgabe, Kontext, Ton, Format. Kein neuer Ansatz für diese Lesson, sondern genau das Handwerk aus dem Prompt-Baukasten, hier als erste Stufe der Landkarte.

Vage gegen konkret

Der gleiche Wunsch, zwei Welten. Der zweite Prompt füllt die fünf Bausteine: Rolle, Aufgabe, Kontext, Ton und Format. Er lässt dem Modell fast keinen Raum, dich misszuverstehen.

Status heute

Prompt Engineering bleibt Grundhandwerk. Aber es verliert als eigenständige Disziplin an Gewicht. Der Prompt ist ein Baustein im Kontext, nicht mehr der einzige Hebel. Einzelne Formulierungs-Tricks veralten schnell. Was bleibt, ist klar denken und wissen, was du eigentlich willst.

Das Symptom. "Das Modell kennt unsere Daten nicht." Oder schlimmer: Es erfindet Firmenwissen, das plausibel klingt und falsch ist. Kein Wortlaut der Welt repariert das. Die Information erreicht das Modell schlicht nicht.

Context Engineering füllt das Kontextfenster für jeden Schritt mit genau der richtigen Information. Und mit nichts anderem. Denk an ein Freelancer-Briefing: Ein vager Auftrag bringt ein vages Ergebnis zurück, egal wie höflich du fragst. Ein präzises Briefing mit den richtigen Unterlagen bringt brauchbare Arbeit.

Der Werkzeugkasten

Context Rot: wenn mehr schlechter wird

Du kennst den Effekt. Ein Chat, der nach fünfzig Nachrichten spürbar dümmer wird. Das ist Context Rot. Bei langen Abläufen sammeln sich Zwischenschritte, Fehlermeldungen und alte Outputs im Fenster. Die Aufmerksamkeit des Modells verwässert.

Das Symptom. "Der Agent macht manchmal Unsinn, und keiner merkt es." Er läuft eine Weile allein, trifft viele Entscheidungen, und irgendwo dazwischen geht etwas schief. Das ist kein Wortlaut-Problem mehr. Es ist ein Umgebungsproblem.

Harness Engineering gestaltet die Ausführungsumgebung eines Agenten. Welche Werkzeuge er hat. Woher er Wissen zieht. Wie er sich selbst prüft. Was ihn begrenzt. Und ob du siehst, was er gerade tut.

Der Werkzeugkasten

Harness zum Anfassen: die CLAUDE.md

Du brauchst dafür nicht zu programmieren. Das greifbarste Beispiel ist eine simple Regeldatei, oft CLAUDE.md genannt. Macht der Agent einen Fehler, schreibst du die Korrektur als feste Regel hinein. Der Fehler passiert kein zweites Mal. Viele machen das längst, ohne den Begriff zu kennen.

Der Prüfstand: zwei Harness, nicht einer

Hier wird es wichtig. Es gibt zwei Dinge, die "Harness" heißen. Der eine läuft mit dem Agenten und macht ihn erst zum Agenten. Der andere steht außerhalb und testet ihn. Der Agent weiß nicht, dass er auf dem Prüfstand steht.

Der Prüfstand macht Verlässlichkeit messbar. Aus "der Agent fühlt sich schlechter an" wird "die Erfolgsquote ist von 92 auf 81 Prozent gefallen" (die Zahlen hier nur als Illustration). Und er prüft das Ergebnis, nicht die Behauptung: nicht ob der Agent "Antrag ist gestellt" sagt, sondern ob der Antrag im System tatsächlich existiert.

Das Symptom. "Der Agent läuft ewig, hört zu früh auf, oder kostet zu viel." Jeder Agent läuft ohnehin in einem Loop: denken, handeln, beobachten, wiederholen. Fast niemand gestaltet diesen Loop bewusst.

Ein Bild dazu: Arbeiten mit einem Agenten ist wie die Zusammenarbeit mit einem übermotivierten, aber unkritischen Junior. Schnell, fleißig, und ohne klare Kante baut er entweder endlos weiter oder meldet stolz "fertig", während nichts stimmt.

Loop Engineering designt genau diesen Zyklus: Ziel, Trigger, Verifikation, Stoppkriterium. Der Unterschied ist der zwischen einem Agenten, der still die Arbeit erledigt, und einem, der über Nacht das Budget verbrennt und glaubt, Fortschritt zu machen.

Prompt gegen Loop-Anweisung

Beides sind Anweisungen in normaler Sprache. Der Unterschied liegt darin, was sie beschreiben. Ein Prompt beschreibt eine Antwort. Eine Loop-Anweisung beschreibt einen Zustand von Fertig, samt Absicherung des Wegs dorthin.

In der Loop-Anweisung steht keine Antwort. Es steht, woran das System selbst erkennt, dass es fertig ist. Wann es aufgibt. Und was es nicht darf.

Die vier Bausteine jeder Loop-Anweisung

1. Ziel als prüfbare Bedingung, nicht als Wunsch.
2. Verifikation: Wer oder was prüft, und woran genau.
3. Stopp: Erfolgsfall und Abbruchfall, beide explizit.
4. Regeln: Was der Agent nicht darf, die Leitplanken.

Was heißt überhaupt "fertig"?

Deterministische Ziele sind einfach. Alle Tests grün, fertig. Schwierig wird es bei Zielen wie "baue dieses Feature". Da braucht der Fertig-Zustand vorab eine Spezifikation, eine geschriebene Spec. Ohne Spec kein Loop bei unscharfen Zielen. Genau deshalb ist Loop Engineering bei Content und Strategie schwerer als bei Code, wo Tests die Spec gratis mitliefern.

Die Verifikation prüft dabei nicht "ist der Post gut", sondern messbare Stellvertreter: Blacklist, Hook-Länge, Beispiel-Pflicht. Ohne solche Checks kann ein Agent "alles super" behaupten, während das Ergebnis kaputt ist.

Wann ein Loop stoppt

Das Problem. Kaum hast du vier Begriffe sortiert, kommt der fünfte. Und der sechste. Die meisten sind Umetikettierung. Manche sind echt. Mit der Landkarte kannst du das selbst prüfen, statt jedem Hype hinterherzulaufen.

Die drei Prüffragen

1. Benennt der Begriff einen neuen Engpass? Die vier Stufen markieren je eine Station des wandernden Engpasses. Ein echter neuer Begriff müsste zeigen: Hier klemmt es jetzt, und keine der vier Stufen deckt es ab.
2. Gab es die Praxis vorher schon unter anderem Namen? Wenn ja, ist es Umetikettierung. Die Praxis kann wertvoll sein. Das Etikett ist es nicht.
3. Wer prägt den Begriff? Fundierter Praktiker-Text plus Hersteller-Artikel? Oder nur virale Timeline-Dynamik?

Fallbeispiel: Graph Engineering

Gemeint sind mehrere Agenten, jeder mit eigenem Loop, verbunden zu einem System. Parallele Zweige, Übergaben, Prüf-Knoten. Der Begriff entstand aus ein paar Tweets und war binnen 48 Stunden eine "Disziplin". Geliefert wurde in der Zeit: nichts Neues. Wir wenden die drei Fragen an.

Urteil: Etikett, keine Disziplin. Ein Graph verbindet und steuert mehrere Loops, das ist im Kern Multi-Agent-Orchestrierung mit einem Orchestrator. Enthaltensein, keine fünfte Stufe.

Die Substanz trotzdem nutzen

Dass der Begriff ein Etikett ist, heißt nicht, dass die Sache dahinter wertlos ist. Mehrere verbundene Loops statt einem einzigen sind manchmal genau richtig. Drei legitime Signale:

• Das Fenster läuft voll: Ein Agent macht zu viele Teilaufgaben, die Qualität sinkt. Aufteilen.
• Unabhängiger Review: Bei hohem Einsatz soll nicht derselbe Agent prüfen, der produziert hat. Zweites Augenpaar als eigener Knoten.
• Parallelität: Unabhängige Teilaufgaben müssen nicht nacheinander laufen.

Erinnerst du dich an die Pointe vom Anfang? Am Anfang beschreibst du eine Antwort. Am Ende beschreibst du einen Zustand von Fertig. Dieselbe Aufgabe sieht auf jeder Stufe anders aus.

Ein wöchentlicher Feedback-Report, durch alle vier Stufen

Der Prompt aus Stufe 1 verschwindet nicht. Er wird zum Baustein im Loop. Genau das ist die Landkarte: kein Ersetzen, ein Stapeln.

Drei Bilder, die bleiben

Die vier Merksätze

Selbstdiagnose: Auf welcher Stufe hängst du?