Context Engineering

Context Engineering

0:00 Über kaum etwas wurde in den letzten Jahren so viel geschrieben wie über gute Prompts. Ganze Sammlungen von Zauberformeln kursieren im Netz. Bei einem Coding-Agenten stellt sich schnell heraus: Die Formulierung ist der kleinere Teil. Viel wichtiger ist, was das Modell überhaupt vor sich sieht, wenn es antwortet — welche Dateien, welche Regeln, welche Werkzeugausgaben. Genau darum geht es in diesem Modul.

0:23 Wir sehen uns an, wie Sie Kontext gezielt bereitstellen, warum er begrenzt ist, was beim Verdichten verloren geht und wie Sie aus einer fachlichen Anforderung einen Auftrag machen, den der Agent zuverlässig abarbeiten kann.

Prompt Engineering wird Context Engineering

0:36 Der Titel dieses Moduls beschreibt eine Verschiebung, die viele in der Praxis schon gemacht haben, ohne sie zu benennen. Man hört auf, an der Formulierung zu feilen, und fängt an, die Arbeitsumgebung herzurichten. Acht Kapitel führen von den vier Hebeln, die Sie überhaupt haben, über das Kontextfenster und seine Grenzen bis zur Spezifikation, die eine Session überlebt.

0:56 Als durchgehendes Beispiel dient uns ein erfundener Buchungsdienst namens kanuverleih — klein genug, um ihn zu überblicken, groß genug für echte Probleme.

Warum der Prompt allein nicht reicht

1:06 Beginnen wir mit einer ehrlichen Bestandsaufnahme. Wer aus dem Chat mit einem Sprachmodell kommt, bringt eine Gewohnheit mit: Wenn das Ergebnis nicht stimmt, formuliert man die Frage besser. Bei einem Agenten, der im Projekt arbeitet, führt diese Gewohnheit erstaunlich schnell in eine Sackgasse. Sehen wir uns an, woran das liegt — und welche vier Hebel Sie stattdessen haben, um das Ergebnis zu beeinflussen.

1:29 Context Engineering ist die Arbeit an dem, was das Modell zum Zeitpunkt der Antwort sieht: der Auftrag, die Dateien, die Projektregeln, die Ausgaben der Werkzeuge. Der Prompt ist davon nur ein Teil — und selten der entscheidende. Ein Bild dafür: Sie geben einem neuen Kollegen eine Aufgabe. Ob er sie gut löst, hängt kaum davon ab, wie elegant Sie die Aufgabe formuliert haben.

1:51 Es hängt davon ab, ob er die richtigen Unterlagen auf dem Tisch hat, die Hausregeln kennt und weiß, woran er Erfolg misst. Genau diese Unterlagen zusammenzustellen ist die eigentliche Arbeit. Vier Punkte machen den Unterschied zum Chatfenster aus. Der Agent liest selbst — aber eben nicht zwangsläufig das Richtige; er weiß ja nicht, welche Datei bei Ihnen die interessante ist.

2:14 Falscher Kontext schlägt gute Formulierung: Wenn er die falschen drei Dateien gelesen hat, hilft kein noch so schöner Satz. Projektregeln wirken dauerhaft, ein Prompt nur einmal. Und der vierte Punkt ist der, den man erst im Alltag spürt: Kontext ist begrenzt und muss bewirtschaftet werden. Es gibt ein Budget, und Sie geben es entweder für Nützliches aus oder für Ballast.

2:36 Diese Tabelle ist nach Lebensdauer sortiert, und genau darin liegt ihre Aussage. Der Auftrag im Prompt wirkt eine Runde lang. Ein Dateiverweis hält die Session über. Die Projektregeln in der AGENTS.md gelten in jeder Session, auch bei Ihren Kolleginnen. Und die Ignorierdatei formt dauerhaft den Suchraum. Die praktische Konsequenz steht in der Fußzeile: Was sich wiederholt, gehört ins Repository und nicht in den nächsten Prompt.

3:02 Wenn Sie merken, dass Sie zum dritten Mal dieselbe Anweisung tippen, haben Sie keine Prompt-Frage — Sie haben eine Projektregel gefunden, die noch nirgends steht. Diese vier Punkte beschreiben denselben Denkfehler aus vier Richtungen. Immer längere Prompts kaschieren fehlenden Projektkontext — man kompensiert mit Worten, was in Dateien gehört.

3:22 Der Agent errät Konventionen, wenn sie nirgends stehen, und seine Vermutung ist plausibel, aber eben eine Vermutung. Alles mitzugeben ist genauso schädlich wie zu wenig, weil der Auftrag im Rauschen untergeht. Und der vierte Punkt ist der unangenehmste: Was nur im Kopf des Teams existiert, sieht der Agent nie. Das gilt übrigens auch für neue Kolleginnen und Kollegen.

Anforderungen zuverlässig formulieren

3:44 Auch wenn der Prompt nicht alles ist — er ist eben auch nicht nichts. Es gibt eine Struktur, die sich bewährt hat und die Rückfragen und Fehlgriffe deutlich reduziert. Vier Angaben, mehr braucht es nicht. Sehen wir uns an, welche das sind, warum gerade die vierte so oft fehlt — und weshalb es sich lohnt, sie trotzdem hinzuschreiben, selbst wenn der Auftrag dadurch länger wird.

4:06 Ein tragfähiger Auftrag nennt vier Dinge: das Ziel statt der Tastenfolge, die nötigen Quellen, das erwartete Ergebnis samt Prüfung und die Grenzen — was unangetastet bleibt und was eine Freigabe braucht. Das erste ist ungewohnt: Wir sind es gewohnt, in Implementierungen zu denken, und beschreiben deshalb den Weg statt des Ziels. Das letzte fehlt fast immer.

4:26 Dabei ist es der Teil, der verhindert, dass der Agent auf dem Weg zu Ihrem Ziel nebenbei Dinge ändert, die niemand angefasst haben wollte. Die fünf Schritte erzählen eine einfache Geschichte. Sie benennen das Ergebnis, nicht den Weg dorthin. Sie nennen den Kontext — Dateien, Tickets, Beispiele. Sie legen fest, wie das Ergebnis aussehen und wie es geprüft werden soll. Sie ziehen Grenzen.

4:50 Und der fünfte Schritt ist der, den die meisten überspringen: Wenn etwas fehlt, fassen Sie nach, statt neu zu starten. Denn ein Neustart wirft den gesamten gesammelten Kontext weg — alle Dateien, die der Agent bereits gelesen hat, alle Erkenntnisse. Nachfassen ist fast immer der schnellere Weg. Was Sie hier sehen, sind vier Zeilen für unser Beispielprojekt: Ziel, Kontext, Ergebnis, Grenzen. Auf die konkrete Formulierung kommt es weniger an als auf die Vollständigkeit.

5:19 Achten Sie besonders auf die letzte Zeile — Preislogik und Migrationen bleiben unangetastet. Ohne diesen Satz könnte der Agent auf die Idee kommen, die Preisberechnung „gleich mit anzupassen", weil sie zur Stornofrist passt. Solche Hilfsbereitschaft ist gut gemeint und im Review teuer. Diese vier Zeilen ersetzen keine Spezifikation, aber sie verhindern die häufigsten Rückfragen.

5:43 Der erste Punkt ist der wichtigste: Ohne Erfolgskriterium erklärt sich der Agent selbst für fertig — und sein Maßstab ist nicht Ihrer. Der zweite hängt daran: Mehrere Ziele in einem Auftrag lassen sich hinterher nicht getrennt bewerten; Sie können dann nur alles annehmen oder alles verwerfen. Der dritte betrifft die fehlenden Grenzen, die zu Kollateraländerungen einladen.

6:04 Und der vierte ist der teuerste: Wer neu formuliert, statt nachzufassen, wirft den Kontext weg und fängt bei null an — oft ohne es zu merken.

Projektkontext bereitstellen

6:12 Kommen wir zu dem Hebel mit der größten Reichweite: dem Wissen, das dauerhaft im Repository steht. Es gilt in jeder Session, für alle im Team, ohne dass jemand daran denken muss. In Modul drei gehen wir tief in die Datei, um die es dabei geht. Hier klären wir zunächst das Prinzip — und warum es sich lohnt. Projektkontext ist alles, was in jeder Session gilt: der Aufbau des Repositorys, die Konventionen, die Testbefehle, die Tabus.

6:39 Codex liest dafür eine Datei namens AGENTS.md — global aus Ihrem Benutzerordner und geschichtet vom Wurzelverzeichnis des Repositorys abwärts. Denken Sie an die Einarbeitungsmappe für neue Mitarbeiter: Was steht da drin? Nicht, wie man programmiert, sondern wie es hier läuft. Welcher Befehl baut, welcher testet, welche Ordner rührt man nicht an. Genau dieses Wissen braucht der Agent auch — und zwar nicht einmal erzählt, sondern aufgeschrieben.

7:07 Vier Kategorien lohnen sich. Erstens: wie gebaut und getestet wird — und zwar der exakte Befehl, nicht die Beschreibung. Zweitens: wo welche Schicht liegt und was dort nicht hingehört. Drittens: Konventionen, die kein Linter erzwingt — denn was der Linter kann, muss nicht noch einmal aufgeschrieben werden. Und viertens: Bereiche, die ohne Rückfrage tabu sind.

7:30 Der Filter für alles andere ist einfach: Braucht der Agent es, um korrekten Code zu schreiben? Wenn nein, kostet es nur Kontext. Der Einstieg ist bequem: Mit dem init-Befehl lassen Sie sich eine erste Fassung erzeugen. Aber — und das ist der zweite Schritt — dieser Entwurf beschreibt gern, was er im Code sieht, und das nützt niemandem.

7:52 Dampfen Sie ihn auf das ein, was belegbar und nicht offensichtlich ist. Tragen Sie Test- und Baubefehle wörtlich ein. Ergänzen Sie eigene Dateien für Teilbereiche, wo nötig. Und der letzte Schritt ist eine Daueraufgabe: Immer wenn Sie sich im Prompt wiederholen, tragen Sie es nach. Modul drei vertieft das ausführlich. Diese Übung ist unspektakulär und erstaunlich wirksam. Gehen Sie Ihre eigenen Prompts durch und suchen Sie die Anweisungen, die Sie immer wieder tippen.

8:21 Gute Kandidaten sind der Testbefehl, eine Formatierungsregel und die Verzeichnisse, die tabu sind. Drei davon wandern in die Projektregeln. Und dann kommt die eigentliche Probe: Stellen Sie den nächsten Auftrag ohne diese Anweisungen. Hält der Agent sie trotzdem ein? Wenn ja, haben Sie Ihren Prompt dauerhaft verkürzt. Wenn nein, war die Regel zu vage formuliert.

Dateien, Regeln und Abhängigkeiten

8:43 Neben dem dauerhaften Projektwissen gibt es die Ebene, die Sie je Auftrag steuern: welche Dateien der Agent für genau diese Aufgabe ansehen soll — und welche er grundsätzlich gar nicht erst zu Gesicht bekommt. Beides zusammen bestimmt, wie zielgerichtet er arbeitet und wie schnell Sie zu einem brauchbaren Ergebnis kommen.

9:01 Beim zweiten Punkt gibt es außerdem ein weitverbreitetes Missverständnis, das ausdrücklich sicherheitsrelevant ist — dem widmen wir eine eigene Folie. Zusätzlich zum dauerhaften Projektkontext benennen Sie je Auftrag die relevanten Dateien. In der Kommandozeile geschieht das über das Klammeraffen-Zeichen oder einen eigenen Befehl; die IDE-Erweiterung reicht die geöffneten Dateien automatisch mit.

9:24 Der Nutzen ist unmittelbar: Der Agent muss nicht suchen, sondern liest gezielt. Das spart Zeit, spart Kontext und — das ist der unterschätzte Teil — verhindert, dass er auf dem Weg zufällig etwas findet, das ihn in eine ganz andere Richtung schickt. Vier Handgriffe, die Sie sich angewöhnen sollten. Eine Datei erwähnen, eine Datei anhängen, die offenen Änderungen zeigen, den Kontextstand prüfen.

9:47 Worauf es ankommt, steht in der Fußzeile: Verweise ersetzen die Suche des Agenten. Statt dass er durchs Repository streift und dabei Kontext verbraucht, liest er die drei Dateien, die Sie für relevant halten. Das setzt natürlich voraus, dass Sie es wissen. Wenn nicht, ist das selbst schon eine Erkenntnis — dann beginnt die Aufgabe mit einer Analyse und nicht mit einer Änderung.

10:10 Die zweite Seite der Medaille ist das Ausblenden. Eine Datei namens Punkt codexignore im Projektwurzelverzeichnis hält Dateien aus der Wahrnehmung des Agenten heraus. Die Schreibweise kennen Sie von gitignore. Und jetzt kommt der Satz, den Sie sich merken sollten: Sie ist kein Schutz. Shell-Befehle, die der Agent ausführt, lesen daran vorbei — wenn er ein Suchwerkzeug startet, findet es auch die ignorierten Dateien.

10:35 Das ist Kontexthygiene, nicht Zugriffskontrolle. Wer das verwechselt, wiegt sich in falscher Sicherheit. Der erste Punkt wiederholt die eben gemachte Warnung, weil sie so wichtig ist. Der zweite zieht die Konsequenz daraus: Geheimnisse gehören nicht ins Repository, auch nicht ignoriert. Ein Zugangsschlüssel in einer ignorierten Datei ist immer noch ein Zugangsschlüssel im Repository.

10:59 Der dritte Punkt betrifft das Maß: Zu viele Verweise verdrängen den eigentlichen Auftrag. Und der vierte ist der billigste Gewinn überhaupt — generierte Ordner, Build-Artefakte, Abhängigkeiten blähen den Kontext auf, ohne irgendetwas beizutragen.

Context Window und Compaction

11:14 Jetzt zu der Grenze, an die früher oder später jede längere Sitzung stößt. Das Kontextfenster ist endlich, und was passiert, wenn es voll ist, sollten Sie verstehen — nicht aus technischem Interesse, sondern weil Sie den Zeitpunkt mitbestimmen können und sollten. Denn beim Aufräumen geht etwas verloren, und es ist besser, wenn Sie entscheiden, wann das passiert — statt es mitten in einer kniffligen Stelle zu erleben.

11:37 Das Kontextfenster ist die Menge an Text, die das Modell gleichzeitig verarbeiten kann. Läuft es voll, verdichtet Codex den Verlauf: Werkzeugausgaben und Antworten weichen einer Zusammenfassung, Ihre eigenen Nachrichten bleiben erhalten. Ein Bild dafür ist der Schreibtisch, auf dem kein Platz mehr ist. Sie räumen auf, indem Sie sich Notizen zu den Stapeln machen und die Stapel wegpacken.

12:01 Die Notiz ist kürzer — aber sie ist eben eine Notiz. Was nicht darin steht, ist weg. Diese vier Posten erklären, warum das Fenster schneller voll ist, als man denkt. Die Grundlast steht schon vor Ihrer ersten Nachricht: Systemtext, Projektregeln, Werkzeugbeschreibungen. Dann die gelesenen Dateien — meist der größte Posten, vor allem wenn der Agent selbst gesucht hat.

12:23 Dann die Werkzeugausgaben: ein Testlauf mit ausführlicher Ausgabe kostet mehr, als man vermutet. Und schließlich der Verlauf. Die praktische Folge: Wenn Sie Projektregeln aufblähen, zahlen Sie das in jeder einzelnen Session — auch in denen, in denen die Regeln gar keine Rolle spielen. Diese vier Punkte sind der Grund, warum Verdichten kein neutraler Vorgang ist. Details aus Werkzeugausgaben gehen verloren — die konkrete Fehlermeldung, die Zeilennummer.

12:51 Die Zusammenfassung ist eine Auslegung, kein Protokoll; sie enthält, was das Modell für wichtig hielt. Nach dem Verdichten fehlt oft der Grund für frühere Entscheidungen, und der Agent widerspricht sich dann unbemerkt. Und ohne Commit ist der Zwischenstand danach schwer zu belegen. Deshalb der Rat: Committen Sie, bevor verdichtet wird. Der Commit ist das Protokoll, das bleibt.

13:15 Fünf Handgriffe, die den Umgang mit der Grenze zur Routine machen. Den Kontextstand regelmäßig ansehen. Selbst verdichten, bevor es automatisch passiert — dann bestimmen Sie den Zeitpunkt und nicht der Zufall. Vorher committen. Ein neues Thema in einem frischen Verlauf beginnen statt im alten. Und Ergebnisse in Dateien sichern, nicht im Verlauf. Der Kerngedanke: Verdichten ist Vorsorge.

13:39 Wer wartet, bis es von selbst passiert, verliert genau das, woran er gerade gearbeitet hat — nämlich das Jüngste und Detaillierteste.

Große Codebasen

13:48 In kleinen Projekten funktioniert vieles auch ohne Sorgfalt. In großen nicht. Aber — und das ist die gute Nachricht — die Ursache liegt fast nie beim Modell. Sie liegt beim Zuschnitt der Aufgabe. Sehen wir uns an, wie Sie den Ausschnitt gezielt begrenzen, statt auf ein größeres Kontextfenster zu warten — und woran Sie im Alltag erkennen, dass genau hier Ihr Problem liegt.

14:11 In großen Projekten scheitert Agentenarbeit selten am Modell, sondern am Zuschnitt: zu viel Suchraum, zu viele offene Fäden, zu lange Sessions. Die Antwort ist Begrenzung — räumlich, thematisch und zeitlich. Das ist deshalb eine gute Nachricht, weil Sie diese drei Dinge vollständig in der Hand haben. Sie müssen nicht auf ein besseres Modell warten, und Sie müssen Ihr Repository nicht verkleinern.

14:34 Sie müssen nur aufhören, dem Agenten die ganze Landschaft zu zeigen, wenn er in einem Zimmer arbeiten soll. Fünf Maßnahmen, die zusammenwirken. Den Auftrag auf ein Verzeichnis oder Modul begrenzen. Die Einstiegsdateien selbst benennen, statt suchen zu lassen. Generiertes und Testdaten ausblenden. Je Thema eine eigene Session. Und Zwischenstände committen, bevor verdichtet wird.

14:57 Die Fußzeile fasst zusammen, was in der Praxis immer wieder überrascht: Ein sauber begrenzter Ausschnitt schlägt jedes größere Kontextfenster. Mehr Platz zu haben heißt nicht, ihn füllen zu müssen — und ein Modell, das dreißig Dateien gelesen hat, antwortet nicht zwangsläufig besser als eines, das die richtigen drei kennt.

15:17 Diese Tabelle ist als Diagnosehilfe gedacht. Der Agent ändert die falsche Datei? Der Ausschnitt war nicht begrenzt. Die Antworten werden vage? Der Verlauf ist zu lang und wurde verdichtet. Konventionen werden missachtet? Die Regeln stehen nirgends. Die Fehlersuche dreht sich im Kreis? Es fehlt die Reproduktion. Die Fußzeile zieht das Fazit: Fast jedes Kontextproblem hat seine Ursache im Zuschnitt, nicht im Modell.

15:43 Bevor Sie also das nächststärkere Modell wählen, lohnt sich der Blick auf diese vier Zeilen — er ist billiger und meistens erfolgreicher. Für diese Übung brauchen Sie einen Vergleich, sonst bleibt sie abstrakt. Nehmen Sie eine Aufgabe aus Ihrem Projekt und lassen Sie sie zweimal laufen: einmal mit sauber begrenztem Ausschnitt, einmal ohne.

16:04 Beobachten Sie, welche Dateien der Agent jeweils anfasst und wie voll der Kontext am Ende ist. Der Unterschied ist bei größeren Projekten oft dramatisch — und er ist der eigentliche Lerneffekt. Danach werden Sie den Ausschnitt von selbst begrenzen, ohne dass es jemand sagen muss.

Spec Driven Development

16:21 Zum vorletzten Kapitel: Was passiert eigentlich mit all dem, was Sie im Gespräch mit dem Agenten geklärt haben? Im Chatverlauf überlebt es keine Verdichtung, keinen Sessionwechsel und schon gar keinen Personalwechsel. Es gibt einen Ort, an dem es überlebt — und der ist erstaunlich altmodisch: eine Datei im Repository, die man liest, versioniert und im Review zitiert.

16:42 Sehen wir uns an, wann sich dieser Aufwand lohnt. Beim Spec Driven Development steht eine versionierte Spezifikation im Repository und beschreibt, was gebaut werden soll. Sie ist prüfbar formuliert und überlebt die Session — anders als ein Auftrag, den nur der Verlauf kennt. Der Gedanke ist nicht neu; neu ist, dass er durch die Agentenarbeit wieder praktisch relevant wird. Denn solange ein Mensch programmiert hat, saß das Wissen in seinem Kopf.

17:09 Ein Agent hat keinen Kopf, in dem etwas sitzen bleibt. Was nicht geschrieben steht, existiert für ihn beim nächsten Mal nicht mehr. Vier Gründe. Sie überlebt Verdichtung, Sessionwechsel und Personalwechsel. Sie macht Uneinigkeit vor der Implementierung sichtbar — und das ist der billigste Zeitpunkt dafür. Sie liefert die Abnahmekriterien gleich mit. Und sie ist im Review zitierbar, was ein Chatverlauf nicht ist.

17:33 Der zweite Punkt ist in Teams der wertvollste: Wenn zwei Leute unterschiedliche Vorstellungen haben, merken sie das beim Lesen einer Seite Text — oder eben erst, wenn drei Tage Arbeit in die falsche Richtung gelaufen sind. Vier Abschnitte reichen für den Anfang: Kontext, Verhalten, Abnahme und offene Punkte. Was Sie hier sehen, ist bewusst schlank — eine Spezifikation, für die man eine Woche braucht, wird nicht geschrieben.

17:59 Der wichtigste Abschnitt ist der letzte, und das überrascht viele. „Offen" hält fest, was bewusst ungeklärt ist. Denn wenn Sie eine Lücke nicht als Lücke markieren, füllt der Agent sie selbst — plausibel, konsistent und möglicherweise völlig falsch. Eine benannte Lücke führt dagegen zu einer Rückfrage. Der erste Punkt trennt die Spezifikation vom Wunschzettel: ohne Abnahmekriterien ist sie nur eine Absichtserklärung.

18:25 Der zweite ist eine wichtige Präzisierung — erfüllte Kriterien bedeuten „richtig zur Spezifikation", nicht „richtig". Wenn die Spezifikation falsch war, ist das Ergebnis korrekt falsch. Der dritte Punkt ist eine Warnung: Veraltete Spezifikationen sind schlimmer als keine, weil sie aktiv in die Irre führen. Und der vierte ist die Verhältnismäßigkeit — für einen Einzeiler ist der Aufwand nicht gerechtfertigt.

Von der Anforderung zum Auftrag

18:50 Zum Abschluss die Übersetzungsarbeit, die im Alltag am häufigsten anfällt und am seltensten bewusst gemacht wird: von dem, was fachlich gewünscht ist, zu dem, was ein Agent tatsächlich umsetzen kann. Diese Übersetzung ist keine Formsache, sondern die eigentliche Entwicklungsarbeit — und sie fällt genauso an, wenn Sie selbst programmieren.

19:09 Nur bleibt sie dann unausgesprochen im Kopf, statt aufgeschrieben zu werden. Zwischen einer fachlichen Anforderung und einem Agentenauftrag liegt Übersetzungsarbeit. Die Anforderung nennt den Nutzen — was jemand haben möchte und warum. Der Auftrag nennt den Eingriff: welche Dateien, welche Änderung, welche Prüfung. Das ist derselbe Schritt, den Sie auch beim eigenen Programmieren machen, nur bleibt er dort meist unausgesprochen im Kopf. Hier müssen Sie ihn aufschreiben.

19:36 Das fühlt sich zunächst nach Mehrarbeit an und ist in Wahrheit die Stelle, an der die meisten Missverständnisse verschwinden. Fünf Schritte, und die Arbeitsteilung darin ist bemerkenswert. Die Anforderung fachlich verstehen und Grenzfälle klären — das ist Ihre Aufgabe, mit den Fachleuten. Die betroffenen Bereiche im Code lokalisieren — das darf der Agent übernehmen, er ist darin gut.

20:00 Das Schneiden in Teilaufträge ist wieder Ihre Entscheidung, weil hier Prioritäten und Risiken abgewogen werden. Die Reihenfolge festlegen, Abhängigkeiten zuerst. Und dann einzeln beauftragen und einzeln prüfen. Die Fußzeile hebt genau diese Grenze hervor: Schritt zwei delegierbar, Schritt drei nicht. Drei Beispiele, und in jedem passiert dasselbe.

20:23 Links steht etwas, das ein Mensch sagen würde: „Kunden sollen später stornieren können." Rechts steht etwas, das ein Agent umsetzen kann: „Stornofrist auf 48 Stunden ändern." Beachten Sie die dritte Zeile — „Die Buchung ist zu langsam" wird nicht zu „mach sie schneller", sondern zu „Engpass messen, dann Abfrage ändern".

20:43 Ohne Messung ist jede Optimierung Raterei. Und die Fußzeile ist wichtig: Rechts steht jeweils der erste von mehreren Schnitten, nicht das ganze Vorhaben. Nehmen Sie für diese Übung eine echte Anforderung aus Ihrem Backlog. Konstruierte Beispiele haben das Problem, dass sie schon vorsortiert sind — echte Anforderungen sind unklar, widersprüchlich und lassen Wichtiges weg.

21:06 Genau daran soll geübt werden. Formulieren Sie mindestens drei Teilaufträge, jeder mit Ziel, Kontext, Ergebnis und Grenzen. Wenn Sie dabei merken, dass Ihnen fachliche Antworten fehlen: Das ist kein Scheitern der Übung, das ist ihr Ergebnis. Diese Fragen hätten Sie sonst mitten in der Implementierung getroffen. Vier Punkte zum Mitnehmen. Kontext schlägt Formulierung — der Prompt ist nur einer von vier Hebeln. Was sich wiederholt, gehört ins Repository statt in den nächsten Prompt.

21:36 Das Kontextfenster ist endlich, und Verdichten kostet Details, weshalb Committen vor dem Verdichten zur Routine werden sollte. Und: Eine Spezifikation überlebt die Session, ein Chatverlauf nicht. Im nächsten Modul sehen wir uns die Datei genauer an, die den dauerhaftesten dieser Hebel trägt — die AGENTS.md und die Frage, was wirklich hineingehört.