Codex verstehen und einsetzen

Codex verstehen und einsetzen

0:00 Werkzeuge, die beim Programmieren helfen, gibt es seit Jahrzehnten. Neu ist etwas anderes: ein Werkzeug, das nicht mehr nur vorschlägt, sondern handelt. Es liest sich in ein Projekt ein, ändert Dateien, startet Tests und schaut sich das Ergebnis an. Genau das ist Codex, der Coding-Agent von OpenAI. In diesem Modul klären wir zuerst, was daran wirklich anders ist — und was davon Marketing ist.

0:24 Danach richten wir eine Umgebung ein, die funktioniert, und sehen uns an, wie Modelle, Sessions und Oberflächen zusammenspielen. Am Ende sollten Sie nicht nur Codex gestartet haben, sondern eine Vorstellung davon, wofür Sie es einsetzen — und wofür besser nicht.

Codex verstehen und einsetzen

0:41 Wir beginnen mit dem Fundament. Acht Kapitel, die aufeinander aufbauen: vom Unterschied zu klassischen Assistenten über die Installation bis zu der Frage, welche Aufgaben sich überhaupt zum Delegieren eignen. Der Anspruch ist bewusst nüchtern — kein Werkzeug macht aus schlechtem Code guten, und keine Automatik ersetzt das Urteil darüber, was gebaut werden soll.

1:01 Aber wer versteht, wie ein Agent tatsächlich arbeitet, trifft deutlich bessere Entscheidungen darüber, wann er ihn einsetzt und wann eben nicht. Genau dieses Urteil bauen wir heute auf.

Codex und klassische Assistenten

1:12 Fangen wir mit dem an, was Sie vermutlich schon kennen: der Autovervollständigung im Editor. Sie ist nützlich, sie ist verbreitet — und sie ist etwas grundsätzlich anderes als das, worüber wir hier sprechen. Der Unterschied klingt zunächst nach einer Feinheit, verändert aber die ganze Arbeitsweise: was Sie eingeben, was Sie zurückbekommen und vor allem, wie Sie das Ergebnis prüfen müssen.

1:33 Sehen wir uns deshalb genau an, wo die Grenze zwischen Vorschlagen und Handeln verläuft. Stellen Sie sich den Unterschied zwischen einem Nachschlagewerk und einem Kollegen vor. Das Nachschlagewerk antwortet, wenn Sie fragen. Der Kollege setzt sich an den Rechner, schaut sich das Projekt an, ändert etwas, lässt die Tests laufen und meldet sich mit einem Ergebnis. Codex ist der Kollege.

1:56 Er arbeitet nicht im Editorfenster einer einzelnen Datei, sondern im Projekt: Er liest die Codebasis, ändert Dateien, führt Befehle aus, liest deren Ausgabe und korrigiert sich selbst. Das ist der ganze Sprung — und zugleich der Grund, warum Sie Ihre Arbeitsweise anpassen müssen. Vier Punkte machen den Unterschied greifbar.

2:15 Der Agent sieht das Repository, nicht nur die Stelle, an der Ihr Cursor blinkt — er findet also auch die Datei, an die Sie nicht gedacht haben. Er darf handeln, Befehle ausführen, Tests starten. Er schließt die Schleife: bauen, prüfen, nachbessern, ohne dass Sie dazwischen sitzen. Und Sie selbst wechseln von der Tastatur ans Steuer. Das ist ein Gewinn, aber kein geschenkter. Wer nur schneller tippen will, wird enttäuscht sein.

2:40 Der Gewinn liegt darin, dass Sie mehr Zeit für die Entscheidungen haben, die ein Modell nicht treffen kann. Diese Gegenüberstellung hat einen roten Faden: In der linken Spalte bleiben Sie der Ausführende, in der rechten werden Sie zum Prüfenden. Das klingt bequemer, ist es aber nicht — es verschiebt nur die Anstrengung. Statt Zeilen zu tippen, lesen Sie Diffs. Statt in der Dokumentation zu suchen, formulieren Sie Aufträge.

3:06 Und was die letzte Zeile andeutet: Ein klassischer Assistent gibt Ihnen einen Vorschlag, den Sie beim Lesen bewerten. Ein Agent liefert das Ergebnis vieler Schritte, und dessen Bewertung ist deutlich mehr Arbeit. Beides hat seinen Platz. Nur die Erwartung muss stimmen. Diese vier Punkte hängen alle an derselben Ursache: Man behandelt den Agenten wie die Autovervollständigung, an die man gewöhnt ist.

3:30 Wer so promptet, bekommt Stückwerk — kurze Befehle statt klarer Aufträge. Wer Agentenarbeit wie einen Vorschlag überfliegt, übersieht, was nebenbei mitgeändert wurde. Besonders wichtig ist der dritte Punkt: Ohne Tests fehlt dem Agenten die Rückmeldung, ob seine Änderung funktioniert hat. Er merkt es dann schlicht nicht.

3:49 Und die Geschwindigkeit verführt: Wenn in zwei Minuten etwas Fertiges dasteht, prüft man weniger genau als nach zwei Stunden eigener Arbeit.

Agentische Softwareentwicklung

3:58 Der Begriff „agentisch" fällt inzwischen überall, meist ohne Erklärung, und wird gern für alles verwendet, was irgendwie mit Sprachmodellen zu tun hat. Sehen wir uns deshalb an, was technisch tatsächlich dahintersteckt — und was daraus für Ihre eigene Rolle folgt. Denn die verändert sich in diesem Modell der Zusammenarbeit deutlich mehr als das Werkzeug selbst. Am Ende dieses Kapitels sollten Sie beides benennen können.

4:22 Agentisch heißt im Kern: Das Modell entscheidet selbst über die nächsten Schritte, innerhalb von Grenzen, die Sie setzen. Es sammelt Kontext, plant, führt Werkzeuge aus, bewertet das Ergebnis und wiederholt diesen Zyklus, bis das Ziel erreicht ist. Der Vergleich, der am besten trägt: ein Navigationsgerät gegenüber einem Fahrer. Das Navi sagt Ihnen die Route, fahren müssen Sie selbst.

4:46 Der Agent fährt — und Sie sagen, wohin und was unterwegs tabu ist. Wichtig ist das Wort „innerhalb von Grenzen". Wie eng die sind, entscheiden Sie, nicht das Modell. Diese fünf Schritte beschreiben keinen starren Ablauf, sondern eine Haltung. Sie formulieren ein Ziel statt einer Tastenfolge — das ist der schwerste Schritt für Menschen, die gewohnt sind, in Implementierungen zu denken.

5:10 Dann lassen Sie den Agenten Kontext sammeln, statt ihn selbst zusammenzutragen. Bevor Code entsteht, sehen Sie sich den Plan an. Die Umsetzung geben Sie in Portionen frei, die Sie prüfen können. Und bewertet wird am Diff und an den Tests, nicht an der Erfolgsmeldung. Jeder dieser Schritte ist zugleich ein Kontrollpunkt. Autonomie ist nichts, was man an- oder ausschaltet — sie ist einstellbar.

5:34 Hier steht der eigentlich unbequeme Teil. Sie beschreiben Absicht und Randbedingungen, statt zu implementieren. Sie bewerten Diffs, statt Zeilen zu tippen. Sie sichern ab — mit Tests, Reviews, Versionskontrolle. Und Sie entscheiden je Aufgabe, wie viel Autonomie sie verträgt. Für viele Entwickler ist das eine Umstellung, die mehr Übung braucht als das Werkzeug selbst.

5:56 Die handwerkliche Freude am Schreiben von Code verlagert sich auf das Formulieren und Beurteilen. Ob man das als Gewinn empfindet, ist Geschmackssache. Dass es die Arbeit verändert, ist keine. Für den Einstieg gilt: klein anfangen. Suchen Sie sich eine Aufgabe, die klar umrissen ist — eine Hilfsfunktion umbenennen, eine Readme-Sektion ergänzen.

6:18 Der Punkt ist nicht das Ergebnis, sondern die Erfahrung, einen Auftrag so zu formulieren, dass der Agent ihn ohne Rückfragen zu Ende bringt. Und dann kommt der Teil, den viele überspringen: die Änderung bewusst annehmen oder ablehnen. Nicht durchwinken, weil es plausibel aussieht. Wer diese Entscheidung von Anfang an ernst nimmt, gewöhnt sich gar nicht erst das Durchwinken an.

CLI, IDE, App und Cloud

6:41 Codex ist nicht ein einzelnes Programm, sondern über mehrere Oberflächen erreichbar — Kommandozeile, Editor, eigene App und Cloud. Das klingt zunächst nach einem Detail für die Dokumentation, ist aber eine praktische Entscheidung, die Sie künftig fast täglich treffen werden. Sehen wir uns deshalb an, wofür sich welche Oberfläche eignet, was sie voraussetzt und woran Sie merken, dass Sie gerade die falsche gewählt haben.

7:05 Vier Zugänge, ein Agent: das Werkzeug für die Kommandozeile, die Erweiterung für VS Code und JetBrains, die eigenständige Desktop-App und die Cloud-Umgebung im Web. Das Entscheidende steht im letzten Satz: Die Konfiguration teilen sie sich. Sie richten also Modell, Rechte und Projektregeln einmal ein und finden sie überall wieder.

7:25 Denken Sie an ein Auto mit mehreren Bedienelementen — Lenkrad, Tempomat, Sprachsteuerung. Es ist derselbe Wagen, nur greifen Sie unterschiedlich zu, je nachdem, was Sie gerade tun. Hinter dieser Tabelle steckt eine einzige Frage: Wie nah muss ich dran sein? Ganz nah dran ist die Kommandozeile — direkt, skriptbar, ohne Umweg.

7:46 Etwas weiter weg die IDE, wo Sie die Änderungen im Editor sehen, während sie entstehen. Noch weiter die Desktop-App, mit der Sie mehrere Aufträge im Blick behalten, ohne bei jedem dabeizusitzen. Und ganz weit weg die Cloud, wo etwas ohne Sie weiterläuft. Je weiter rechts, desto mehr Aufgaben laufen gleichzeitig — und desto wichtiger wird, dass der Auftrag von Anfang an vollständig war.

8:11 Die Auswahl folgt vier einfachen Fragen. Brauchen Sie Ihre lokale Toolchain oder ein privates Netz? Dann Kommandozeile. Wollen Sie Änderungen sofort sichtbar prüfen? Dann die IDE. Betreuen Sie mehrere lange Aufträge? Dann die Desktop-App. Wollen Sie einen Auftrag abgeben und später abholen? Dann die Cloud. In der Praxis mischen die meisten: lokal entwickeln, Größeres in die Cloud geben.

8:35 Wichtig ist nur, dass Sie die Wahl bewusst treffen und nicht aus Gewohnheit — sonst delegieren Sie irgendwann Aufgaben in die Cloud, die dort gar nicht laufen können. Der erste Punkt ist der, der am häufigsten Zeit kostet: Die Cloud kennt Ihre lokalen Dienste und Datenbanken nicht. Was auf Ihrem Rechner läuft, existiert dort schlicht nicht.

8:57 Der zweite ist subtiler — wenn Sie die Oberfläche wechseln, wandert der Gesprächskontext nicht mit. Sie müssen neu erklären. Der dritte ist ein psychologischer: In der IDE sehen Sie den Diff so schön aufbereitet, dass Zustimmen leichter fällt als Prüfen. Und der vierte ist banal, aber ärgerlich: Nicht jede Oberfläche steht in jedem Abo-Tarif bereit.

Installation und Einrichtung

9:19 Genug Theorie. Die nächsten Folien bringen Sie in wenigen Minuten an den Punkt, an dem Codex tatsächlich läuft — auf macOS, Linux oder Windows, wahlweise über das Installationsskript, npm oder Homebrew. Wir klären dabei gleich mit, welche Stolperfallen am häufigsten zuschlagen, denn die sind erstaunlich banal und kosten trotzdem regelmäßig eine Viertelstunde.

9:40 Am Ende steht eine Umgebung, von der Sie wissen, dass sie funktioniert. Codex wird als Werkzeug für die Kommandozeile installiert und mit dem Befehl codex im Projektordner gestartet. Empfohlen ist das Installationsskript; alternativ gibt es den Weg über npm und über Homebrew. Was hier wichtig ist: Sie starten Codex immer in einem Projektordner, nicht irgendwo.

10:02 Der Ordner, in dem Sie den Befehl absetzen, bestimmt, was der Agent sieht und wo er arbeiten darf. Das klingt selbstverständlich, ist aber später — beim Thema Berechtigungen — der entscheidende Punkt. Drei Wege, ein Ergebnis. Das Installationsskript ist der empfohlene Weg; npm und Homebrew sind Alternativen, wenn Sie ohnehin mit diesen Werkzeugen arbeiten.

10:24 Auf das Detail kommt es hier weniger an als auf zwei Dinge. Erstens: Windows hat sein eigenes PowerShell-Skript, der Weg ist derselbe. Zweitens — und das ist die häufigste Frustquelle — nach der Installation brauchen Sie ein neues Terminal, damit der Befehl gefunden wird. Wer das überspringt, bekommt „command not found" und sucht den Fehler an der falschen Stelle.

10:47 Diese fünf Schritte führen Sie von null zu einer Umgebung, mit der man wirklich arbeiten kann. Terminal öffnen, installieren, neues Terminal, anmelden. Interessant sind die letzten beiden: Mit dem Befehl init lassen Sie eine erste Projektregel- Datei erzeugen — dazu kommen wir in Modul drei ausführlich. Und mit status prüfen Sie, mit welchem Modell und mit welchen Rechten Sie eigentlich arbeiten. Diesen Blick sollten Sie sich angewöhnen.

11:12 Es ist erstaunlich, wie oft Menschen mit Einstellungen arbeiten, von denen sie nichts wissen. Der erste Punkt kostet regelmäßig eine Viertelstunde: Das Paket heißt at-openai Schrägstrich codex — wer nur codex installiert, bekommt etwas völlig anderes. Der zweite ist das schon erwähnte neue Terminal. Der dritte trifft vor allem in Unternehmen zu: Ein Firmenproxy blockiert gern das Installationsskript, dann hilft der Weg über npm.

11:39 Und der vierte ist eine Information, die später wichtig wird: Die Konfiguration landet in Ihrem Heimatverzeichnis, nicht im Projekt. Sie gilt also zunächst für alle Projekte gleichzeitig. Jetzt sind Sie dran. Ziel ist eine Umgebung, die nachweislich läuft — nicht eine, von der Sie annehmen, dass sie läuft. Der Nachweis ist einfach: Codex startet angemeldet im Projektordner, und der status-Befehl zeigt Ihnen Modell und Rechte an.

12:06 Wenn das Installationsskript hakt, ist der Weg über npm der Fallback; dafür brauchen Sie Node in Version 22 oder neuer. Nehmen Sie sich die Zeit, wirklich hinzusehen, was status ausgibt. Diese Ausgabe werden wir in den nächsten Kapiteln noch mehrfach brauchen.

Modelle passend einsetzen

12:22 Codex arbeitet nicht mit einem einzigen Modell, sondern mit mehreren — unterschiedlich stark, unterschiedlich teuer, unterschiedlich schnell. Dazu kommt ein zweiter Regler, der oft übersehen wird: wie gründlich das Modell nachdenkt, bevor es handelt. Beides zusammen ist Teil der Aufgabenplanung und nicht eine Einstellung, die man einmal setzt und dann vergisst.

12:43 In diesem Kapitel klären wir, welche Kombination zu welcher Art von Aufgabe passt. Zwei Regler bestimmen, wie der Agent arbeitet. Der eine ist das Modell selbst, der andere der Denkaufwand — von leicht bis maximal. Der Denkaufwand steuert, wie gründlich das Modell plant, bevor es handelt. Der Vergleich, der hier trägt: Sie können eine Frage aus dem Bauch beantworten oder sich erst zehn Minuten Gedanken machen. Beides hat seine Berechtigung.

13:10 Für das Umbenennen einer Variablen ist langes Nachdenken verschwendete Zeit und verschwendetes Geld. Für eine Architekturentscheidung ist es genau richtig. Die Namen in dieser Tabelle werden Sie vermutlich nicht auswendig lernen — und das müssen Sie auch nicht. Wichtiger ist das Muster dahinter: Es gibt jeweils ein sehr starkes Modell für komplexe Arbeit mit Urteilsvermögen, ein ausgewogenes für den Alltag und ein schnelles, günstiges für Zuarbeit.

13:38 Diese Staffelung bleibt, auch wenn die Namen wechseln. Und sie wechseln oft — der Stand hier ist September 2026. Prüfen Sie das vor dem Einsatz nach; Modelle werden regelmäßig abgelöst, und abgekündigte verschwinden auch aus laufenden Konfigurationen. Vier Wege, dasselbe zu tun. Innerhalb einer laufenden Sitzung schalten Sie mit model um — praktisch, wenn Sie mitten in der Arbeit merken, dass die Aufgabe mehr Tiefe braucht.

14:04 Mit status sehen Sie, womit Sie gerade arbeiten. Und beim Start können Sie das Modell direkt mitgeben, ausgeschrieben oder in der Kurzform. Worauf es hier ankommt: Wenn Sie gar nichts angeben, wählt Codex selbst ein empfohlenes Modell. Das ist kein schlechter Standard — aber es ist eine Entscheidung, die jemand anderes für Sie trifft.

14:24 Was Sie dauerhaft wollen, gehört in die Konfigurationsdatei. Zwei Zeilen genügen: das Modell und der Denkaufwand. Interessant ist der zweite Block — ein Profil. Damit bündeln Sie eine Kombination unter einem Namen und wechseln später mit einem Handgriff. Hier ist es ein Profil namens „sichten": schnelles Modell, niedriger Denkaufwand, gedacht für das Durchsehen großer Codemengen.

14:48 Wir vertiefen Profile in Modul sieben, wenn es um Berechtigungen geht. Merken Sie sich für den Moment: Dieselbe Datei nutzen die Kommandozeile, die Desktop-App und die IDE-Erweiterung. Vier Faustregeln. Eine große Codebasis zu sichten schafft auch ein schnelles, günstiges Modell — dabei geht es ums Finden, nicht ums Urteilen.

15:09 Architektur und Planung verlangen das starke Modell mit hohem Denkaufwand; hier zahlt sich Tiefe aus. Mechanisches Umbenennen braucht das Gegenteil: möglichst wenig Nachdenken, möglichst schnell. Und der vierte Punkt wird gern übersehen: Kosten und Wartezeit sind Teil der Entscheidung. Wer grundsätzlich das stärkste Modell mit maximalem Denkaufwand fährt, wartet viel und zahlt viel — für Ergebnisse, die oft nicht besser sind.

15:35 Diese Übung lässt sich nicht durch Zuhören ersetzen — Sie müssen den Unterschied selbst sehen. Nehmen Sie eine Aufgabe und lassen Sie sie zweimal laufen, mit unterschiedlichen Modellen oder unterschiedlichem Denkaufwand. Und dann vergleichen Sie nicht nur das Ergebnis, sondern auch die Dauer und die Zahl der Rückfragen. Oft ist das schnellere Modell für die konkrete Aufgabe völlig ausreichend, und Sie sparen sich beim nächsten Mal die Wartezeit. Manchmal ist es andersherum.

16:01 Beides zu wissen ist mehr wert als jede allgemeine Empfehlung.

Sessions verwalten

16:05 Eine Session ist mehr als ein Chatfenster: Sie ist der gesammelte Kontext einer Arbeit — alles, was der Agent gelesen, ausgeführt und geschlossen hat. Wie Sie damit umgehen, entscheidet darüber, ob er nach einer Stunde noch treffsicher antwortet oder nur noch allgemein. Das ist keine Frage der Modellqualität, sondern der Ordnung, die Sie halten. Sehen wir uns an, welche Handgriffe dabei wirklich zählen.

16:29 Eine Session bündelt einen laufenden Auftrag samt allem, was der Agent dabei gelesen und getan hat. Codex speichert sie je Repository, sodass Sie eine unterbrochene Arbeit später wieder aufnehmen können, statt bei null zu beginnen. Der passende Vergleich ist der Schreibtisch: Alles, was Sie an einem Vorgang brauchen, liegt ausgebreitet vor Ihnen. Solange Sie an einer Sache arbeiten, ist das hilfreich.

16:52 Sobald Sie drei Vorgänge gleichzeitig ausbreiten, finden Sie nichts mehr — und dem Agenten geht es genauso. Vier Befehle decken den Alltag ab. Sie starten eine neue Session im Projekt, Sie nehmen mit resume die letzte wieder auf. Der dritte Befehl ist der für Automatisierung — er läuft ohne Oberfläche und lässt sich in Skripte einbauen; dazu kommt Modul zehn ausführlich.

17:14 Und der vierte schaltet die Websuche dazu, wenn der Agent aktuelle Informationen braucht. Wichtiger als die Befehle ist die Angewohnheit dahinter: Mit status behalten Sie im Blick, wie voll der Kontext schon ist. Das ist die Zahl, die darüber entscheidet, wann Sie aufräumen sollten. Der rote Faden dieser fünf Schritte lautet: Ordnung halten, bevor Unordnung entsteht. Je Aufgabe eine eigene Session. Zwischenstände committen, bevor der Kontext voll wird.

17:42 Den Kontextstand im Blick behalten. Unterbrochene Arbeit gezielt fortsetzen. Und erledigte Sessions bewusst schließen. Das klingt nach Sekretariatsarbeit, hat aber einen handfesten Grund: Wenn der Kontext voll ist, wird der Verlauf verdichtet, und dabei gehen Details verloren. Wer vorher committet, hat den Stand wenigstens im Repository — nachvollziehbar, auch wenn der Agent sich nicht mehr erinnert.

18:07 Der erste Punkt ist der häufigste Fehler überhaupt: zwei Themen in einer Session. Der Agent vermischt dann Kontexte und zieht Schlüsse aus Dateien, die mit Ihrer aktuellen Frage nichts zu tun haben. Der zweite erklärt, warum lange Sessions schwächer werden — ein voller Kontext wird verdichtet, und Verdichten heißt Weglassen.

18:26 Der dritte folgt daraus: Ohne Commit ist der Zwischenstand danach schwer zu belegen. Und der vierte ist eine Information, die man einmal wissen muss: Sessions gelten je Repository, nicht global.

Integration in den Entwicklungsprozess

18:37 Ein Agent, der neben dem etablierten Prozess herläuft, wird über kurz oder lang zum Problem — nicht wegen seiner Ergebnisse, sondern weil niemand mehr weiß, was geprüft wurde und was nicht. Sehen wir uns deshalb an, wie er sich in die vorhandenen Abläufe einfügt: vor dem Commit, am Pull Request und in der Pipeline. Und warum es klug ist, ihm dabei ausdrücklich keinen Sonderweg einzuräumen.

19:00 Codex dockt an drei Stellen an: als Reviewer auf Pull Requests, als Schritt in der Build-Pipeline und als lokaler Helfer vor dem Commit. Der entscheidende Satz ist der letzte: Die Regeln dafür stehen im Repository, nicht im Kopf einzelner Leute. Denn sobald ein Teammitglied den Agenten anders einsetzt als die anderen, entsteht genau das, was Prozesse verhindern sollen — unterschiedliche Qualität, je nachdem, wer gerade arbeitet.

19:24 Behandeln Sie den Agenten wie ein neues Teammitglied: Es bekommt dieselben Regeln und dieselben Kontrollpunkte. Vier Gründe, warum sich die Einordnung lohnt. Der Pull Request bleibt der Ort der Entscheidung — dort wird zusammengeführt, dort wird verantwortet. Agentenarbeit ist im Diff sichtbar und damit rückholbar. Die Regeln gelten für alle gleich, weil sie im Repository stehen.

19:48 Und automatisierte Läufe ergänzen den Menschen, ersetzen ihn nicht. Der letzte Punkt ist mehr als eine Höflichkeitsfloskel: Ein Agent, der prüft, findet anderes als ein Mensch, der prüft. Beides zusammen ist besser als jedes für sich — aber eben nur zusammen. Diese drei Zeilen sind nach Nähe sortiert. Ganz nah bei Ihnen: der Review-Befehl in der laufenden Sitzung, noch bevor irgendetwas gepusht ist.

20:13 Eine Stufe weiter: der Pull Request, wo Sie den Agenten mit einem Kommentar um ein Review bitten und die Antwort als Kommentar zurückbekommen. Und ganz außen: die Build-Pipeline, wo er als regulärer Prüfschritt läuft. Was in allen drei Zeilen gilt, steht in der Fußzeile: Ein Review des Agenten ersetzt kein menschliches Review. Es geht ihm voraus und räumt die einfachen Fälle ab.

20:37 Der erste Punkt ist der, der Teams am schnellsten frustriert: Automatisches Review auf jedem Pull Request erzeugt Rauschen, und Rauschen wird ignoriert — irgendwann auch dann, wenn ausnahmsweise etwas Wichtiges dabei ist. Der zweite hängt an den Projektregeln: Ohne sie bemängelt der Agent den falschen Stil und diskutiert Geschmacksfragen.

20:56 Der dritte betrifft Cloud-Läufe, die bewusst vergebene Repository-Rechte brauchen. Und der vierte ist die wichtigste Klarstellung: Ein grüner Agentenlauf ist kein Ersatz für grüne Tests. Hier üben Sie etwas, das sich sofort in den Alltag übertragen lässt: den Agenten als ersten Reviewer, bevor Sie pushen. Nehmen Sie eine offene Änderung, lassen Sie sie prüfen — und dann kommt der eigentliche Lernteil. Gewichten Sie die Hinweise. Welche sind echte Fehler, welche nur Geschmack?

21:24 Ein Agent unterscheidet das nicht zuverlässig; er meldet beides mit derselben Bestimmtheit. Wer diese Gewichtung nicht übt, übernimmt entweder alles oder ignoriert alles. Beides verschenkt den Nutzen.

Einsatzszenarien und Zuschnitt

21:37 Zum Abschluss die vielleicht praktischste Frage des ganzen Moduls: Welche Aufgaben eignen sich überhaupt zum Delegieren, und welche besser nicht? Die Antwort hat weniger mit der Formulierung des Prompts zu tun, als die meisten erwarten — und sehr viel mehr mit dem Zuschnitt der Aufgabe. Wer das einmal verinnerlicht hat, spart sich einen großen Teil der Frustration, über die im Umgang mit Coding-Agenten sonst berichtet wird.

22:00 Der Zuschnitt einer Aufgabe entscheidet über den Erfolg. Kleine, klar begrenzte Änderungen laufen ohne Plan. Alles, was mehrere Dateien oder Entwurfsentscheidungen berührt, braucht erst Analyse und Plan. Das ist die Faustregel, die Sie sich merken sollten. Denn der häufigste Grund für enttäuschende Ergebnisse ist nicht ein schlecht formulierter Prompt, sondern eine zu groß geschnittene Aufgabe.

22:22 Ein Agent, der zu viel auf einmal soll, trifft unterwegs Dutzende Entscheidungen, von denen Sie keine gesehen haben — und am Ende steht ein Diff, das niemand mehr sinnvoll prüfen kann. Vier Stufen, und die Steigerung ist wichtiger als die einzelnen Beispiele. Klein heißt: direkt beauftragen, ein Tippfehler braucht keinen Plan.

22:43 Mittel heißt: Plan sichten, dann bauen. Groß heißt: analysieren, planen, in Etappen umsetzen. Und offen — also eine Fehlersuche, bei der Sie die Ursache noch nicht kennen — heißt: erst untersuchen lassen, nichts ändern. Die Fußzeile gibt die Regel für den Zweifelsfall: eine Stufe kleiner schneiden. Teilergebnisse sind leichter zu prüfen, und ein zu klein geschnittener Auftrag kostet Sie eine Minute, ein zu großer einen Nachmittag.

23:11 Vier Merkmale. Das Ziel ist prüfbar formuliert, nicht nur beschrieben — es gibt also etwas, woran man Erfolg messen kann. Der betroffene Bereich ist eingegrenzt, der Agent muss nicht das halbe Repository durchsuchen. Es gibt ein Erfolgskriterium, meist einen Test. Und der erwartete Umfang passt in ein Review. Der letzte Punkt ist der praktischste Filter überhaupt: Wenn Sie sich das Diff nicht in einer sinnvollen Zeit ansehen können, ist der Auftrag zu groß — unabhängig davon, wie gut der Agent ihn erledigen würde.

23:42 Diese vier Fallen tauchen in der Praxis fast täglich auf. Ein zu großer Auftrag endet in einem Diff, das niemand prüft — und ungeprüfter Code ist schlimmer als kein Code. Ein zu vager Auftrag lädt den Agenten ein, Annahmen zu treffen, die er Ihnen nicht mitteilt. Fehlersuche ohne Reproduktion führt zu Ratearbeit; dazu kommen wir in Modul fünf ausführlich.

24:03 Und mehrere Ziele in einem Auftrag lassen sich nicht getrennt bewerten — Sie können dann nur alles annehmen oder alles verwerfen. Für diese Übung brauchen Sie ein echtes Vorhaben aus Ihrem eigenen Projekt, kein Beispiel aus einem Lehrbuch. Der Grund: Nur echte Vorhaben haben die unangenehmen Zwischenabhängigkeiten, um die es hier geht.

24:23 Zerlegen Sie es in drei Teilaufträge, jeder mit einem prüfbaren Ergebnis und einem Umfang, den Sie reviewen können. Wenn Ihnen das schwerfällt, ist das kein schlechtes Zeichen — es ist genau die Fähigkeit, die den Unterschied zwischen frustrierender und produktiver Agentenarbeit ausmacht. Vier Punkte zum Mitnehmen. Codex handelt im Projekt — prüfen heißt deshalb, das Diff zu lesen, nicht einen Vorschlag zu überfliegen.

24:47 Vier Oberflächen sprechen denselben Agenten an und teilen sich die Konfiguration. Modell und Denkaufwand gehören in die Aufgabenplanung, nicht in eine Einstellung, die man einmal setzt. Und der wichtigste Punkt: Der Zuschnitt der Aufgabe entscheidet mehr als die Formulierung des Prompts. Genau da setzt das nächste Modul an — wir sehen uns an, wie Sie Kontext gezielt bereitstellen, damit der Agent zuverlässig arbeitet.