StartseiteArtikel

OpenAI-Ingenieure schreiben keine Codes mehr: KI schreibt zu schnell, und die menschliche Prüfung kann nicht mitkommen. Agenten übernehmen die gesamte Entwicklung direkt.

AI前线2026-03-09 20:18
Sogar die "Bedienungsanleitung" schreibt der Codex selbst.

OpenAI hat kürzlich in einem Blog einen ziemlich sensationellen Bericht veröffentlicht: Ihre eigenen Ingenieure schreiben kaum noch Code.

In einem internen Projekt haben sie in nur fünf Monaten eine Million Codezeilen produziert, und kein einziger Code wurde von Hand geschrieben. Alles wurde von Codex erstellt.

Dieser Code ist kein loses Skript, sondern eine vollständige interne Beta-Version eines Softwareprodukts, das von Grund auf aufgebaut wurde: von der Anwendungslogik und der Infrastruktur bis hin zu Tools, Dokumentationen und internen Entwicklertools ist fast alles enthalten.

01

Diese Veränderung lässt sich möglicherweise in der Ingenieurkultur von OpenAI finden.

Calvin French-Owen, ein ehemaliger OpenAI-Ingenieur, der am Codex-Projekt beteiligt war, schrieb in einem Blogbeitrag, dass die rasante Expansion des Unternehmens in den letzten Monaten zu einigen Verwirrungen geführt habe.

Dennoch habe es auch weiterhin eine starke Startup-Atmosphäre im Unternehmen gegeben: kleine Teams, schnelle Entscheidungen und hohe Autonomie für die Ingenieure.

Im Gegensatz zu vielen Tech-Riesen, bei denen die Führungsebene die Richtung vorgibt und das Team dann ausführt, gibt es bei OpenAI in der Regel keine klare langfristige Roadmap. Die Forscher entdecken oft selbst Probleme, stellen Ideen vor, und kleine Teams bilden sich um gute Ideen herum und bringen Projekte voran.

Er sagte, dass die besten Ideen, die den Fortschritt antreiben, von überall herkommen können und nicht aus einem grandiosen Plan stammen müssen.

„OpenAI legt großen Wert auf einen bottom-up-Ansatz, insbesondere bei der Forschung.“

Zum Beispiel wurde Codex ursprünglich in einem kleinen Team von nur etwa einem Dutzend Personen entwickelt. Dieses Team hat in sieben Wochen fast ohne Pause Codex von der Idee bis zum Release gebracht.

Das Phänomen, dass die OpenAI-Ingenieure nicht mehr Code schreiben, geht auf ein neues Problem zurück, das ein Team bei der Entwicklung entdeckt hat.

Heutzutage ist AI Coding nichts Ungewöhnliches. Aber nachdem Codex in großem Maßstab Code generiert hat, hat das Entwicklerteam von OpenAI schnell ein neues Problem festgestellt:

Die Codegenerierung ist schnell, aber die Überprüfung des Codes durch Menschen ist langsam.

Die Zeit und Aufmerksamkeit der Menschen sind begrenzt. Im gesamten Entwicklungsprozess ist der engste Teil nun die QA (Qualitätsprüfung).

Um dieses Problem zu lösen, haben die OpenAI-Ingenieure einen anderen Ansatz gewählt: Lassen Sie Codex einfach die Ingenieure imitieren und die Applikation selbst „sehen“ und „verwenden“.

Was tun die OpenAI-Ingenieure also jetzt, wenn sie nicht mehr Code schreiben?

Entwerfen Sie die Umgebung, erstellen Sie Feedback-Schleifen und definieren Sie Architekturbeschränkungen, und lassen Sie dann den Agenten den Code schreiben.

Der Artikel betont: „Der Mensch steuert, der Agent führt aus“.

Sie nennen dies Harness Engineering, was wörtlich übersetzt „AI-Steuerungs-Engineering“ bedeutet.

Die Ingenieure werden zu „Fähigkeitsarchitekten“

Dieses Projekt begann Ende August 2025 mit dem ersten Commit in ein völlig leeres Code-Repository.

Die initiale Architektur, einschließlich der Code-Repository-Struktur, der CI-Konfiguration, der Formatierungsregeln, der Paketmanager-Einstellungen und des Anwendungsframeworks – alles wurde nicht von Hand geschrieben, sondern von Codex CLI unter Verwendung von GPT-5 automatisch generiert.

Sogar die AGENTS.md-Datei, die dem Agenten sagt, wie er in diesem Repository arbeiten soll, wurde von Codex selbst geschrieben.

Mit anderen Worten, seit seiner Entstehung hat dieses System fast keinen handgeschriebenen Code. Das gesamte Code-Repository wurde Schritt für Schritt von Agenten aufgebaut.

Anfangs lief alles nicht so glatt wie erwartet: Der Projektfortschritt war zunächst langsam, aber das Problem lag nicht an der Fähigkeit von Codex, sondern an der Umgebung – die Regeln waren unklar, die Tools unvollständig und die Systembeschränkungen noch nicht etabliert.

Ein Netizen hat es treffend zusammengefasst:

„Das ärgste: Der Agent macht immer wieder die gleichen Fehler, nicht weil er unfähig ist, sondern weil Sie Ihre Urteilsfähigkeit nicht in Code geschrieben haben. Wenn Sie es nicht tun, wird er das Hundertste Mal den gleichen Dummheiten begehen.“

Wenn es bei der Entwicklung zu Staus kommt, fragt das Team nicht mehr, „Können wir einen anderen Code versuchen?“, sondern: Welche Fähigkeiten fehlen dem Agenten?

Machen Sie diese Fähigkeiten zu Regeln, die der Agent verstehen, ausführen und auch zwangsläufig befolgen kann.

Das bedeutet, dass sich die Arbeit der Ingenieure in der heutigen Situation, in der der Agent selbst testen und Fehler beheben kann, von „Code schreiben“ auf etwas anderes verlagert hat: Machen Sie es Codex einfacher, die Dinge richtig zu machen und „ergänzen“ Sie die Fähigkeiten des Agenten.

Von dieser Perspektive aus hat sich die Arbeit der Ingenieure auf eine höhere Ebene verlagert: Mit einem Satz ausgedrückt, zerlegen Sie Aufgaben, entwerfen Sie Fähigkeiten und bauen Sie Systeme auf, damit der Agent stabilen und korrekten Code produzieren kann.

02

Konkret gibt es ungefähr folgende Dinge zu tun:

Erstens müssen Sie die Applikation für die KI lesbar machen.

Wie bereits erwähnt, müssen Sie den Agenten manuell in das Chrome DevTools-Protokoll integrieren, damit er die Benutzeroberfläche „berühren“ kann.

Zweitens müssen die Ingenieure alles „implizite Wissen“ in das Code-Repository schreiben und es in maschinenlesbares Wissen umwandeln.

Für den Agenten existiert alles, was er zur Laufzeit nicht zugreifen kann, nicht. Informationen, die in Google Docs, Chatverläufen oder im Kopf der Menschen gespeichert sind, können nicht vom System abgerufen werden.

Allerdings sollten Sie nicht alle Regeln und Anweisungen auf einmal an Codex geben. Stattdessen sollten Sie ihm zuerst eine Navigation geben und ihm dann ermöglichen, die Details selbst zu recherchieren.

Das Forschungsteam hat versucht, dem Agenten eine riesige AGENTS.md-Datei zu geben, aber schnell festgestellt, dass dies nicht funktioniert.

Der Hauptgrund ist, dass der Kontext eine knappe Ressource ist. Je dicker die Anleitung, desto leichter wird die wirklich wichtige Information untergehen. Außerdem wird diese große Dokumentation schnell veraltet und ist schwer zu überprüfen und zu warten.

Sie haben diese Erfahrung in einem Satz zusammengefasst:

„Geben Sie Codex eine Karte, nicht ein 1000-seitiges Handbuch.“

Dieses Schema wurde von KI generiert

Drittens müssen die Ingenieure eine KI-freundliche Architektur entwerfen.

KI ist in Systemen mit klarer Struktur und definierten Grenzen am effizientesten. Für Menschen können diese Regeln scheinen zu restriktiv, aber für den Agenten sind sie ein Effizienzvervielfacher.

Das OpenAI-Team hat daher eine strenge Architektur entworfen, bei der jedes Geschäftsgebiet in festen Ebenen organisiert sein muss: Types → Config → Repo → Service → Runtime → UI.

Die Abhängigkeitsrichtung ist verpflichtend. Jegliche Verletzung wird automatisch verhindert.

Viertens müssen Sie „Geschmack“ in Regeln umwandeln.

„In der Ära der KI ist der Geschmack die wichtigste Fähigkeit des Menschen.“ Solche Äußerungen hören wir immer häufiger, je stärker die großen Modelle werden.

In diesem Blogbeitrag gibt es ein sehr interessantes Konzept: taste invariants (Geschmacksinvarianten).

Das bedeutet, dass der ästhetische Geschmack der Ingenieure, wie Dateigrößenbeschränkungen, Benennungsregeln, Protokollstrukturen, API-Spezifikationen usw., in lint-Regeln umgewandelt wird.

So wird die KI automatisch bei jedem Code-Schreiben diese Regeln befolgen: „Sobald der menschliche Geschmack erfasst ist, kann er auf jede Codezeile angewendet werden.“

In der praktischen Entwicklung interagiert der Mensch hauptsächlich über Hinweise mit dem System: Beschreiben Sie die Aufgabe, starten Sie den Agenten, und lassen Sie Codex automatisch einen Pull Request generieren.

Der gesamte anschließende Prozess, einschließlich der Code-Selbstüberprüfung, der Agenten-Bewertung, der Anpassung basierend auf Feedback und der erneuten Einreichung, wird im Wesentlichen vom Agenten selbst durchgeführt und wiederholt sich, bis alle Bewertungen bestanden sind.

Fünftens müssen Sie das „Müll“ entfernen, den die KI erzeugt hat.

Der Artikel weist darauf hin, dass vollautonome Agenten auch neue Probleme mit sich bringen.

Nachdem fast der gesamte Code von Codex generiert wurde, ist ein neues Problem aufgetreten: Die KI kopiert ständig die Muster im Code-Repository, einschließlich schlechter Schreibweisen. Mit der Zeit verändert sich der Code-Style langsam.

Anfangs plante das Team, einmal pro Woche einen Tag für die manuelle Entfernung dieses „KI-Rückstands“ einzusetzen, aber schnell feststellten sie, dass diese Methode nicht skalierbar ist.

Später haben sie die Erfahrungen und Präferenzen der Ingenieure in eine Reihe von „Goldenen Regeln“ umgewandelt, wie die bevorzugte Verwendung von gemeinsamen Toolkits und die strenge Überprüfung von Datenstrukturen anstelle von „Raten“.

Diese Regeln werden dann direkt in das Code-Repository codiert, damit Codex automatisch Probleme erkennt und einen Refactoring-Pull Request initiiert.

So wird dem Code-Repository eine Art „Müllabfuhrmechanismus“ hinzugefügt: Kleine Probleme können sofort behoben werden, und technische Schulden wachsen nicht unkontrolliert.

Dieser Blogbeitrag hat in der technischen Community breites Interesse und Diskussion ausgelöst. Einige sind der Meinung, dass Harness Engineering im Wesentlichen eine moderne Version der Kybernetik ist: Die Ingenieure schreiben nicht mehr direkt Code, sondern entwerfen Systeme, Regeln und Feedback-Schleifen, damit der Agent die Arbeit automatisch erledigt.

Er sagte, dass dieses Muster in der Geschichte bereits dreimal aufgetreten sei.

Von der Regler des Watt'schen Dampfmaschinen bis zum Kubernetes-Controller und schließlich zum heutigen KI-Agenten: Die echte Veränderung besteht nicht darin, dass die Maschine den Menschen ersetzt, sondern darin, dass die Rolle des Menschen sich von Ausführenden zu Designer und Kalibrierer des Systems wandelt:

„Sie drehen nicht mehr selbst das Ventil, sondern steuern das Schiff.“

Wenn immer dieses Muster auftritt, liegt es in der Regel daran, dass jemand stark genug Sensoren und Aktoren entwickelt hat, um die Feedback-Schleife auf dieser Ebene wirklich zu schließen.“

Agenten übernehmen bereits den gesamten Entwicklungsprozess

03

Warum können die OpenAI-Ingenieure nicht mehr Code schreiben? Schauen wir uns an, welche Fähigkeiten der Agent bereits hat.

Wie bereits erwähnt, haben die OpenAI-Ingenieure einen anderen Ansatz gewählt: Lassen Sie Codex einfach die Ingenieure imitieren und die Applikation selbst „sehen“ und „verwenden“.

Erstens müssen Sie den Agenten in die Lage versetzen, die Benutzeroberfläche (UI) zu sehen.

Sie haben das Chrome DevTools-Protokoll in die Laufzeitumgebung des Agenten integriert. Dadurch kann Codex wie ein Entwickler im Browser agieren: er kann die Seite bedienen, Logs lesen, das DOM erfassen, Screenshots machen und die Benutzeroberfläche beobachten...

Dieser Schritt ist sehr wichtig, da LLM selbst die UI nicht sehen kann.

Nach der Integration von DevTools hat Codex quasi „Augen“ und „Hände“:

Er kann die Seite über Screenshots und das DOM beobachten, den Laufzustand über die Konsole und das Netzwerk überwachen und selbst klicken, eingeben und navigieren.