Qodo-Plugin für Codex bringt Kontext aus dem Code-Review in die Programmiersitzung

Codex den Blick auf das Gesamtsystem geben

Itamar Friedman, Mitgründer und CEO von Qodo, nennt das Produkt seines Unternehmens "den besten Freund des Coding-Agenten". Das Problem, auf das es zielt, ist die Größenordnung. Friedman beschreibt Kundenumgebungen mit 10.000 oder mehr Repositories, in denen eine lokale Codeänderung einen nachgelagerten Dienst beeinträchtigen kann, auch wenn sie für sich genommen korrekt aussieht.

"Codex ist wirklich gut darin, eine lokale Aufgabe aufzugreifen und effizient zu erledigen", sagt Friedman. Qodos Plugin ergänzt den Zugriff auf Wissen über die Codebasis, organisationsweite Regeln und unabhängiges Review über Qodos Agentic Toolbox. Mit diesem Kontext kann Codex Abhängigkeiten zwischen Repositories berücksichtigen, auch wenn diese bei unterschiedlichen Git-Anbietern liegen oder Dienste über Kafka verbunden sind.

"Qodo stellt diese Verbindung her und hilft Codex, die Software als Ganzes zu betrachten und diese P0-Bugs nicht zu übersehen", sagt Friedman.

Review in derselben Sitzung

Der Workflow besteht aus zwei Schritten. Bevor Codex Code schreibt, kann es über das Plugin relevante Regeln der Codebasis abrufen, ebenso wie die Historie und Muster früherer Pull Requests. Nachdem Codex seine Änderungen vorgenommen hat, prüft Qodo sie und gibt seine Ergebnisse noch in derselben Sitzung direkt an Codex zurück, bevor der Entwickler einen Pull Request öffnet.

Nnenna Ndukwe, AI Developer Relations Lead bei Qodo, beobachtet, dass Entwickler diese Konstellation nutzen, um mit GPT-6-Modellen in Codex Features zu bauen und technische Schulden abzutragen. Dabei automatisieren sie die Übergabe zwischen Codex' Programmierarbeit und Qodos unabhängigem Review.

Friedman bezeichnet Coding- und Review-Agenten als "Yin und Yang": Der eine erzeugt Code, der andere stellt ihn infrage. Jede Rolle braucht ein eigenes Setup und eigenen Kontext und kann mehrere Agenten umfassen. Seine Vision ist, dass die Agenten ihre Befunde miteinander besprechen und "nur das nach oben reichen, was sie nicht akzeptieren", damit Menschen es prüfen. Entwickler wären dann Planer und Reviewer und könnten ungelöste Probleme zusammen mit der Diskussion der Agenten, dem Kontext und früheren Entscheidungen von Entwicklern einsehen. "So schafft man Vertrauen", sagt er.

Alltagsnutzung und die Decisions API

Bei Qodo nutzt Ndukwe die Effort-Einstellungen Extra High und Ultra von GPT-6 Astra in ihren eigenen automatisierten Entwicklungsworkflows und bei der Wissensarbeit. Sie lässt Codex regelmäßig berichten, was sie in der Woche erreicht hat und worauf sie sich als Nächstes konzentrieren könnte, Diskussionen über Agentic Engineering auf sozialen Plattformen recherchieren sowie ihre Codeänderungen analysieren und Agent Skills vorschlagen, die sie anlegen oder verfeinern kann.

Friedman sieht zudem eine Rolle für OpenAIs kürzlich gestartete Decisions API. Statt sich bei jeder Entscheidung auf Sprachmodelle zu verlassen, könnte Qodo damit auswählen, welche Regeln und Agent Skills in welcher Entwicklungsphase gelten. In seinem Beispiel könnte die API bestimmen, welche von 200 Regeln geprüft werden müssen, bevor ein Sprachmodell die relevanten durchdenkt. Friedman zufolge würde das die Auswahl schneller und günstiger machen und zugleich die Review-Qualität verbessern.

Was das für Entwickler bedeutet

Qodos Ansatz ist eine Arbeitsteilung: Unternehmenswissen leitet die Coding-Agenten an, unabhängiges Review prüft deren Arbeit, und menschliche Expertise klärt die verbleibenden Fragen. Friedman beschreibt das Ergebnis als Software-Fabrik, ein System, das Kunden selbst zusammenstellen und besitzen könnten und das Coding- und Review-Agenten mit einem Verständnis dafür verbindet, wie sich Software in der Produktion verändert.

Für Teams, die über viele Repositories hinweg arbeiten, soll das Plugin dienstübergreifende Probleme abfangen, bevor ein Pull Request geöffnet wird, und Entwickler auf die Fragen konzentrieren, die die Agenten nicht selbst klären können.