Codex SDK und Automatisierungen

Codex SDK und Automatisierungen

0:00 Bisher saß immer jemand davor. Sie haben Aufträge formuliert, Rückfragen beantwortet, Ergebnisse geprüft. In diesem Modul verlassen wir das interaktive Arbeiten: Der Agent wird zum Baustein, den Sie in Skripte, Pipelines und eigene Werkzeuge einbauen. Das eröffnet Möglichkeiten — eine Prüfung bei jedem Pull Request, ein Bericht jede Nacht.

0:21 Und es stellt neue Anforderungen: Wo niemand antwortet, muss der Auftrag vollständig sein, bevor er startet. Sehen wir uns an, was dafür nötig ist und was sich wirklich zu automatisieren lohnt.

Codex SDK und Automatisierungen

0:34 Acht Kapitel, die vom einfachen Skriptaufruf bis zum eingebetteten Agenten führen. Wir klären den Unterschied zwischen dem nicht-interaktiven Befehl und dem SDK, sehen uns an, welche Aufgaben sich überhaupt automatisieren lassen, und enden bei Einsatzfeldern, die mit klassischem Programmieren wenig zu tun haben. Der rote Faden: Ohne Aufsicht müssen Rechte, Grenzen und der Fehlerfall vorab feststehen — sonst hängt ein Lauf still oder liefert etwas, das niemand bemerkt.

Der programmierbare Agent

1:00 Beginnen wir mit der Landkarte. Es gibt drei Wege, Codex anzusprechen, und der Unterschied zwischen ihnen ist weniger technisch als organisatorisch: Es geht darum, wer die Entscheidungen trifft, die sonst Sie treffen. Sehen wir uns diese drei an und was sich ändert, sobald niemand mehr am Terminal sitzt. Die Kommandozeile ist eine Oberfläche für Menschen.

1:21 Für wiederkehrende Läufe ohne Aufsicht gibt es zwei andere Wege: den nicht-interaktiven Aufruf und das SDK, das den Agenten in eigene Anwendungen einbettet. Der Unterschied zwischen diesen beiden ist ein Unterschied in der Tiefe. Der Aufruf gibt einen Auftrag hinein und bekommt ein Ergebnis heraus. Das SDK erlaubt Ihnen, den Lauf zu begleiten — Ereignisse zu verfolgen, Regeln zu setzen, mitten im Lauf zu reagieren.

1:46 Drei Zeilen mit zunehmender Kontrolle und zunehmendem Aufwand. Interaktiv: ein Mensch am Terminal, für Entwicklung und Erkundung. Nicht-interaktiv: ein Befehl im Skript, für Pipelines und Hooks. Und das SDK: eigener Programmcode, für Werkzeuge und Dienste. Die Fußzeile ist der praktische Rat, den ich unterstreichen möchte: Der nicht-interaktive Aufruf deckt die meisten Automatisierungen bereits ab.

2:12 Zum SDK greift man, wenn dessen Grenzen erreicht sind — nicht, weil es professioneller klingt. Vier Änderungen. Es gibt niemanden, der eine Rückfrage beantwortet — ein Lauf, der fragt, hängt einfach. Rechte müssen vorab feststehen, nicht im Dialog. Fehler müssen im Ergebnis erkennbar sein, nicht im Verlauf, denn den liest niemand. Und der Umfang muss vorhersagbar begrenzt sein.

2:36 Diese vier Punkte beschreiben zusammen, warum ein Auftrag, der interaktiv gut funktioniert, automatisiert scheitern kann: Er hat sich unbemerkt auf Sie verlassen. Der erste Punkt ist der ärgerlichste, weil er lautlos passiert: Ein Lauf, der auf eine Freigabe wartet, hängt still — bis irgendwann ein Zeitlimit greift oder jemand nachsieht.

2:57 Der zweite folgt daraus: Ohne Zeitlimit blockiert ein Fehllauf die Pipeline. Der dritte ist eine Sicherheitsfrage — volle Rechte werden in Skripten schnell zur Gewohnheit, weil sie das Hängen verhindern. Und der vierte ist eine nüchterne Feststellung: Nicht jede interaktive Arbeitsweise überträgt sich.

Grundlagen des Codex SDK

3:15 Sehen wir uns nun das SDK genauer an — was es ist, was es kann und wann es sich gegenüber dem einfachen Befehl lohnt. Denn der Aufwand ist real, und er rechtfertigt sich nur, wenn Sie etwas brauchen, das der Befehl nicht liefert. Genau diese Grenze arbeiten wir heraus. Das SDK bettet den Codex-Agenten in eigene Anwendungen ein.

3:35 Es steuert den Agentenprozess, nimmt Aufträge entgegen, liefert die Ereignisse eines Laufs zurück und macht das Ergebnis in strukturierter Form zugänglich. Das Entscheidende ist das Wort „Ereignisse". Beim einfachen Befehl sehen Sie am Ende, was herausgekommen ist. Mit dem SDK sehen Sie unterwegs, was passiert — welche Datei gelesen, welcher Befehl ausgeführt wurde. Und Sie können darauf reagieren, statt nur abzuwarten.

4:02 Vier Fähigkeiten. Ereignisse eines Laufs verfolgen statt nur das Endergebnis zu sehen. Strukturierte Ergebnisse statt Text, den Sie zerlegen müssen. Regeln zur Laufzeit aus Ihrer eigenen Anwendung setzen. Und mehrere Läufe koordinieren und auswerten. Der zweite Punkt ist im Alltag der wichtigste: Freitext auszuwerten funktioniert erstaunlich lange und bricht dann an einem Sonderfall.

4:25 Eine strukturierte Ausgabe ersparen Ihnen diese Klasse von Fehlern vollständig. Vier Vergleichszeilen. Der Befehl: ein Auftrag, ein Ergebnis, Ausgabe als Text, ins Skript eingebettet, schnell eingerichtet. Das SDK: den Lauf begleiten und steuern, Ereignisse und Struktur, in eine Anwendung eingebettet, mehr Aufwand und mehr Kontrolle.

4:47 Die Fußzeile gibt die Empfehlung: Erst den Befehl versuchen. Sehr viele Automatisierungen — eine Prüfung im CI, ein nächtlicher Bericht — brauchen nichts weiter. Das SDK lohnt sich, wenn Sie den Lauf tatsächlich steuern wollen. Der erste Punkt ist eine Erwartungskorrektur: Das SDK ersetzt keine Fachlogik, es ruft einen Agenten.

5:08 Wer glaubt, damit ein Problem zu lösen, für das es einen Algorithmus gibt, macht die Sache teurer und unzuverlässiger. Der zweite ist die Kostenseite: Läufe kosten Zeit und Geld, auch die fehlgeschlagenen. Der dritte ist ein Wartungsthema — Versionen von Agent und SDK müssen zusammenpassen. Und der vierte ist wichtig für die Erwartung: Ergebnisse bleiben nicht deterministisch, nur strukturiert.

Codex aus Anwendungen ansprechen

5:34 Jetzt zur Praxis. Ein programmatischer Lauf braucht dieselben Angaben wie ein interaktiver, nur werden sie übergeben statt getippt. Sehen wir uns an, wie das konkret aussieht, welche Angaben man leicht vergisst und warum die Fehlerbehandlung hier wichtiger ist als beim interaktiven Arbeiten. Ein programmatischer Lauf braucht dieselben Angaben wie ein interaktiver: das Arbeitsverzeichnis, den Auftrag und die geltenden Rechte.

5:58 Nur werden sie nicht getippt, sondern übergeben. Das klingt trivial, wird aber gern zur Fehlerquelle. Interaktiv ist das Arbeitsverzeichnis selbstverständlich das, in dem Sie stehen. In einem Skript ist es das, in dem das Skript zufällig läuft — und das ist in einer Pipeline häufig etwas anderes, als Sie erwarten. Zwei Aufrufe, die den Unterschied zeigen. Der erste gibt einen Auftrag und liefert Text. Der zweite fordert eine strukturierte Ausgabe an.

6:26 Die Fußzeile nennt die Konsequenz: Die strukturierte Ausgabe lässt sich im Skript auswerten, der reine Text nur lesen. Wenn Ihre Automatisierung also eine Entscheidung treffen soll — Pipeline durchlassen oder blockieren —, brauchen Sie die strukturierte Form. Andernfalls raten Sie mit Textsuche in einer Ausgabe, deren Formulierung sich jederzeit ändern kann.

6:48 Fünf Schritte. Den Auftrag als festen Text mit Platzhaltern formulieren. Arbeitsverzeichnis und Rechte ausdrücklich setzen. Zeitlimit und Abbruchbedingung festlegen. Das Ergebnis strukturiert entgegennehmen. Und den Fehlerfall behandeln, nicht nur den Erfolgsfall. Die Fußzeile erklärt Schritt eins: Ein Auftrag ohne Platzhalter ist wiederholbar — und genau das macht ihn automatisierbar.

7:12 Wenn Sie den Auftrag je Lauf neu formulieren müssen, haben Sie keine Automatisierung, sondern eine umständliche Bedienung. Der erste Punkt ist eine Sicherheitswarnung: Aufträge aus Nutzereingaben zusammenzusetzen ist riskant — wer den Text beeinflusst, beeinflusst, was der Agent tut. Der zweite ist die schon erwähnte Falle mit dem Arbeitsverzeichnis. Der dritte ist der, der Ausfälle unsichtbar macht: fehlende Fehlerbehandlung.

7:38 Und der vierte ist praktisch: Parallele Läufe im selben Verzeichnis stören sich — dafür gibt es Worktrees, die wir in Modul sechs besprochen haben.

Aufgaben programmatisch übergeben

7:47 Nicht jede Aufgabe eignet sich für den unbeaufsichtigten Lauf. Es gibt ein erkennbares Profil, und wer es kennt, spart sich einige enttäuschende Versuche. Sehen wir uns an, welche Aufgaben dazu passen, welche besser interaktiv bleiben und woran man den Unterschied schon vorher erkennt. Automatisierbar sind Aufgaben mit stabiler Form und wechselnden Eingaben: eine Prüfung je Pull Request, eine Zusammenfassung je Fehlerbericht, eine Kontrolle je nächtlichem Lauf.

8:14 Das Muster ist immer dasselbe: Die Frage bleibt gleich, das Material wechselt. Sobald sich auch die Frage je Fall ändert, brauchen Sie jemanden, der sie stellt — und dann ist der interaktive Weg der richtige, nicht ein Skript mit immer mehr Sonderfällen. Vier Gegenüberstellungen. Gut automatisierbar: Prüfliste je Änderung, Changelog aus Commits, Testlücken benennen, Formalien kontrollieren.

8:38 Besser interaktiv: Entwurfsentscheidungen, Architekturumbauten, Fehlersuche ohne Reproduktion, alles mit Ermessen. Die Fußzeile nennt den gemeinsamen Nenner der rechten Spalte: Dort muss jemand das Ergebnis bewerten. Eine Entwurfsentscheidung ist nicht richtig oder falsch, sondern angemessen oder unangemessen — und diese Bewertung kann keine Automatisierung übernehmen.

9:01 Vier Voraussetzungen. Eine Form, die sich nicht je Fall ändert. Eingaben, die maschinell verfügbar sind — ein Auftrag, für den jemand erst etwas heraussuchen muss, ist nicht automatisiert. Ein Ergebnis, das maschinell prüfbar ist. Und ein Umfang, der verlässlich begrenzt bleibt. Der letzte Punkt wird gern unterschätzt: Ein Auftrag, der mal fünf und mal fünfhundert Dateien betrifft, macht Laufzeit und Kosten unvorhersehbar — und in einer Pipeline ist das ein Problem.

9:30 Das Erfolgskriterium ist praktisch: Derselbe Auftrag läuft dreimal mit unterschiedlichen Eingaben und liefert jeweils verwertbare Ergebnisse. Der Hinweis nennt den Prüfstein: Wenn Sie beim dritten Lauf eingreifen müssen, ist der Auftrag noch nicht fertig. Genau dieses Eingreifen ist das Signal — es zeigt, dass der Auftrag eine Annahme enthält, die nur beim ersten Beispiel stimmte.

9:52 Drei Läufe sind das Minimum, um so etwas überhaupt zu bemerken.

Ergebnisse weiterverarbeiten

9:57 Ein Lauf ist erst dann etwas wert, wenn sein Ergebnis irgendwo ankommt, wo es jemand sieht. Das klingt selbstverständlich und ist der Punkt, an dem Automatisierungen am häufigsten verpuffen. Sehen wir uns an, wie man Ergebnisse zustellt und warum der Fehlerfall dabei genauso viel Aufmerksamkeit braucht wie der Erfolgsfall.

10:15 Der Wert einer Automatisierung entsteht am Ausgang: als Kommentar am Pull Request, als Eintrag im Ticket, als Datei im Repository oder als Rückgabewert, der über Erfolg und Misserfolg entscheidet. Die Wahl des Ausgangs ist eine Entscheidung über Wirkung. Ein Bericht, der in einem Verzeichnis landet, das niemand öffnet, hat keinen Effekt — auch wenn der Lauf perfekt funktioniert hat.

10:37 Die Frage lautet also: Wo schaut die Person hin, die etwas ändern soll? Fünf Schritte. Die Ergebnisform vorab festlegen, nicht hinterher deuten. Strukturierte Ausgabe anfordern statt Fließtext. Das Ergebnis maschinell prüfen, bevor es weitergegeben wird. Erfolgs- und Fehlerfall unterschiedlich behandeln. Und einen Ausgang wählen, an dem tatsächlich jemand liest.

11:01 Die Fußzeile ist deutlich: Ein Ergebnis, das niemand liest, ist teurer als kein Ergebnis. Es kostet Rechenzeit, es kostet Wartung, und es erzeugt das trügerische Gefühl, dass etwas geprüft wird. Der erste Punkt beschreibt eine Zeitbombe: Freitext auswerten funktioniert, bis es das nicht mehr tut. Der zweite ist ein Qualitätsproblem — Ergebnisse ohne Prüfung weiterzugeben verbreitet Fehler in großer Zahl und mit Autorität.

11:28 Der dritte ist der häufigste Grund, warum Automatisierungen wieder abgeschaltet werden: Zu viele automatische Kommentare werden ignoriert. Und der vierte ist der gefährlichste: Ein stiller Fehlschlag sieht aus wie ein Erfolg. Der Hinweis zu dieser Übung ist der eigentliche Inhalt: Prüfen Sie ausdrücklich, wie der Fehlerfall aussieht — nicht nur der geglückte Lauf. Denn den geglückten Lauf testet jeder.

11:52 Was passiert, wenn der Agent nicht erreichbar ist, wenn das Zeitlimit greift, wenn die Ausgabe unerwartet aussieht? Wenn die Antwort lautet „dann passiert gar nichts", haben Sie eine Automatisierung gebaut, deren Ausfall niemand bemerkt. Und die ist schlechter als keine.

Engineering-Aufgaben automatisieren

12:08 Sehen wir uns jetzt an, welche Aufgaben sich in der Praxis wirklich lohnen. Es gibt ein Muster: Es sind die Routinen, die immer anfallen und unter Zeitdruck als Erstes ausfallen. Und bevor man loslegt, gibt es vier Fragen zu klären, die mit Technik nichts zu tun haben. Automatisiert werden Aufgaben, die immer anfallen, immer gleich ablaufen und unter Zeitdruck als Erstes ausfallen: Prüfungen, Zusammenfassungen, Kontrollen von Formalien.

12:34 Genau darin liegt der eigentliche Gewinn. Es geht nicht darum, dass eine Maschine schneller ist als ein Mensch. Es geht darum, dass sie am Freitagabend vor dem Release genauso gründlich arbeitet wie am Montagmorgen — und das kann kein Mensch von sich behaupten. Vier Anlässe mit ihren Ergebnissen. Ein neuer Pull Request führt zu Prüfhinweisen als Kommentar. Ein nächtlicher Lauf zu einem Bericht über Testlücken.

12:59 Vor dem Release entsteht ein Changelog aus den Commits. Und ein neues Ticket bekommt eine Einschätzung des Aufwands. Die Fußzeile nennt das Auswahlkriterium: Je unbeliebter eine Routine, desto größer der Gewinn ihrer Automatisierung. Denn unbeliebte Routinen sind genau die, die unter Druck stillschweigend entfallen. Vier Fragen, alle nichttechnisch. Wer liest das Ergebnis und entscheidet daraufhin? Was passiert, wenn der Lauf ausfällt? Wie viel Rauschen toleriert das Team?

13:28 Und was kostet der Lauf, multipliziert mit der Anzahl der Anlässe? Die letzte Frage wird regelmäßig vergessen. Ein Lauf für ein paar Cent klingt vernachlässigbar — bei zweihundert Pull Requests im Monat und mehreren Läufen je Request steht am Jahresende eine Zahl, die jemand rechtfertigen muss. Der erste Punkt ist der häufigste Fehlschlag: Automatische Hinweise ohne Empfänger erzeugen nur Lärm.

13:52 Der zweite betrifft blockierende Prüfschritte — wenn ein Prüfschritt die Pipeline anhalten kann, muss er sehr zuverlässig sein, sonst wird er umgangen. Der dritte ist die eben erwähnte Kostenfrage. Und der vierte ist der subtilste: Was automatisch läuft, wird nicht mehr hinterfragt. Nach einem halben Jahr weiß niemand mehr, warum die Prüfung eigentlich eingeführt wurde.

In eigene Werkzeuge integrieren

14:14 Jetzt zur Frage, wie man einen Agenten in ein eigenes Werkzeug einbaut, ohne dass das Werkzeug dadurch unzuverlässig wird. Denn es gibt eine Grenze zwischen dem, was ein Modell übernehmen sollte, und dem, was gewöhnlicher Code besser kann. Sehen wir uns an, wo diese Grenze verläuft. Eingebettet in eigene Werkzeuge wird der Agent zu einem Bestandteil unter anderen: Er erledigt den Teil, der Sprache und Urteil braucht, während der Rest gewohnt deterministisch bleibt.

14:42 Das ist eine wichtige Haltung. Ein Werkzeug, in dem der Agent alles macht, ist unzuverlässig und teuer. Ein Werkzeug, in dem er genau den einen Schritt macht, den man anders nicht lösen kann, ist robust — und lässt sich notfalls auch ohne ihn betreiben. Vier Leitsätze. Deterministische Schritte gehören in normalen Code — was sich programmieren lässt, sollte programmiert werden.

15:05 Der Agent übernimmt, was Sprache oder Urteil verlangt. Die Prüfung des Ergebnisses bleibt deterministisch; sonst prüft ein unzuverlässiger Teil einen anderen unzuverlässigen Teil. Und fällt der Agent aus, muss der Rest weiterlaufen. Der letzte Punkt entscheidet darüber, ob Ihr Werkzeug eine Abhängigkeit hat oder ein Risiko.

15:25 Fünf Schritte. Den Schritt isolieren, der wirklich ein Modell braucht. Ein- und Ausgabe dieses Schritts festlegen. Den Agentenlauf als austauschbaren Baustein bauen. Das Ergebnis mit gewöhnlichem Code prüfen. Und das Verhalten bei Ausfall festlegen. Die Fußzeile formuliert das Qualitätsmerkmal: Ein Werkzeug, das ohne Agent gar nichts mehr kann, ist zu eng gebaut.

15:47 Es sollte im Zweifel weniger liefern, aber nicht ausfallen — so wie eine Rechtschreibprüfung, deren Ausfall das Schreiben nicht verhindert. Der Hinweis nennt eine Reihenfolge, die sich bewährt hat: Schreiben Sie zuerst die Prüfung des Ergebnisses. Denn die Prüfung bestimmt, welche Form die Ausgabe haben muss — und wenn Sie mit der Ausgabe anfangen, bauen Sie eine Form, die sich hinterher schlecht prüfen lässt.

16:12 Das Erfolgskriterium schließt den Ausfall ausdrücklich ein: Das Werkzeug muss bei Ausfall des Bausteins ein definiertes Verhalten zeigen, nicht einfach abstürzen.

Einsatz jenseits von Coding

16:22 Zum Abschluss ein Blick über den Tellerrand. Ein Coding-Agent ist ein Werkzeug, das Code liest und Text erzeugt — und das ist deutlich mehr, als nur Programmieren. Sehen wir uns Einsatzfelder an, die man auf den ersten Blick nicht mit einem Coding-Agenten verbindet, und in denen er trotzdem gut ist. Ein Coding-Agent kann mehr als Code schreiben.

16:42 Überall dort, wo aus einem Repository etwas Verständliches entstehen soll, ist er einsetzbar — von der Migrationsanalyse bis zur Dokumentation. Der gemeinsame Nenner dieser Aufgaben: Sie erfordern, viel zu lesen und wenig zu schreiben. Das ist genau die Konstellation, in der ein Modell zuverlässig arbeitet — und zugleich die, in der Menschen ungern gründlich sind, weil das Lesen ermüdet.

17:05 Vier Felder. Dokumentation: veraltete Abschnitte finden — eine Aufgabe, die niemand freiwillig macht. Migration: betroffene Stellen erheben. Aufwand: den Umfang einer Änderung abschätzen. Und Einarbeitung: einen Rundgang durch ein Modul erzeugen. Die Fußzeile nennt das Muster: Der Agent liest viel und schreibt wenig — genau seine Stärke.

17:28 In allen vier Fällen ist das Ergebnis außerdem verhältnismäßig harmlos, denn es ändert keinen Code. Der erste Punkt ist eine wichtige Warnung: Schätzungen klingen präzise und sind es nicht. Eine Zahl mit zwei Nachkommastellen wirkt fundiert, auch wenn sie geraten ist. Der zweite ist banal und trotzdem übersehen: Erzeugte Dokumentation veraltet wie jede andere.

17:50 Der dritte betrifft Erhebungen — Vollständigkeit ist nie garantiert, und das muss man beim Weiterverwenden wissen. Und der vierte ist die Wiederholung des Kernprinzips: Ergebnisse ohne Beleg im Code sind nicht überprüfbar. Der Hinweis liefert die Technik, die alle diese Einsatzfelder brauchbar macht: Verlangen Sie Dateipfade zu jeder Aussage.

18:11 Ohne Belege haben Sie einen gut formulierten Text, dessen Richtigkeit Sie nicht überprüfen können — und der genau deshalb gefährlich ist, weil er überzeugend klingt. Mit Belegen können Sie stichprobenartig nachsehen. Suchen Sie sich für diese Übung ein Feld, das in Ihrem Umfeld tatsächlich Arbeit macht, und bewerten Sie den Nutzen ehrlich.

18:30 Vier Punkte zum Mitnehmen. Ohne Aufsicht müssen Rechte, Grenzen und der Fehlerfall vorab feststehen — sonst hängt der Lauf oder scheitert unbemerkt. Erst den nicht-interaktiven Befehl versuchen, dann das SDK. Automatisierbar ist, was stabile Form und ein maschinell prüfbares Ergebnis hat. Und ein Ergebnis, das niemand liest, ist teurer als kein Ergebnis.

18:53 Im nächsten Modul geht es um die Frage, wo ein Lauf eigentlich stattfinden sollte: lokal, im Web oder in der Cloud.