Alle zwei Stunden erstellt Codex E-Mail-Entwürfe, die ich überprüfen kann.
Die meisten Entwürfe sind gut. Trotzdem ändere ich sie noch.
Ich füge vielleicht eine Entscheidung aus einem älteren Thread oder einem persönlichen Gespräch hinzu, mache den Ton sanfter, weil ich den Absender kenne, oder entferne eine Zusage, die ich noch nicht machen möchte. Der Entwurf kann gut geschrieben sein und trotzdem generisch wirken. Dieses generische Gefühl wird oft als "KI-Schrott" bezeichnet, aber in Fällen wie diesem liegt das Problem nicht an der Intelligenz. Es fehlt der Kontext.
Niemand hat etwas falsch gemacht. Codex arbeitete mit den Informationen, die es hatte, während meine Änderungen den Kontext lieferten, den es nicht hatte. Interessant ist, dass diese Änderungen selbst auch Kontext enthalten. Sie zeigen, was in dieser Situation wichtig war: was ich behalten, was ich geändert, was ich abgelehnt und was ich nicht zu senden bereit war.
Die meisten Automatisierungen bewahren diesen Kontext nicht. Die nächste Ausführung beginnt wieder mit demselben unvollständigen Bild.
Ich finde es hilfreich, Kontext in zwei Kategorien zu denken.
Erstens gibt es den Kontext, der vor der Arbeit benötigt wird: Historie, Fakten, Einschränkungen, Beziehungen und frühere Entscheidungen.
Zweitens gibt es den Kontext, der nach der Arbeit sichtbar wird: was eine Person während der Überprüfung behält, ändert, ablehnt, sendet oder als ausstehend markiert.
Das ergibt zwei Schleifen. Die innere Schleife bringt den richtigen Kontext zur Aufgabe und erstellt einen Entwurf. Die äußere Schleife lernt aus der Überprüfung und macht diesen Kontext beim nächsten Durchlauf verfügbar.
Die innere Schleife bringt Kontext in die Arbeit
Bei E-Mails entscheidet die innere Schleife, ob eine Nachricht eine Antwort benötigt, findet relevanten Kontext, erstellt einen Antwortentwurf, überprüft dessen Aussagen und erstellt einen Entwurf zur Überprüfung.
Der Workflow kann in einem in Code geschriebenen Workflow oder mit einem Workflow-Builder festgelegt werden: Nachrichten abrufen, Rauschen herausfiltern, klassifizieren, entwerfen und das Ergebnis überprüfen. Oder Codex kann anhand eines einfachen Prompts wie „Erstelle jeden Morgen um 9 Uhr Entwürfe für E-Mails, die ich beantworten muss“ selbstständig die nächsten Schritte festlegen, neue Threads untersuchen, relevante Historie wiederherstellen, fehlende Informationen recherchieren, Antworten vorbereiten und Unklarheiten aufdecken.
Beide Ansätze können funktionieren. Wichtig ist, dass das Abrufen von Informationen Teil des Schreibprozesses ist.
Eine Antwort kann von einer ähnlichen E-Mail, einer sechs Monate alten Entscheidung, dem aktuellen Status in einem Projekt-Tracker oder einer Tatsache aus einer genehmigten Quelle abhängen. Codex kann diesen Kontext sammeln oder einen Unteragenten bitten, eine bestimmte Frage zu recherchieren. Das Ziel ist nicht, alles abzurufen, sondern die kleinste Menge an Informationen zu finden, die die Antwort genau und spezifisch macht.
Ich halte die Aktion umkehrbar: Entwurf erstellen, niemals absenden. Vor meiner Bearbeitung speichert die innere Schleife den vorgeschlagenen Antwortentwurf, seine Quellen und die Versionen seines Prompts und der Schreibanleitung. Ohne diese Aufzeichnung ist die Überprüfung eine Anekdote. Mit ihr wird die Überprüfung zum Beleg.
Die äußere Schleife gewinnt Kontext aus der Überprüfung zurück
Die äußere Schleife beginnt, nachdem ich den Entwurf überprüft habe. Wurde er unverändert gesendet, bearbeitet und gesendet, gelöscht oder als ausstehend markiert?
Diese Ergebnisse bedeuten unterschiedliche Dinge. Ein unverändertes Senden deutet darauf hin, dass der Entwurf funktioniert hat. Ein bearbeitetes Senden ergibt ein Vorher-Nachher-Paar. Ein gelöschter Entwurf ist schwerer zu deuten: Vielleicht war er falsch, oder vielleicht war keine Antwort nötig. Ein ausstehender Entwurf sagt wenig aus.
Selbst die gesendete E-Mail zeichnet nur auf, was ich akzeptiert habe, nicht, ob die Antwort funktioniert hat. Das eigentliche Ergebnis zeigt sich vielleicht in der Antwort oder der darauffolgenden Arbeit. Trotzdem fügt die Überprüfung Belege hinzu, die zum Zeitpunkt der Erstellung des Entwurfs nicht verfügbar waren.
Der Unterschied zwischen dem Entwurf und der gesendeten Version ist ein Beleg. Er ist nicht automatisch eine Lehre und sollte nicht automatisch zu einer Prompt-Änderung werden.
Eine kürzere Einleitung kann eine Schreibpräferenz zeigen. Eine hinzugefügte Tatsache kann offenbaren, dass die innere Schleife an der falschen Stelle gesucht hat. Eine entfernte Zusage kann auf eine Prüfung hinweisen, die der Workflow benötigt. Ein umgeschriebener Absatz kann ein Urteil widerspiegeln, das menschlich bleiben sollte.
Ein Diff kann zeigen, was sich geändert hat. Zu verstehen, was es bedeutet, ist die eigentliche Arbeit der äußeren Schleife.
Die äußere Schleife verbessert die innere Schleife
Die äußere Schleife existiert, um den nächsten Durchlauf der inneren Schleife zu verbessern.
Sie überprüft, was sich zwischen dem Entwurf von Codex und der Version, die ich gesendet habe, geändert hat, und fragt dann: Was hätte Codex geholfen, beim ersten Mal näher dran zu sein?
Die Antwort könnte eine bessere Schreibanleitung, eine andere Quelle, ein neuer Suchschritt, eine Prüfung auf nicht unterstützte Zusagen oder eine frühere Übergabe an mich sein. Nicht jede Bearbeitung wird zur Regel. Die äußere Schleife sucht nach Mustern, schlägt die kleinste sinnvolle Änderung vor, und ich entscheide, was ich behalte.
In der Praxis würde ich diese genehmigten Lehren in einer einfachen Markdown-Datei festhalten. Die äußere Schleife schlägt Aktualisierungen dieser Datei vor; die innere Automatisierung liest sie, bevor sie die nächste E-Mail entwirft.
So verbessert die Überprüfung die innere Schleife: Was ich heute korrigiere, wird zu nützlichem Kontext für den morgigen Durchlauf.
Zwei Schleifen, zwei Takte
Die Schleifen laufen mit unterschiedlichen Geschwindigkeiten. Die innere Schleife hilft schnell, vielleicht alle zwei Stunden. Die äußere Schleife wartet auf genügend Beispiele, läuft am Ende des Tages, nach zehn überprüften Entwürfen oder wöchentlich, wenn die Beispiele spärlich sind.
Wird die äußere Schleife zu oft ausgeführt, lernt sie möglicherweise aus einem ungewöhnlichen Fall. Wird sie nie ausgeführt, verschwinden nützliche Korrekturen mit dem nächsten Entwurf.
Das gleiche Muster gilt für Präsentationen, Berichte, Briefings und Issue-Triage. In jedem Fall verbessert sich die Arbeit, wenn der Workflow beide Arten von Kontext nutzen kann: was vor dem ersten Entwurf bekannt war und was die Überprüfung danach offenbart hat.
Die Modelle sind bereits leistungsfähig. Die Chance liegt darin, Workflows zu entwickeln, die sie nicht bei jedem Durchlauf denselben Kontext neu entdecken lassen.
Die innere Schleife bringt den richtigen Kontext in die Arbeit. Die äußere Schleife bewahrt den Kontext, der durch die Arbeit offenbart wird.
