In der Softwareentwicklung verschiebt sich die Arbeitsteilung. Nicht mehr nur das Schreiben von Code wird an KI-Werkzeuge delegiert, sondern auch das, was danach kommt: Tests formulieren, Änderungen durchsehen, Schwachstellen benennen. In einem Podcast-Gespräch sprechen Richard Seidl und Benedikt Stemmildt über Agenten, die sich selbst verbessern – und darüber, warum Codex manchmal der beste Reviewer für Claude Code ist.

Diese Beobachtung ist unspektakulär formuliert und trotzdem der interessante Punkt. Denn sie beschreibt eine Konstellation, die im Projektalltag neu ist: Zwei unterschiedliche Systeme arbeiten nicht nebeneinander, sondern übereinander. Das eine erzeugt einen Änderungsvorschlag, das andere prüft ihn.

Warum ein zweites Modell überhaupt etwas findet

Ein Code-Review lebt davon, dass jemand mit anderem Blick hineinschaut. Wer eine Lösung selbst entworfen hat, trägt die Annahmen dieser Lösung mit sich – und übersieht deshalb bestimmte Fehler systematisch. Das gilt für Menschen, und es gilt offenbar in ähnlicher Form für KI-Modelle: Ein Agent, der seine eigene Ausgabe prüft, bleibt in der gleichen Denkspur.

Genau hier liegt der praktische Wert unterschiedlicher Werkzeuge. Ein anderes Modell, anders trainiert und anders auf Aufgaben abgestimmt, bringt andere Prioritäten mit. Es kommentiert womöglich, was das erste Modell für selbstverständlich gehalten hat. Das ist kein Wunderheilmittel, aber es ist mehr als ein Doppelklick auf denselben Knopf.

Selbstverbesserung ist kein Automatismus

Der zweite Begriff aus dem Gespräch – Agenten, die sich selbst verbessern – klingt größer, als er im Projektalltag zunächst ist. Gemeint ist im Kern ein Regelkreis: Ein Agent erzeugt etwas, erhält Rückmeldung, passt seinen nächsten Versuch an. Diese Rückmeldung kann von Tests kommen, von einem Build, von einem Linter oder eben von einem zweiten Agenten.

Entscheidend ist, dass dieser Regelkreis überhaupt ein belastbares Signal hat. Ohne automatisierte Tests, ohne klare Definition von "fertig" und ohne reproduzierbare Umgebung dreht sich die Schleife im Leeren. Ein Agent, der auf eine unklare Rückmeldung reagiert, produziert mehr Änderungen – nicht bessere.

Für Projekte heißt das: Die Voraussetzungen für sinnvolle Agentenarbeit sind ziemlich genau dieselben, die gute Softwareentwicklung ohnehin ausmachen. Eine ordentliche Testabdeckung, eine funktionierende Continuous-Integration-Strecke – also der automatische Bau- und Testlauf bei jeder Änderung – und saubere Grenzen zwischen Modulen zahlen sich nun doppelt aus.

Was Kundinnen und Kunden davon merken

Aus Auftraggebersicht ist die technische Konstellation weniger interessant als ihre Wirkung. Die liegt vor allem in der Durchlaufzeit. Ein Review, das früher auf die Verfügbarkeit einer zweiten Person gewartet hat, kann in Teilen sofort passieren. Kleine Auffälligkeiten – vergessene Fehlerbehandlung, unsaubere Benennungen, fehlende Testfälle – werden gefunden, bevor ein Mensch den Vorgang öffnet.

Damit verschiebt sich die Rolle des menschlichen Reviews nach oben: weg von Formalien, hin zu Architektur, fachlicher Korrektheit und Fragen, die nur mit Kenntnis des Geschäftsmodells zu beantworten sind. Das ist die eigentliche Effizienz, nicht das Einsparen von Personen.

Gleichzeitig entsteht ein neues Risiko. Wenn Änderungen schneller entstehen und schneller durchgewinkt werden, wächst die Menge an Code, die niemand wirklich gelesen hat. Ein Agenten-Review ist ein zusätzliches Netz, kein Ersatz für Verantwortung. Wer freigibt, haftet – technisch, vertraglich und gegenüber den eigenen Nutzerinnen und Nutzern.

Was ein sauberes Setup ausmacht

Aus der Praxis lassen sich einige Leitlinien ableiten, die unabhängig von den konkret eingesetzten Werkzeugen gelten:

  • Rollen trennen. Der Agent, der eine Änderung erzeugt, sollte nicht derselbe sein, der sie abschließend bewertet.
  • Automatisierte Prüfungen zuerst. Tests, Build, statische Analyse laufen vor jedem Modell-Review. Was eine Maschine deterministisch prüfen kann, muss kein Sprachmodell einschätzen.
  • Menschliche Freigabe verankern. Für Änderungen an Schnittstellen, Datenmodellen, Berechtigungen und Bezahlvorgängen bleibt die Entscheidung bei einer Person.
  • Nachvollziehbarkeit sichern. Welcher Agent hat welchen Hinweis gegeben, was wurde übernommen, was verworfen? Ohne Protokoll fehlt die Grundlage für spätere Fehlersuche.
  • Datenfluss klären. Welcher Quellcode verlässt das eigene System und wandert zu welchem Anbieter? Diese Frage gehört vor die Werkzeugauswahl, nicht danach.

Werkzeuge kommen und gehen

Die Namen in dieser Diskussion werden sich ändern. Welches Modell heute als der bessere Prüfer für welche Aufgabe gilt, kann in wenigen Monaten anders aussehen – und genau deshalb lohnt es sich, nicht auf ein einzelnes Produkt zu optimieren.

Stabil bleibt die Struktur: definierte Schritte, austauschbare Werkzeuge, klar zugeordnete Verantwortung. Ein Team, das seinen Entwicklungsprozess so aufgebaut hat, kann einen Agenten ersetzen, ohne den Ablauf neu zu erfinden.

Für Web- und Softwareprojekte bedeutet das: Der Nutzen von KI-Agenten im Review hängt weniger vom Modell ab als von der Qualität der Pipeline, in die es eingebettet ist. Wer Tests, Automatisierung und Freigabewege ordentlich aufgesetzt hat, gewinnt Tempo, ohne Prüftiefe abzugeben. Wer sie nicht hat, beschleunigt lediglich die Produktion von ungeprüftem Code – und merkt das erst im Betrieb.

Quellen