Codex- und Multi-Agent-Workflow: Arbeiten Sie mit Agenten, ohne die Kontrolle zu verlieren

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2Wenn ein Coding-Agent zum ersten Mal tatsächlich einen Fehler für Sie behebt, ist die Reaktion fast immer dieselbe: eine Mischung aus Begeisterung und Misstrauen. Schön, sicher. Aber dann schaust du auf den Unterschied und fragst dich: „Okay, aber was genau hat er berührt? Kann ich ihm vertrauen? Wird er es morgen noch einmal auf die gleiche Weise tun?“.
3~
4Hier beginnt meiner Meinung nach der interessante Teil. Nicht, wenn der Agent eine Funktion schreibt, sondern wenn er in der Lage ist, ganze Aufgaben zu übernehmen: das Repository lesen, einen Patch erstellen, Tests ausführen, eine PR öffnen, nach einem Überprüfungskommentar zurückkommen. Codex geht genau in diese Richtung: Hintergrundarbeit, separate Arbeitsbäume, integrierter Browser, Automatisierungen, Plugins, Speicher und explizitere Berechtigungskontrollen.
5~
6Es geht nicht darum, sich eine Zukunft vorzustellen, in der niemand mehr Code liest. Es wäre eine schreckliche und auch ziemlich naive Zukunft. Es geht darum, herauszufinden, wie man mit Agenten zusammenarbeitet, die viel können, ohne sie alles tun zu lassen.
7~
8## Die Änderung der Gewohnheit
9~
10Mit der traditionellen Autovervollständigung saßen Sie immer am Steuer. Die KI hat eine Linie vorgeschlagen, Sie haben entschieden. Bei einem Agenten ändert sich jedoch die Beziehung: Sie geben ihm ein Ziel und er durchläuft mehrere Schritte selbstständig.
11~
12Das ist mächtig, aber es verschiebt das Problem. Die Frage ist nicht mehr nur „Kann das Modell programmieren?“. Die Frage wird:
13~
14- Habe ich ihm ein ausreichend kleines Zielfernrohr gegeben?
15- Wissen Sie, wie Sie das Ergebnis überprüfen können?
16- Arbeite ich in einer isolierten Umgebung?
17- Ist die abschließende Prüfung noch human und sorgfältig?
18~
19Ein gesunder Arbeitsablauf sieht eher so aus als wie ein Zauberstab:
20~
21```mermaid
22flowchart LR
23    Idea[Menschliche Aufgabe] --> Scope[Kleiner, nachweisbarer Zweck]
24    Scope --> Agent[Agent im Arbeitsbaum isoliert]
25    Agent --> Checks[Test, Lint, Build, Browser]
26    Checks --> Review[Menschliche Überprüfung]
27    Review --> Merge[Zusammenführung oder neue Iteration]
28    Review --> Iterate[Genaue Kommentare zum Diff]
29    Iterate --> Agent
30```
31~
32Es klingt weniger romantisch als „Der Agent baut alles“, funktioniert aber viel besser. Und so funktionieren auch Teams, die gut mit Menschen umgehen können: klare Aufgaben, schnelles Feedback, klare Verantwortlichkeiten.
33~
34## Die gute Eingabeaufforderung ist fast ein gutes Ticket
35~
36Die gefährlichste Aufforderung ist die vage, aber sichere Aufforderung: „Rechnungsseite reparieren“, „Architektur verbessern“, „Authentifizierungsmodul bereinigen“. Das sind Anfragen, die produktiv klingen und große Unterschiede erzeugen. Aber dann beschäftigt man sich mit Archäologie.
37~
38Eine hilfreiche Eingabeaufforderung ist langweiliger. Beispiel: Implementieren Sie den CSV-Export für die Rechnungsseite und wissen Sie, dass sich die Tabelle in `app/(dashboard)/invoices/page.tsx` befindet, die Abfragen in `src/server/invoices.ts` und es bereits ein ähnliches Muster in `app/(dashboard)/reports` gibt.
39~
40Fügen Sie dann klare Einschränkungen hinzu: Ändern Sie nicht das Datenbankschema, fügen Sie keine Abhängigkeiten hinzu, wenn ein kleines Dienstprogramm ausreicht, und behalten Sie den vorhandenen UI-Stil bei. Und schließen Sie mit der Verifizierung ab: `npm test -- invoices` und `npm run build`.
41~
42Bei dieser Art von Auftrag geht es nicht darum, „der KI besser zu erklären“. Es dient vor allem dazu, Ihnen klarer zu machen, was Sie delegieren. Wenn Sie es nicht konkret aufschreiben können, ist die Aufgabe möglicherweise noch nicht für einen Agenten bereit.
43~
44## Drei Jobs, die ich gerne delegiere
45~
46Die erste ist sich wiederholende, aber überprüfbare Arbeit: Tests hinzufügen, Aufrufe zu einer neuen internen API migrieren, Importe aktualisieren, veraltete Komponenten ersetzen, TypeScript-Fehler beheben. Hier kann der Agent Stunden sparen und das Risiko ist kontrollierbar.
47~
48Bei der zweiten handelt es sich um eine explorative Arbeit: „Finden Sie heraus, wo diese Summe berechnet wird“, „Erklären Sie mir, warum dieser Test fragil ist“, „Reproduzieren Sie den Fehler und sagen Sie mir, welche Dateien betroffen zu sein scheinen“. Auch wenn es nicht sofort einen Patch erzeugt, kann es nützliche Aufklärungsarbeit leisten.
49~
50Der dritte Teil sind wiederkehrende Wartungsarbeiten: kleine Abhängigkeitsaktualisierungen, Bereinigung alter Feature-Flags, Zusammenfassung blockierter PRs, Überprüfung vergessener TODOs. Es ist nicht glamourös, aber es ist genau die Art von Arbeit, die sich anhäuft.
51~
52## Drei Jobs, die ich menschlich halte
53~
54Produktentscheidungen bleiben menschlich. Wenn eine Änderung die Art und Weise ändert, wie ein Benutzer bezahlt, Daten löscht, Preise sieht oder eine Erlaubnis versteht, möchte ich eine verantwortliche Person.
55~
56Auch Sicherheitsgrenzen verdienen menschliche Aufmerksamkeit: Authentifizierung, Rollen, Token, Protokollierung sensibler Daten, Datenbankmigrationen. Ein Agent kann bei der Umsetzung helfen, muss aber nicht der alleinige Entscheidungsträger sein.
57~
58Schließlich behalte ich alles, was architektonischen Geschmack menschlich erfordert. Ein Agent kann eine Umgestaltung vorschlagen, aber es bleibt eine Aufgabe zu verstehen, ob eine Abstraktion wirklich notwendig ist oder ob wir nur ein nicht existierendes Problem ausmerzen.
59~
60## Die Überprüfung ist nicht optional
61~
62Wenn ein Agent gut ist, besteht die Versuchung darin, dem Grün des CI zu vertrauen. Es ist verständlich. Dann beginnen auch die Probleme.
63~
64Ich schaue mir immer mindestens fünf Dinge an:
65~
661. Löst der Patch nur die gewünschte Aufgabe?
672. Hat er Dateien berührt, die nichts damit zu tun hatten?
683. Decken die Tests neuartiges Verhalten oder nur glückliche Zufälle ab?
694. Folgt der Code lokalen Mustern?
705. Werden Fehler wie im restlichen Projekt behandelt?
71~
72Wenn etwas nicht stimmt, muss das Feedback konkret sein. „Repariere es“ ist faul. Besser: Dieses Dienstprogramm dupliziert `parseMoney` in `src/lib/money.ts`; Verwenden Sie diese Funktion erneut, fügen Sie einen Test für den EUR-Fall hinzu und ändern Sie nicht die öffentliche API des Abrechnungsmoduls.
73~
74Agenten reagieren viel besser auf kleine, überprüfbare Kommentare. Merkwürdigerweise gilt das auch für die Menschen.
75~
76## Leitplanken, die sich lohnen
77~
78Wenn ein Agent Dateien lesen, Code schreiben und Befehle ausführen kann, sollte er als leistungsstarker Prozess behandelt werden. Es besteht kein Grund zur Paranoia, Sie brauchen Hygiene.
79~
80Verwenden Sie separate Arbeitsbäume oder Zweige. So können Sie den Unterschied vergleichen, fehlgeschlagene Experimente verwerfen und die Arbeit des Agenten nicht mit Ihrer Arbeit vermischen.
81~
82Beschränken Sie die Berechtigungen. Befehle wie `rg`, `git diff`, `npm test` und `npm run build` können ziemlich kostenlos sein. Bereitstellungen, Datenbankmigrationen, Zugriff auf Geheimnisse und zerstörerische Befehle müssen explizit bleiben.
83~
84Reduzieren Sie den Netzwerkzugriff, wenn Sie ihn nicht benötigen. Für viele Aufgaben genügen offizielle Dokumentation, Paketregistrierung und spezifische interne Dienste. Weniger Fläche, weniger Überraschungen.
85~
86Verfolgen Sie Aktionen. Wenn ein Patch zur Überprüfung eintrifft, sollten Sie in der Lage sein, Eingabeaufforderungen, ausgeführte Befehle, bestandene Tests und geänderte Dateien zu rekonstruieren. Nicht um Bürokratie zu schaffen, sondern um nachvollziehen zu können, was passiert, wenn etwas schiefgeht.
87~
88## Eine einfache Möglichkeit, als Team durchzustarten
89~
90Wenn ich Agenten in ein kleines Team einführen würde, würde ich ohne große Revolutionen beginnen.
91~
92Ich würde ein `agent-ready`-Label für Probleme mit klarem Umfang erstellen. Ich würde eine Vorlage mit Kontext, Einschränkungen und Überprüfungsbefehlen hinzufügen. Ich würde um eine kleine PR bitten, idealerweise unter ein paar hundert Zeilen. Für sichtbare Änderungen würde ich Tests oder Screenshots benötigen. Und vor allem würde ich einen Verantwortlichen für die Fusion benennen.
93~
94Nach zwei Wochen würde ich mir die Daten ansehen: Welche Aufgaben wurden wirklich beschleunigt, welche Überprüfungen waren umfangreich, welche Eingabeaufforderungen waren verwirrend, welche Teile der Codebasis waren zu fragil, um sie zu delegieren.
95~
96Es ist ein weniger spektakulärer Ansatz als „Ab heute machen wir alles mit den Agenten“, aber er ermöglicht es Ihnen, ohne Reue in die dritte Woche zu kommen.
97~
98## Der menschlichste Teil
99~
100Das Witzige daran ist, dass je autonomer die Agenten werden, desto wichtiger werden die klassischen Fähigkeiten: ein gutes Ticket schreiben, kleine Abstriche machen, Tests erstellen, Unterschiede lesen, Kompromisse kommunizieren. Der Agent beschleunigt diejenigen, die bereits wissen, wie man gut arbeitet. Es verstärkt auch das Chaos derjenigen, die schlecht delegieren.
101~
102Also nein, ich sehe Multi-Agent-Workflows nicht als Abkürzung, um mit dem Engineering aufzuhören. Ich sehe sie als eine Möglichkeit, mehr Energie auf die wichtigen Teile zu verlagern: zu entscheiden, was gebaut werden soll, sicherzustellen, dass es funktioniert, und das System verständlich zu halten.
103~
104Agenten können großartige asynchrone Kollegen sein. Aber um nützlich zu sein, braucht ein asynchroner Kollege Kontext, Grenzen und Überprüfung. Genau wie alle anderen.
105~
106## Nützliche Quellen
107~
108- [Codex für (fast) alles – OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Codex sicher bei OpenAI ausführen](https://openai.com/index/running-codex-safely/)
110- [Wir stellen Codex vor – OpenAI](https://openai.com/index/introducing-codex/)
111- [Was ist neu beim Copilot-Coding-Agenten von GitHub?](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2Wenn ein Coding-Agent zum ersten Mal tatsächlich einen Fehler für Sie behebt, ist die Reaktion fast immer dieselbe: eine Mischung aus Begeisterung und Misstrauen. Schön, sicher. Aber dann schaust du auf den Unterschied und fragst dich: „Okay, aber was genau hat er berührt? Kann ich ihm vertrauen? Wird er es morgen noch einmal auf die gleiche Weise tun?“.

4Hier beginnt meiner Meinung nach der interessante Teil. Nicht, wenn der Agent eine Funktion schreibt, sondern wenn er in der Lage ist, ganze Aufgaben zu übernehmen: das Repository lesen, einen Patch erstellen, Tests ausführen, eine PR öffnen, nach einem Überprüfungskommentar zurückkommen. Codex geht genau in diese Richtung: Hintergrundarbeit, separate Arbeitsbäume, integrierter Browser, Automatisierungen, Plugins, Speicher und explizitere Berechtigungskontrollen.

6Es geht nicht darum, sich eine Zukunft vorzustellen, in der niemand mehr Code liest. Es wäre eine schreckliche und auch ziemlich naive Zukunft. Es geht darum, herauszufinden, wie man mit Agenten zusammenarbeitet, die viel können, ohne sie alles tun zu lassen.

8## Die Änderung der Gewohnheit

10Mit der traditionellen Autovervollständigung saßen Sie immer am Steuer. Die KI hat eine Linie vorgeschlagen, Sie haben entschieden. Bei einem Agenten ändert sich jedoch die Beziehung: Sie geben ihm ein Ziel und er durchläuft mehrere Schritte selbstständig.

11~

12Das ist mächtig, aber es verschiebt das Problem. Die Frage ist nicht mehr nur „Kann das Modell programmieren?“. Die Frage wird:

13~

14- Habe ich ihm ein ausreichend kleines Zielfernrohr gegeben?

15- Wissen Sie, wie Sie das Ergebnis überprüfen können?

16- Arbeite ich in einer isolierten Umgebung?

17- Ist die abschließende Prüfung noch human und sorgfältig?

18~

19Ein gesunder Arbeitsablauf sieht eher so aus als wie ein Zauberstab:

20~

21```mermaid

22flowchart LR

23 Idea[Menschliche Aufgabe] --> Scope[Kleiner, nachweisbarer Zweck]

24 Scope --> Agent[Agent im Arbeitsbaum isoliert]

25 Agent --> Checks[Test, Lint, Build, Browser]

26 Checks --> Review[Menschliche Überprüfung]

27 Review --> Merge[Zusammenführung oder neue Iteration]

28 Review --> Iterate[Genaue Kommentare zum Diff]

29 Iterate --> Agent

30```

31~

32Es klingt weniger romantisch als „Der Agent baut alles“, funktioniert aber viel besser. Und so funktionieren auch Teams, die gut mit Menschen umgehen können: klare Aufgaben, schnelles Feedback, klare Verantwortlichkeiten.

33~

34## Die gute Eingabeaufforderung ist fast ein gutes Ticket

35~

36Die gefährlichste Aufforderung ist die vage, aber sichere Aufforderung: „Rechnungsseite reparieren“, „Architektur verbessern“, „Authentifizierungsmodul bereinigen“. Das sind Anfragen, die produktiv klingen und große Unterschiede erzeugen. Aber dann beschäftigt man sich mit Archäologie.

37~

38Eine hilfreiche Eingabeaufforderung ist langweiliger. Beispiel: Implementieren Sie den CSV-Export für die Rechnungsseite und wissen Sie, dass sich die Tabelle in `app/(dashboard)/invoices/page.tsx` befindet, die Abfragen in `src/server/invoices.ts` und es bereits ein ähnliches Muster in `app/(dashboard)/reports` gibt.

39~

40Fügen Sie dann klare Einschränkungen hinzu: Ändern Sie nicht das Datenbankschema, fügen Sie keine Abhängigkeiten hinzu, wenn ein kleines Dienstprogramm ausreicht, und behalten Sie den vorhandenen UI-Stil bei. Und schließen Sie mit der Verifizierung ab: `npm test -- invoices` und `npm run build`.

41~

42Bei dieser Art von Auftrag geht es nicht darum, „der KI besser zu erklären“. Es dient vor allem dazu, Ihnen klarer zu machen, was Sie delegieren. Wenn Sie es nicht konkret aufschreiben können, ist die Aufgabe möglicherweise noch nicht für einen Agenten bereit.

43~

44## Drei Jobs, die ich gerne delegiere

45~

46Die erste ist sich wiederholende, aber überprüfbare Arbeit: Tests hinzufügen, Aufrufe zu einer neuen internen API migrieren, Importe aktualisieren, veraltete Komponenten ersetzen, TypeScript-Fehler beheben. Hier kann der Agent Stunden sparen und das Risiko ist kontrollierbar.

47~

48Bei der zweiten handelt es sich um eine explorative Arbeit: „Finden Sie heraus, wo diese Summe berechnet wird“, „Erklären Sie mir, warum dieser Test fragil ist“, „Reproduzieren Sie den Fehler und sagen Sie mir, welche Dateien betroffen zu sein scheinen“. Auch wenn es nicht sofort einen Patch erzeugt, kann es nützliche Aufklärungsarbeit leisten.

49~

50Der dritte Teil sind wiederkehrende Wartungsarbeiten: kleine Abhängigkeitsaktualisierungen, Bereinigung alter Feature-Flags, Zusammenfassung blockierter PRs, Überprüfung vergessener TODOs. Es ist nicht glamourös, aber es ist genau die Art von Arbeit, die sich anhäuft.

51~

52## Drei Jobs, die ich menschlich halte

53~

54Produktentscheidungen bleiben menschlich. Wenn eine Änderung die Art und Weise ändert, wie ein Benutzer bezahlt, Daten löscht, Preise sieht oder eine Erlaubnis versteht, möchte ich eine verantwortliche Person.

55~

56Auch Sicherheitsgrenzen verdienen menschliche Aufmerksamkeit: Authentifizierung, Rollen, Token, Protokollierung sensibler Daten, Datenbankmigrationen. Ein Agent kann bei der Umsetzung helfen, muss aber nicht der alleinige Entscheidungsträger sein.

57~

58Schließlich behalte ich alles, was architektonischen Geschmack menschlich erfordert. Ein Agent kann eine Umgestaltung vorschlagen, aber es bleibt eine Aufgabe zu verstehen, ob eine Abstraktion wirklich notwendig ist oder ob wir nur ein nicht existierendes Problem ausmerzen.

59~

60## Die Überprüfung ist nicht optional

61~

62Wenn ein Agent gut ist, besteht die Versuchung darin, dem Grün des CI zu vertrauen. Es ist verständlich. Dann beginnen auch die Probleme.

63~

64Ich schaue mir immer mindestens fünf Dinge an:

65~

661. Löst der Patch nur die gewünschte Aufgabe?

672. Hat er Dateien berührt, die nichts damit zu tun hatten?

683. Decken die Tests neuartiges Verhalten oder nur glückliche Zufälle ab?

694. Folgt der Code lokalen Mustern?

705. Werden Fehler wie im restlichen Projekt behandelt?

71~

72Wenn etwas nicht stimmt, muss das Feedback konkret sein. „Repariere es“ ist faul. Besser: Dieses Dienstprogramm dupliziert `parseMoney` in `src/lib/money.ts`; Verwenden Sie diese Funktion erneut, fügen Sie einen Test für den EUR-Fall hinzu und ändern Sie nicht die öffentliche API des Abrechnungsmoduls.

73~

74Agenten reagieren viel besser auf kleine, überprüfbare Kommentare. Merkwürdigerweise gilt das auch für die Menschen.

75~

76## Leitplanken, die sich lohnen

77~

78Wenn ein Agent Dateien lesen, Code schreiben und Befehle ausführen kann, sollte er als leistungsstarker Prozess behandelt werden. Es besteht kein Grund zur Paranoia, Sie brauchen Hygiene.

79~

80Verwenden Sie separate Arbeitsbäume oder Zweige. So können Sie den Unterschied vergleichen, fehlgeschlagene Experimente verwerfen und die Arbeit des Agenten nicht mit Ihrer Arbeit vermischen.

81~

82Beschränken Sie die Berechtigungen. Befehle wie `rg`, `git diff`, `npm test` und `npm run build` können ziemlich kostenlos sein. Bereitstellungen, Datenbankmigrationen, Zugriff auf Geheimnisse und zerstörerische Befehle müssen explizit bleiben.

83~

84Reduzieren Sie den Netzwerkzugriff, wenn Sie ihn nicht benötigen. Für viele Aufgaben genügen offizielle Dokumentation, Paketregistrierung und spezifische interne Dienste. Weniger Fläche, weniger Überraschungen.

85~

86Verfolgen Sie Aktionen. Wenn ein Patch zur Überprüfung eintrifft, sollten Sie in der Lage sein, Eingabeaufforderungen, ausgeführte Befehle, bestandene Tests und geänderte Dateien zu rekonstruieren. Nicht um Bürokratie zu schaffen, sondern um nachvollziehen zu können, was passiert, wenn etwas schiefgeht.

87~

88## Eine einfache Möglichkeit, als Team durchzustarten

89~

90Wenn ich Agenten in ein kleines Team einführen würde, würde ich ohne große Revolutionen beginnen.

91~

92Ich würde ein `agent-ready`-Label für Probleme mit klarem Umfang erstellen. Ich würde eine Vorlage mit Kontext, Einschränkungen und Überprüfungsbefehlen hinzufügen. Ich würde um eine kleine PR bitten, idealerweise unter ein paar hundert Zeilen. Für sichtbare Änderungen würde ich Tests oder Screenshots benötigen. Und vor allem würde ich einen Verantwortlichen für die Fusion benennen.

93~

94Nach zwei Wochen würde ich mir die Daten ansehen: Welche Aufgaben wurden wirklich beschleunigt, welche Überprüfungen waren umfangreich, welche Eingabeaufforderungen waren verwirrend, welche Teile der Codebasis waren zu fragil, um sie zu delegieren.

95~

96Es ist ein weniger spektakulärer Ansatz als „Ab heute machen wir alles mit den Agenten“, aber er ermöglicht es Ihnen, ohne Reue in die dritte Woche zu kommen.

97~

98## Der menschlichste Teil

99~

100Das Witzige daran ist, dass je autonomer die Agenten werden, desto wichtiger werden die klassischen Fähigkeiten: ein gutes Ticket schreiben, kleine Abstriche machen, Tests erstellen, Unterschiede lesen, Kompromisse kommunizieren. Der Agent beschleunigt diejenigen, die bereits wissen, wie man gut arbeitet. Es verstärkt auch das Chaos derjenigen, die schlecht delegieren.

101~

102Also nein, ich sehe Multi-Agent-Workflows nicht als Abkürzung, um mit dem Engineering aufzuhören. Ich sehe sie als eine Möglichkeit, mehr Energie auf die wichtigen Teile zu verlagern: zu entscheiden, was gebaut werden soll, sicherzustellen, dass es funktioniert, und das System verständlich zu halten.

103~

104Agenten können großartige asynchrone Kollegen sein. Aber um nützlich zu sein, braucht ein asynchroner Kollege Kontext, Grenzen und Überprüfung. Genau wie alle anderen.

105~

106## Nützliche Quellen

107~

108- [Codex für (fast) alles – OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Codex sicher bei OpenAI ausführen](https://openai.com/index/running-codex-safely/)

110- [Wir stellen Codex vor – OpenAI](https://openai.com/index/introducing-codex/)

111- [Was ist neu beim Copilot-Coding-Agenten von GitHub?](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~