OpenAI-Codex-Team liefert Millionen-Zeilen-Produkt ohne eine Zeile von Menschenhand

Die Vorgabe, die alles geprägt hat: kein manuell geschriebener Code

Der erste Commit landete Ende August 2025 in einem leeren Repository. Fünf Monate später umfasst das Repository laut Blogpost rund eine Million Zeilen Code — keine davon wurde von einem Menschen eingetippt. Selbst das ursprüngliche Grundgerüst — Repository-Struktur, CI-Konfiguration, Formatierungsregeln, Package-Setup — wurde von der Codex CLI mit GPT-5 generiert, und selbst die erste AGENTS.md, die Agenten erklärt, wie im Repository gearbeitet wird, wurde vom Agenten selbst verfasst.

Das Team berichtet von rund 1.500 gemergten Pull Requests, im Schnitt 3,5 PRs pro Ingenieur und Tag, und einer Teamgröße, die von drei auf sieben Ingenieure wuchs — während der Durchsatz stieg statt zu sinken. Das Produkt hat Hunderte interne Nutzer und tägliche Power-User, es geht hier also nicht um Output als Selbstzweck.

Die Regel 'kein manuell geschriebener Code' wirkt wie ein Kunstgriff, doch der Blogpost stellt klar, dass sie bewusst als erzwingender Mechanismus gewählt wurde. Wenn Menschen Probleme nicht durch Eintippen lösen können, wird jeder Fehler zu einer Frage an die Umgebung statt an den Code: Welche Fähigkeit fehlt, und wie machen wir sie für den Agenten sichtbar und durchsetzbar?

Die laufende Anwendung für den Agenten lesbar machen

Der Flaschenhals, auf den das Team stieß, war nicht Codex' Fähigkeit, Code zu schreiben — sondern die menschliche QA-Kapazität. Ihre Antwort war, dem Agenten direkten Zugriff auf das zu geben, was sich normalerweise ein Mensch ansieht. Sie machten die App pro Git-Worktree startfähig, sodass Codex für jede Änderung eine eigene Instanz starten konnte, banden das Chrome DevTools Protocol in die Agenten-Laufzeitumgebung ein und bauten Skills für DOM-Snapshots, Screenshots und Navigation.

Dasselbe taten sie für Observability. Jeder Worktree erhält einen kurzlebigen lokalen Stack aus Logs, Metriken und Traces, der nach Abschluss der Aufgabe wieder abgebaut wird. Weil der Agent Logs per LogQL und Metriken per PromQL abfragen kann, werden Vorgaben wie 'der Service-Start soll in unter 800 ms abgeschlossen sein' oder 'kein Span in diesen vier kritischen User-Journeys darf zwei Sekunden überschreiten' zu handhabbaren Anweisungen statt bloßen Wünschen.

Das ist der tragende Gedanke im Blogpost: Wie der Autor es formuliert, existiert aus Sicht des Agenten alles, worauf er nicht im Kontext zugreifen kann, effektiv nicht. Wissen in Slack-Threads, Google Docs oder in den Köpfen von Menschen ist unsichtbar. Deshalb behandelt das Team ein strukturiertes docs/-Verzeichnis als verbindliche Quelle der Wahrheit und hält AGENTS.md bei rund 100 Zeilen — ein Inhaltsverzeichnis, keine Enzyklopädie — mit einem wiederkehrenden 'Doc-Gardening'-Agenten, der Korrektur-PRs öffnet, wenn die Dokumentation vom tatsächlichen Verhalten abweicht.

Starre Architektur als Beschleuniger, nicht als Bremse

Das Team umgab die Codebasis mit Beschränkungen, die die meisten Organisationen erst einführen, wenn sie Hunderte Ingenieure beschäftigen. Jede Fachdomäne ist in feste Schichten aufgeteilt — Types, Config, Repo, Service, Runtime, UI —, wobei Abhängigkeiten nur vorwärts fließen dürfen, und übergreifende Belange wie Auth und Telemetrie müssen zwingend über eine einzige Providers-Schnittstelle laufen. Alles andere ist untersagt und wird mechanisch durch eigene Linter geprüft, die natürlich ebenfalls von Codex generiert wurden.

Die Logik dreht den üblichen Zielkonflikt um. Strikte Grenzen wirken in einem menschlichen Workflow pedantisch; hier wirken sie als Multiplikator, denn sobald eine Regel kodiert ist, gilt sie überall gleichzeitig. Individuelle Lint-Fehlermeldungen speisen sogar Korrekturanweisungen direkt zurück in den Agenten-Kontext, sodass ein Verstoß zu einer sich selbst korrigierenden Schleife wird statt zu einem blockierten PR.

Das ist die Art von Architektur, die man normalerweise aufschiebt, bis man Hunderte Ingenieure hat. Mit Coding-Agenten ist sie eine frühe Voraussetzung: Die Beschränkungen sind das, was Geschwindigkeit ohne Verfall oder architektonische Drift ermöglicht.Montana Labs

Bemerkenswert ist, dass das Team Grenzen zentral durchsetzt, die Umsetzung aber offenlässt. Sie verlangen, dass Datenformen an den Grenzen geprüft werden, schreiben aber keine bestimmte Bibliothek vor — das Modell entschied sich von selbst für Zod. Sie haben sich außerdem entschieden, kleine Utilities wie einen Concurrency-Helper selbst neu zu implementieren, statt ein generisches Package einzubinden, weil eine repo-interne Version vollständig einsehbar und in die eigene Instrumentierung integriert ist. 'Langweilige' Technologie gewinnt hier, weil sie stabil, kombinierbar und in den Trainingsdaten gut repräsentiert ist.

Entropie ist der wiederkehrende Preis, und das Aufräumen läuft jetzt automatisiert

Volle Autonomie schuf einen neuen Fehlermodus: Codex repliziert bestehende Muster originaltreu — auch die schlechten —, sodass die Codebasis abdriftet. Das Team verbrachte anfangs jeden Freitag, also ein Fünftel der Woche, damit, das aufzuräumen, was sie 'AI Slop' nennen. Das skalierte offensichtlich nicht.

Ihre Lösung war, klare 'Golden Principles' direkt im Repository zu verankern und im Hintergrund laufende Codex-Aufgaben in regelmäßigem Takt Abweichungen scannen, Qualitätsbewertungen aktualisieren und gezielte Refactoring-PRs öffnen zu lassen — die meisten davon in unter einer Minute prüfbar und automatisch gemergt. Sie beschreiben technische Schulden als einen hochverzinsten Kredit, der am besten in kleinen täglichen Raten abgetragen wird. Menschlicher Geschmack wird einmal erfasst und dann kontinuierlich auf jede Zeile angewendet.

Die Merge-Philosophie verändert sich entsprechend. Blockierende Gates sind minimal, PRs sind kurzlebig, und flackernde Tests werden mit Folgeläufen behandelt statt mit dauerhafter Blockade. Das Team gibt offen zu, dass das in einer Umgebung mit niedrigem Durchsatz unverantwortlich wäre; es funktioniert nur, weil Korrekturen billig sind und Warten die teure Option ist.

Die konkrete Lehre: Das Harness ist das Produkt, das Ingenieure jetzt bauen

OpenAI grenzt die Aussage bewusst ein. Man betont, dass die durchgängige Feature-Autonomie — einen Bug reproduzieren, ein Video des Fehlers aufzeichnen, ihn beheben, durch Bedienen der App validieren, ein Lösungsvideo aufzeichnen, den PR öffnen und mergen — 'stark von der konkreten Struktur und dem Tooling dieses Repositorys abhängt und nicht ohne vergleichbare Investition als übertragbar angenommen werden sollte.' Man gibt außerdem zu, noch nicht zu wissen, wie sich architektonische Kohärenz über Jahre in einem vollständig agentengenerierten System hält.

Die übertragbare Erkenntnis sind nicht die Million Zeilen. Es ist, dass sich die Ingenieursarbeit dieses Teams fast vollständig in den Bau der Umgebung verlagert hat, in der der Agent operiert: App-Instanzen pro Worktree, kurzlebige Observability, strukturierte versionierte Dokumentation, mechanisch durchgesetzte Schichtung und sich selbst korrigierende Lint-Meldungen. Jedes Mal, wenn Codex an seine Grenzen stieß, war die Antwort, ein fehlendes Werkzeug, eine Leitplanke oder ein Dokument hinzuzufügen — und Codex diese Lösung ebenfalls schreiben zu lassen.

Für jedes Team, das agentenzentrierte Entwicklung erwägt, liegt das ehrliche Kostensignal in diesem Blogpost im Gerüst, nicht im Prompting. Der Flaschenhals war menschliche Aufmerksamkeit, und alles, was sie gebaut haben, war der Versuch, weniger davon zu verbrauchen. Die Frage, die es weiterzudenken gilt, ist, wie viel dieser Harness-Investition sich ein kleineres Team leisten kann, bevor der Durchsatz sie wieder auszahlt.