Wenn 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?“.

Hier 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.

Es 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.

Die Änderung der Gewohnheit

Mit 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.

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

• Habe ich ihm ein ausreichend kleines Zielfernrohr gegeben?
• Wissen Sie, wie Sie das Ergebnis überprüfen können?
• Arbeite ich in einer isolierten Umgebung?
• Ist die abschließende Prüfung noch human und sorgfältig?

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

Es 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.

Die gute Eingabeaufforderung ist fast ein gutes Ticket

Die 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.

Eine 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.

Fü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.

Bei 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.

Drei Jobs, die ich gerne delegiere

Die 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.

Bei 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.

Der 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.

Drei Jobs, die ich menschlich halte

Produktentscheidungen 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.

Auch 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.

Schließ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.

Die Überprüfung ist nicht optional

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

Ich schaue mir immer mindestens fünf Dinge an:

1. Löst der Patch nur die gewünschte Aufgabe?
2. Hat er Dateien berührt, die nichts damit zu tun hatten?
3. Decken die Tests neuartiges Verhalten oder nur glückliche Zufälle ab?
4. Folgt der Code lokalen Mustern?
5. Werden Fehler wie im restlichen Projekt behandelt?

Wenn 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.

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

Leitplanken, die sich lohnen

Wenn 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.

Verwenden 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.

Beschrä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.

Reduzieren 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.

Verfolgen 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.

Eine einfache Möglichkeit, als Team durchzustarten

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

Ich 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.

Nach 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.

Es 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.

Der menschlichste Teil

Das 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.

Also 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.

Agenten 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.

Nützliche Quellen

• Codex für (fast) alles – OpenAI
• Codex sicher bei OpenAI ausführen
• Wir stellen Codex vor – OpenAI
• Was ist neu beim Copilot-Coding-Agenten von GitHub?