OpenAI hat auch die Erfahrungen von Ingenieuren in Skills "destilliert". Der Autor eines viral gewordenen Artikels von Harness hat interne Vorgehensweisen preisgegeben: Ein System mit einer Million Codezeilen wurde ganz ohne manuelle Codierung und Prüfung erstellt.
Kürzlich hat Ryan Lopopolo von OpenAI einen langen Artikel mit dem Titel „Harness engineering“ veröffentlicht, der zu einem heißen Thema in der Branche geworden ist.
In diesem Artikel hat Ryan zum ersten Mal systematisch aufgezeigt, wie das kürzlich gegründete Frontier-Team von OpenAI tatsächlich arbeitet: Das Team ist heute der intensivste Nutzer von Codex innerhalb von OpenAI. Sie unterhalten eine Codebasis mit mehr als einer Million Zeilen Code – und in dem gesamten System gibt es keine einzige Zeile manuell geschriebenen Code. Entscheidender ist noch: Vor dem Zusammenführen des Codes gibt es auch keine menschliche Code-Überprüfung.
Ryan verfolgt diesen Ansatz mit fast missionarischer Leidenschaft. Er sagt sogar offen: Wenn du heute nicht täglich mehr als eine Milliarde Tokens verbrauchst, bist du fast schon „beruflich nachlässig“. Nach aktuellen Marktpreisen und Annahmen zur Zwischenspeicherung entspricht das etwa täglichen Token-Kosten von zwei- bis dreitausend US-Dollar.
In den vergangenen Monaten haben sie ein extrem radikales Experiment durchgeführt: Sie haben von Grund auf ein internes Testprodukt erstellt und ausgeliefert – in dem gesamten Prozess wurde keine einzige Zeile Code von Menschen geschrieben. Aus diesem Experiment haben sie nach und nach eine völlig andere Arbeitsweise für das Engineering entwickelt: Wenn ein Agent scheitert, überlegen sie nicht mehr „Probier mal eine andere Prompt“ oder lassen ihn „noch härter arbeiten“, sondern fragen stattdessen umgekehrt: Welche Fähigkeit, welcher Kontext oder welche Strukturebene fehlt hier eigentlich?
Das Experiment hat schließlich Symphony hervorgebracht. Ryan bezeichnet es als „Geisterbibliothek“ (ghost library), gleichzeitig handelt es sich um eine referenzielle Implementierung in Elixir, erstellt von Alex Kotliarskyi. Seine Aufgabe ist es, ein gesamtes großes Codex-Agent-System aufzubauen. Jeder Agent erhält extrem detaillierte Prompt-Informationen, deren Detaillierungsgrad fast einem echten Produktanforderungsdokument entspricht, ohne jedoch die vollständige Implementierung direkt vorzugeben.
So wird die Kontur der Zukunft immer klarer: Coding-Agents sind nicht mehr nur der Beifahrer neben dir (Copilot), sie entwickeln sich allmählich zu einem echten „Teammitglied“, das jeder wirklich aufrufen kann. Und Codex baut kontinuierlich in dieser Richtung auf und sendet sogar eine starke Botschaft nach außen: Du musst nur direkt mit dem Aufbau anfangen.
Ryan treibt schon lange eine Frage voran: Was passiert, wenn du Codebasen, Arbeitsabläufe und Organisationen nicht mehr nach den Nutzungsgewohnheiten von Menschen optimierst, sondern stattdessen auf die Lesbarkeit für Agenten ausrichtest?
Während eines Podcasts bei Latent Space und AI Engineer hat er detailliert geteilt, wie das Konzept des Harness Engineering ursprünglich entstanden ist, und welche zentrale Randbedingung den Start des gesamten Experiments bestimmt hat: Ryan hat sich von Anfang an bewusst dazu entschieden, selbst keinen Code zu schreiben – er hat den Agenten gezwungen, die Arbeit von Anfang bis Ende selbst zu erledigen.
Außerdem geht es darum, wie interne Teams von OpenAI Codex tatsächlich nutzen; warum in der KI-nativen Softwareentwicklung die menschliche Aufmerksamkeit zum echten Flaschenhals geworden ist; warum sie so besessen von Baugeschwindigkeit sind: warum „eine Minute“ als Obergrenze für die innere Schleife (inner loop) festgelegt wurde und wie das Team das Build-System immer wieder neu aufbaut, nur damit der Agent konstant effizient produzieren kann.
Wir haben das Originalgespräch übersetzt und aufbereitet, ohne den ursprünglichen Sinn zu verändern, und haben es teilweise gekürzt, um es unseren Lesern zugänglich zu machen.
Mit unbegrenzten Tokens Produkte ohne manuell geschriebenen Code bauen
swyx: Du hast kürzlich einen wichtigen Artikel über Harness Engineering geschrieben, er wird wahrscheinlich zu dem repräsentativsten Artikel für diesen aufstrebenden Bereich.
Ryan Lopopolo: Danke. Ich finde das Thema ziemlich interessant – es scheint, als hätten wir irgendwie den Rahmen für diese Diskussion wirklich schon zuerst aufgestellt.
swyx: Das ist dein erster Podcast-Auftritt. Erzähl uns erstmal: In welchem Team arbeitest du heute? Was machst du dort?
Ryan Lopopolo: Klar. Ich bin heute im Team „Frontier Product Exploration“ und arbeite an der Entwicklung neuer Produkte im Rahmen von OpenAI Frontier. OpenAI Frontier ist im Grunde unsere Unternehmensplattform, mit dem Ziel, dass Unternehmen Agents in großem Maßstab, kontrollierbar und sicher einsetzen können. Unser Team hat die Aufgabe, neue Methoden zu erforschen, wie man Modelle zu Produkten und Lösungen verpackt, für die Unternehmen wirklich bezahlen wollen.
swyx: Lass mich ergänzen, was deinen Hintergrund angeht: Du hast vorher bei Snowflake, Brex, Stripe und Citadel gearbeitet.
Ryan Lopopolo: Ja, im Grunde habe ich mein ganzes Berufsleben lang Unternehmenskunden bedient.
Vibhu: Ich muss sagen, als ich vorher deinen Twitter gelesen habe, hätte ich diesen Hintergrund nicht erwartet. Online wirkst du total wie jemand, der voll auf KI und voll auf Coding setzt – der sogar sitzend in einem Waymo den Laptop auf den Beinen hält und weiterarbeitet. Als ich dann deinen Lebenslauf gesehen habe, war ich total überrascht – und dann dachte ich: „Oh, das ist aber eigentlich total logisch.“
Ryan Lopopolo: Ich denke, wenn du wirklich ein extrem KI-affiner Mensch werden willst, ist OpenAI tatsächlich der am besten geeignete Ort dafür.
swyx: An Tokens mangelt es euch ja nicht, richtig?
Ryan Lopopolo: Genau. Intern gibt es keine Ratenbegrenzung, das hilft wirklich extrem. Also kann ich wirklich komplett all-in gehen, wie du gesagt hast.
swyx: Also seid ihr unter Frontier ein relativ besonderes Team?
Ryan Lopopolo: Genau. Das Unternehmen hat uns tatsächlich einen Raum gegeben, in dem wir „uns selbst ausprobieren“ können – das ist ziemlich spannend.
Deshalb habe ich mir von Anfang an eine klanglich etwas übertriebene Randbedingung gesetzt: Ich schreibe selbst keinen einzigen Code. Meine Idee ist einfach: Wenn wir Agents bauen wollen, die später tatsächlich in Unternehmen eingesetzt werden können, dann müssen sie die Dinge erledigen können, die ich normalerweise mache. Nachdem ich schon mehrere Monate mit diesen Coding-Modellen und Coding-Harness gearbeitet habe, habe ich tatsächlich das Gefühl, dass sowohl das Modell selbst als auch die Fähigkeiten des Harness bereits so weit entwickelt sind, dass sie mir in gewisser Weise „isomorph“ sind. Das heißt, was die Arbeitsfähigkeit angeht, sind sie mir bereits nahe genug.
Wenn ich mir also von Anfang an die Randbedingung auferlege, dass ich keinen Code selbst schreiben darf, bleibt mir nur ein einziger Weg, um meine Arbeit zu erledigen: Ich muss den Agenten die Arbeit für mich erledigen lassen.
Wenn das Modell nicht weiterkommt, liegt das Problem nicht unbedingt am Prompt
Vibhu: Das ist eigentlich das Kernexperiment deines Artikels. Ihr hab über mehrere Monate ein internes Tool entwickelt, ohne dass Menschen Code von Hand geschrieben haben – die gesamte Codebasis umfasst mehr als eine Million Zeilen. Du sagst auch, das ging im Grunde sogar schneller, als wenn du es selbst geschrieben hättest. Das war also von Anfang an eure Idee?
Ryan Lopopolo: Ja, genau das meine ich.
Wir haben am Anfang noch eine sehr frühe Version der Codex CLI verwendet, kombiniert mit dem Codex Mini-Modell. Es ist natürlich bei weitem nicht so stark wie die Modelle, die wir heute haben – aber das war eigentlich eine gute Randbedingung. Denn das Gefühl ist sehr direkt: Du lässt das Modell eine Produktfunktion für dich bauen, und es kriegt es einfach nicht hin, es kann die Teile nicht zu einem Ganzen zusammenfügen.
Genau diese Frustration hat uns dazu gezwungen, allmählich eine Vorgehensweise zu entwickeln: Wenn das Modell es einfach nicht schafft, musst du die Aufgabe sofort zerlegen, tief einsteigen und kleinere Basiskomponenten bauen, bevor du sie wieder zu dem großen Ziel zusammenfügst.
Ehrlich gesagt war dieser Prozess am Anfang sehr schmerzhaft. Im ersten Monat lag die Geschwindigkeit nur bei einem Zehntel von der, wenn ich selbst normal Code schreibe. Aber weil wir diese „Lernkosten“ am Anfang bezahlt haben, konnten wir später ein gesamtes Toolset und einen Build-Stack aufbauen, der es dem Agenten schließlich erlaubt, die ganze Sache durchzuziehen. Und sobald dieses System steht, ist seine Produktivität weit höher als die eines einzelnen Ingenieurs.
Später haben wir alle Modellentwicklungen von GPT-5 über 5.1, 5.2, 5.3 bis 5.4 mitgemacht. Man spürt es sehr direkt: Jede Modellgeneration hat ihre Eigenheiten und ihre eigene Arbeitsweise. Das bedeutet, wenn das Modell aktualisiert wird, müssen wir auch die Codebasis anpassen und mit dem Modell „schalten“.
Ein besonders interessantes Beispiel: Bei der Generation 5.2 hatte das Codex Harness noch keine Fähigkeit für Hintergrund-Shells, also konnten wir damals noch blockierende Skripte für langlaufende Aufgaben verwenden. Als 5.3 dann Hintergrund-Shells hatte, wurde das Modell weniger geduldig, es wollte nicht mehr ewig warten. Also mussten wir das gesamte Build-System neu bauen, mit dem Ziel, die Build-Zeit unter einer Minute zu halten.
Wenn ein normales menschliches Team die Codebasis wartet, halte ich das fast für unmöglich. Denn Menschen haben ihre eigenen Präferenzen, streiten sich und grübeln darüber, ob es sich lohnt, alles umzustellen – aber unser einziges Ziel war es, die Produktivität des Agenten innerhalb einer Woche zu maximieren. Also sind wir von einem benutzerdefinierten Build über Makefile zu Bazel gewechselt, dann zu Turbo, dann zu Nx – und haben da angehalten, wo es am schnellsten war.
Warum die Build-Zeit unbedingt unter einer Minute bleiben muss
swyx: Ziemlich interessant, erzähl mehr über Turbo und Nx – die meisten anderen gehen ja in die entgegengesetzte Richtung.
Ryan Lopopolo: Ehrlich gesagt habe ich selbst nicht besonders viel praktische Erfahrung mit Frontend-Repository-Architektur.
swyx: Du hast gesagt, Jessica hat das gesamte System aufgebaut. Ich kenne das Nx-Team und auch Jared Palmer und die Leute von Turbo. Ich finde diesen Kontrast ziemlich spannend.
Ryan Lopopolo: Aber der „Berg, den wir besteigen wollten“, bestand eigentlich nur aus einer Sache: Es muss schneller werden.
swyx: Gibt es da Micro Frontends? Oder ist die Komplexität von React sehr hoch?
Ryan Lopopolo: Es ist eine Monolithanwendung basierend auf Electron, ungefähr diese Struktur.
swyx: Und es muss unbedingt unter einer Minute bleiben? Diese Randbedingung ist ziemlich interessant. Ich bin mit dem Hintergrund-Shell-Thema nicht so vertraut, es wurde ja in der Veröffentlichung von 5.3 erwähnt.
Ryan Lopopolo: Grundsätzlich kann Codex im Hintergrund Befehle starten und während des Wartens auf die Beendigung andere Dinge erledigen. Zum Beispiel kann es zuerst einen besonders zeitaufwändigen Build starten, dann während des Wartens selbst Code reviewen. Das ist viel zeitsparender für die Person, die das Harness nutzt.
swyx: Aber warum eine Minute, warum nicht fünf?
Ryan Lopopolo: Weil wir die innere Schleife (inner loop) so schnell wie möglich machen wollen. Eine Minute ist einfach eine runde Zahl und ein Ziel, das tatsächlich erreichbar ist.
swyx: Wird es direkt gekillt, wenn es nach einer Minute nicht fertig ist?
Ryan Lopopolo: Nein. Es ist nur ein Signal, dass wir anhalten und die Aufgabe neu ordnen müssen: Wir müssen den Build-Graphen feiner zerlegen, bis die Komplexität unter den Schwellenwert sinkt, damit der Agent wieder effizient weiterarbeiten kann.
swyx: Das fühlt sich wie eine Ratsche an. Du zwingst dich mit einer sehr harten Methode, die Untergrenze der Build-Geschwindigkeit einzuhalten. Denn wenn du das nicht machst, wird die Zeit immer länger. Du hast ja auch erwähnt, dass die Software, die du heute selbst baust, bereits zwölf Minuten Build-Zeit hat – das ist eine furchtbare Erfahrung.
Ryan Lopopolo: Genau. Das ist genau das, was ich früher als Plattformteam immer erlebt habe: Man hat einen Bereich von Build-Zeiten, den man noch akzeptiert, und wenn er immer weiter ansteigt und über die Grenzen geht, investiert man zwei bis drei Wochen, um ihn wieder unter den Durchschnitt zu drücken.
Aber heute sind Tokens einfach viel zu billig, und Modelle können massiv parallel arbeiten. Also können wir das System kontinuierlich pflegen und trimmen wie einen Garten und diese Kernwerte einhalten. Dadurch ist die Diskrepanz zwischen Code und dem gesamten SDLC viel geringer – wir können viele Dinge einfacher machen und mehr stabile Invarianten bei der Softwareentwicklung nutzen.
Der Mensch wird zum Flaschenhals
Vibhu: Du hast in deinem Artikel einen sehr auffälligen Satz geschrieben: Der Mensch ist zum Flaschenhals geworden. Ihr habt am Anfang nur zu dritt angefangen, und hab ein System mit einer Million Codezeilen und tausend PRs gebaut. Welche Denkweise steckt dahinter? Du hast schon viel darüber gesagt, dass Code wegwerfbar ist, aber trotzdem müsst ihr trotzdem viel reviewen. Der Artikel betont immer wieder, dass alles als Prompt formuliert werden muss – alles, was der Agent nicht sehen kann, ist im Grunde Müll. Aus einer höheren Perspektive betrachtet: Wie habt ihr dieses System aufgebaut? Wenn der Mensch bereits der Flaschenhals bei der PR-Überprüfung ist, welche Rolle bleibt dem Menschen überhaupt noch?
Ryan Lopopolo: Ehrlich gesagt sind wir inzwischen an einem Punkt angelangt, an dem nicht einmal mehr die Code-Überprüfung hauptsächlich von Menschen gemacht wird. Die meisten menschlichen Überprüfungen finden heute tatsächlich nach dem Merge des Codes statt.
swyx: Moment, nach dem Merge? Also gibt es vor dem Merge überhaupt keine Überprüfung? Ist das nur, damit die Menschen sich psychologisch wohlfühlen?
Ryan Lopopolo: Du kannst die alte Denkweise einfach nicht mehr beibehalten. Modelle lassen sich im Grunde extrem einfach parallelisieren. Wenn ich bereit bin, mehr GPU und mehr Tokens einzusetzen, können sie kontinuierlich an meiner Codebasis arbeiten. Das wirklich knappe Gut ist inzwischen die „menschliche Aufmerksamkeit“, die in meinem Team in Echtzeit verfügbar sein muss.
Obwohl es ehrlich gesagt schwer ist, nicht ständig einzugreifen und dem Modell neue Dinge zu geben, wenn es einmal läuft –