Wie ich mit Codex 15 Projekte reviewe, ohne die manuelle Kontrolle abzugeben

Vor einigen Jahren hätte die Vorstellung, 15 Softwareprojekte gleichzeitig wirklich gründlich zu reviewen, für mich unrealistisch geklungen. Ich meine nicht, 15 Repositories zu öffnen und kurz hineinzuschauen. Ich meine reale Projekte immer wieder auf Bugs, falsche Annahmen, SEO-Probleme, Übersetzungsfehler, Lokalisierungsinkonsistenzen, fehlende Tests, Regressionen und alten Code zu prüfen, der nicht mehr zum Rest des Systems passt.

Der Engpass war nie die Tippgeschwindigkeit. Der Engpass war Aufmerksamkeit. Jedes Projekt hat seine eigene Geschichte, Konventionen, Edge Cases und Stellen, die falsch aussehen können, obwohl sie absichtlich so gebaut wurden. Ein sorgfältiges Review bedeutet lesen, suchen, vergleichen, Checks ausführen und erst dann entscheiden, was überhaupt geändert werden sollte.

Codex hat für mich die Kosten dieser wiederkehrenden Arbeit verändert. Es kann einen ersten Durchgang durch ein Repository machen, Referenzen verfolgen, verwandte Dateien untersuchen, verdächtige Muster sichtbar machen, Testideen liefern und Bereiche untersuchen, die ich sonst Datei für Datei manuell öffnen müsste. Dadurch wird die endgültige Entscheidung nicht automatisch. Aber der teure Teil vor der Entscheidung wird deutlich schneller.

Meine wichtigste Regel ist deshalb einfach: Ich nutze Codex nicht, um mich aus dem Review-Loop zu entfernen. Ich nutze es, um meinen Review-Loop zu vergrößern.

Der eigentliche Engpass ist Wiederholung, nicht das Schreiben von Code

Bei einem einzelnen Projekt kann man erstaunlich viel Kontext im Kopf behalten. Mit vielen Projekten skaliert das nicht mehr. Die gleichen Arten von Arbeit tauchen immer wieder auf:

• ähnliche Bugs in verschiedenen Komponenten suchen;
• prüfen, ob nach einem Refactoring alte Call Sites übrig geblieben sind;
• Tests nach Verhaltensänderungen überprüfen;
• Inkonsistenzen in Metadata, Sprachlogik, Überschriften oder internen Links finden;
• Localization Keys und übersetzte Inhalte vergleichen;
• fehlendes Error Handling und Edge Cases suchen;
• kontrollieren, ob eine „kleine“ Änderung mehr Dateien berührt als erwartet;
• Diffs lesen, die einzeln einfach sind, zusammen aber viel Zeit kosten.

Nichts davon ist spektakulär. Alles davon ist wichtig. Wenn dieselbe Review-Arbeit über viele Codebases wiederholt werden muss, wird sie extrem teuer.

Genau dort ist ein AI Coding Agent für mich besonders nützlich. Er kann den repetitiven Teil des Suchraums übernehmen, damit ich meine Aufmerksamkeit stärker für Urteilsentscheidungen einsetzen kann.

Ich beginne mit Inspektion, nicht mit der Erlaubnis, alles umzuschreiben

Eine der einfachsten Methoden, schlechte Ergebnisse zu bekommen, ist eine riesige Aufgabe wie „reviewe das ganze Projekt und repariere alles“. Das klingt effizient, vermischt aber Discovery, Priorisierung, Architektur, Implementierung und Validierung in einem unkontrollierten Auftrag.

Bessere Ergebnisse bekomme ich, wenn ich die Phasen trenne.

inspect → explain findings → prioritize → change → validate → review diff

Zuerst soll der Agent den relevanten Bereich verstehen und erklären, was er gefunden hat. Ich möchte konkrete Dateipfade, betroffenen Code, die Begründung, warum etwas verdächtig ist, und den möglichen Impact. Änderungen kommen erst danach.

Das ist wichtig, weil AI sehr selbstbewusst falsch liegen kann. Code kann redundant aussehen und trotzdem für einen alten Browser, einen seltenen Payment-Edge-Case, einen Migrationspfad oder eine Business Rule existieren, die aus einer einzelnen Datei nicht erkennbar ist. Die Inspektionsphase gibt mir die Chance, eine falsche Annahme zu stoppen, bevor daraus ein riesiger Diff wird.

Ich behandle Findings als Hinweise, nicht als Urteile

Ein gutes Codex-Review endet nicht mit „17 Probleme gefunden“. Die Zahl allein ist fast bedeutungslos. Mich interessiert Evidenz.

Bei einem wirklich verwertbaren Finding möchte ich wissen:

• wo das Problem liegt;
• warum es ein Problem sein soll;
• welches Verhalten dadurch brechen kann;
• wie sicher die Schlussfolgerung überhaupt ist;
• welcher Check sie bestätigen oder widerlegen kann;
• wie der kleinste sichere Fix aussehen würde.

Das ist besonders bei Security, SEO und Business Logic wichtig. Ein Agent kann auf etwas hinweisen, das untersucht werden sollte, aber eine sicher klingende Erklärung ist noch kein bestätigter Vulnerability Report. Eine SEO-Warnung ist nicht automatisch ein Ranking-Problem. Eine seltsame Bedingung ist nicht automatisch Dead Code.

AI senkt die Kosten, Kandidaten zu finden. Verifikation entscheidet weiterhin, was real ist.

Der Validation Loop macht den Workflow vertrauenswürdig

Codegenerierung ist der sichtbarste Teil von AI-gestützter Entwicklung. Für Production ist die Validierung wichtiger.

Nach einer Änderung soll die Codebase zurücksprechen. Je nach Projekt nutze ich dafür beispielsweise:

• TypeScript oder einen anderen Compiler/Type Checker;
• Linting;
• Unit- und Integrationstests;
• Build Checks;
• gezielte Suche nach alten Namen oder Call Sites;
• manuelles Review des finalen Diffs;
• manuelle Prüfung des sichtbaren Verhaltens.

Die konkreten Commands sind weniger wichtig als der Loop selbst. Der Agent trifft eine Annahme, das Repository liefert Evidenz, und die nächste Entscheidung basiert auf dieser Evidenz.

Darum funktionieren stark typisierte Projekte für mich besonders gut mit AI. Ich habe separat beschrieben, warum TypeScript mit Codex in echter Softwareentwicklung so gut funktioniert: Typen verwandeln viele falsche Annahmen sofort in maschinenlesbares Feedback.

Einige Review-Kategorien eignen sich besonders gut für AI

Bugs und Regressionen

Ein Agent kann Werte über mehrere Dateien verfolgen, Caller untersuchen, ähnliche Implementierungen vergleichen und Branches finden, die sich widersprechen. Das ist hilfreich, um die Quelle eines Symptoms einzugrenzen. Die Schlussfolgerung verifiziere ich trotzdem durch Reproduktion oder andere Checks.

Tests

AI ist gut darin, Verhalten zu finden, das sich geändert hat, ohne dass die Testabdeckung nachgezogen wurde, Edge Cases vorzuschlagen und zu erklären, was ein vorhandener Test tatsächlich schützt. Es kann auch Tests auffallen lassen, die nur Implementierungsdetails statt reales Verhalten prüfen.

SEO

Technisches SEO enthält viel Konsistenzarbeit: Metadata, Sprachalternativen, Indexability-Regeln, interne Links, Seitentemplates, Sitemap-Generierung, Redirects und Page-Level-Konventionen. Ein Agent kann diese Regeln über eine große Codebase schneller vergleichen, als ich jede Route manuell öffnen könnte. Technische Korrektheit trenne ich aber von der schwierigeren Frage, ob der Content selbst überhaupt ranken sollte.

Lokalisierung und Übersetzungen

In multilingualen Produkten ist das eine der repetitivsten Kategorien. AI kann Keys vergleichen, fehlende Werte finden, offensichtliche Sprachmischungen erkennen, Placeholder prüfen und strukturelle Abweichungen zwischen Locales hervorheben. Das ist deutlich schneller als große Translation Objects von Hand zu lesen, auch wenn wichtiger Text weiterhin menschliches Urteil braucht.

Konsistenz nach Refactorings

Große Refactorings scheitern oft auf langweilige Weise: ein alter Import bleibt stehen, eine Route nutzt noch den vorherigen Feldnamen, ein Test Fixture hat noch die alte Struktur. Repository-weite Suche kombiniert mit einem Agenten, der das Ziel der Änderung versteht, ist hier besonders hilfreich.

Parallelität hilft nur bei unabhängigen Aufgaben

Es ist verlockend, viele Agents zu starten und sie alles gleichzeitig ändern zu lassen. Das kann den Durchsatz erhöhen, aber genauso Konflikte und widersprüchliche Annahmen vervielfachen.

Ich sehe Parallelität deshalb als Koordinationsproblem. Unabhängige Audits sind gute Kandidaten: Ein Projekt kann auf Lokalisierung geprüft werden, während ein anderes bei den Tests reviewed wird, oder getrennte Repositories können gleichzeitig untersucht werden. Zwei Agents, die ohne gemeinsamen Plan dieselbe Architektur umschreiben, sind etwas völlig anderes.

Je paralleler die Arbeit wird, desto wichtiger werden Grenzen: ein klares Projekt, eine klare Aufgabe, eine klare Definition of Done und ein Ergebnis, das separat reviewed werden kann.

Das Ziel ist nicht, möglichst viele Agents laufen zu lassen. Das Ziel ist möglichst viel nützlichen, überprüfbaren Fortschritt zu erzeugen.

Was ich nicht blind delegiere

• Architekturentscheidungen: AI kann Optionen vorschlagen, aber langfristige Trade-offs hängen oft von Kontext außerhalb des Repositories ab.
• Security-Schlussfolgerungen: Findings brauchen Verifikation, Threat Context und häufig spezialisierte Tools.
• Business Rules: Code kann intern konsistent sein und trotzdem das falsche Produktverhalten implementieren.
• Große destruktive Refactorings: große Diffs sind schwerer zu verstehen und leichter gedankenlos zu akzeptieren.
• Production Deployment: bestandene Tests entfernen keinen operativen Risk.
• Finales Review: bevor ich meinen Namen unter eine Änderung setze, möchte ich verstehen, was passiert ist.

Nicht weil AI in diesen Bereichen nutzlos ist, sondern weil eine plausible falsche Antwort dort besonders teuer werden kann.

AI Review ersetzt keine statische Analyse

Codex ist für mich kein Ersatz für Compiler, Linter, Tests, Scanner oder Monitoring. Diese Werkzeuge haben einen Vorteil, den AI nicht hat: Sie sind eng definiert, deterministisch und wiederholbar.

Am stärksten ist die Kombination. Codex kann über Kontext nachdenken und zeigen, wo man hinschauen sollte. Statische Tools können exakte Regeln erzwingen. Tests prüfen Verhalten. Logs und Monitoring zeigen die Realität. Human Review verbindet all diese Signale mit der Produktabsicht.

Ohne diese Feedback-Systeme würde ich AI weniger vertrauen, nicht mehr.

Der größte Produktivitätsgewinn ist bessere Verteilung von Aufmerksamkeit

Man kann einfach sagen: „Codex spart Zeit.“ Für mich beschreibt das die Veränderung aber zu schwach.

Die knappste Ressource in Softwareentwicklung sind nicht Keystrokes, sondern hochwertige Aufmerksamkeit. Vor AI Coding Agents ging viel davon für repetitive Discovery drauf: dieselben Patterns suchen, ähnliche Dateien lesen, References verfolgen, prüfen, ob eine Änderung überall angekommen ist, und denselben Audit im nächsten Repository wiederholen.

Heute kann ich mehr von diesem First-Pass delegieren und meine eigene Aufmerksamkeit für schwierigere Entscheidungen aufheben: Ist das Finding relevant? Passt der Fix zur Architektur? Wird die User Experience besser? Ist das Risiko akzeptabel? Will ich diese Änderung wirklich shippen?

Darum fühlt sich die Pflege vieler Projekte heute anders an. Ich reviewe nicht weniger. In vielen Fällen kann ich mehr reviewen, weil der mechanische Teil nicht mehr das gesamte Budget verbraucht.

Der Workflow, dem ich vertraue

1. Ein enges Review-Ziel definieren. Bugs, Tests, SEO, Lokalisierung, Refactoring oder ein anderes konkretes Thema.
2. Vor dem Editieren untersuchen lassen. Zuerst brauche ich Evidenz und betroffene Stellen.
3. Findings priorisieren. Nicht jedes theoretische Problem braucht eine Codeänderung.
4. Änderungen begrenzen. Kleine zusammenhängende Diffs sind leichter zu prüfen.
5. Maschinelle Checks ausführen. Typecheck, Lint, Tests, Build, Search oder projektspezifische Validierung.
6. Diff manuell lesen. Unnötige Rewrites, falsche Annahmen, fehlende Edge Cases und Scope Creep suchen.
7. Wichtiges Verhalten verifizieren. Besonders bei Users, Geld, Security, SEO und Production Infrastructure.
8. Erst dann zum nächsten Projekt. Parallelität ist nützlich, aber ungelöste Unsicherheit sollte nicht weitergetragen werden.

15 Projekte fühlen sich nicht mehr wie das 15-Fache an Review-Arbeit an

Codex hat 15 Projekte nicht einfach gemacht und mir keine Verantwortung abgenommen. Es hat die Beziehung zwischen Skalierung und repetitivem Aufwand verändert.

Ich kann tiefere First Passes, breitere Konsistenzchecks, mehr Testideen und systematischere Audits durchführen, ohne persönlich jede Minute mit der Suche in jeder Datei zu verbringen. Die frei gewordene Aufmerksamkeit kann ich für Entscheidungen nutzen, die weiterhin einen Entwickler brauchen.

Diese Form von AI-assisted Development finde ich wertvoll: kein Autopilot, kein blindes Vertrauen und kein „generiere Code, bis irgendetwas grün wird“. Stattdessen ein engerer Loop zwischen maschineller Inspektion im großen Maßstab und menschlichem Urteil.

Genau das ist für mich der echte Hebel von Codex. Es eliminiert Review nicht. Es macht ernsthaftes Review über einen Umfang möglich, der früher deutlich schwieriger zu halten war.