Braintrust hat innerhalb eines Monats die Hälfte seines Entwicklungsteams auf Codex umgestellt und damit den Rückstau an Feature-Wünschen aufgelöst

Was Braintrust an seinem Workflow tatsächlich verändert hat

Braintrust entwickelt eine Observability- und Evaluierungsplattform für KI-Produkte. Laut OpenAIs Bericht nutzen die Entwickler dort inzwischen Codex mit GPT-5.5, um aus einer Kunden-Feature-Anfrage direkt einen Preview-Branch zu erstellen und dem Kunden innerhalb von Minuten eine funktionierende Version zu zeigen.

Der konkrete Vorher-Nachher-Vergleich ist der bemerkenswerte Teil. Gründer und CEO Ankur Goyal beschreibt den alten Weg so: Eine Anfrage würde „in einen Rückstau wandern und später priorisiert werden“. Der neue Weg ist Copy-Paste in Codex, ein Preview-Branch und eine Live-Demo. Der Warteschlangen-Schritt entfällt – zumindest für Anfragen, die klein genug sind, um sie direkt vor Ort zu prototypisieren.

OpenAI berichtet, dass die Hälfte des Braintrust-Teams innerhalb eines Monats zu Codex gewechselt ist. Diese Adoptionsrate ist die zentrale Kennzahl der Geschichte und zugleich die einzige belastbare Zahl – konkrete Angaben zu Durchsatz oder Zykluszeiten fehlen.

Goyals Aussage betrifft die Latenz, nicht die Fähigkeiten des Modells

Die Geschichte ist ungewöhnlich direkt darin, was den Unterschied ausmacht – und es ist nicht die Qualität des Reasonings, sondern die Geschwindigkeit. Goyal beschreibt sie als Eigenschaft, die sein Verhalten verändert, nicht nur seine Output-Rate.

Es klingt simpel, aber Codex kann buchstäblich mehr Text ins Terminal schreiben, ohne dabei langsamer zu werden, und andere Modelle können das einfach nicht nachbilden. Der größte Gewinn ist die Geschwindigkeit.Montana Labs

Das ist eine enge, überprüfbare Behauptung: anhaltender Terminal-Output ohne Verlangsamung. Für ein Team, das vor den Augen des Kunden iteriert, ist die Latenz des Tools kein kosmetisches Detail – sie entscheidet darüber, ob eine Anfrage direkt im Meeting prototypisiert oder für später notiert wird. Goyal sagt, die Geschwindigkeit „verändert die Art, wie ich mit Codex im Vergleich zu anderen Modellen interagiere“ – das ist der Mechanismus hinter der Rückstau-Behauptung, nicht ein separater Vorteil.

Ein Wandel vom Prompten zur sandboxbasierten Autonomie

Die zweite beschriebene Workflow-Änderung betrifft die Entwicklungspraxis noch konkreter. Goyal sagt, dass er mit langsameren Tools „das Modell anleiten musste, ein bestimmtes Problem zu lösen“ – Schritt für Schritt, mit direkter Führung. Mit Codex schreibt er stattdessen einen Test, der das Problem demonstriert, richtet eine Sandbox-Umgebung ein und lässt den Agenten darin selbstständig arbeiten.

Er nennt das „für mich einen neuartigen Anwendungsfall“ und führt ihn explizit auf die Geschwindigkeit zurück: „Ich kann Experimente durchführen, weil es schnell genug ist.“ Die Logik dahinter: Wenn jede Iteration günstig genug ist, wird es praktikabel, ein Problem über einen fehlschlagenden Test zu definieren und den Agenten iterieren zu lassen – wo vorher sorgfältiges Prompten nötig war. Das passt gut zu einem Eval-Unternehmen – ein Problem anhand eines Tests zu demonstrieren, ist genau die Art von Spezifikation, die ein evaluierungsorientiertes Team ohnehin schon erstellt.

Die eigentliche Implikation: Schnelle Agenten verändern, was überhaupt in den Rückstau gelangt – nicht nur, wie schnell er sich abbaut

Die naheliegende Lesart dieser Geschichte lautet: „KI macht Coding schneller.“ Die präzisere Erkenntnis ist, dass eine ausreichend niedrige Iterationslatenz die Entscheidung verändert, ob eine Anfrage überhaupt erst angegangen wird. Braintrust hat nicht nur bereits in der Warteschlange befindliche Arbeit beschleunigt – das Unternehmen hat den Kompromiss aufgelöst, der kleine Anfragen überhaupt erst in eine Warteschlange schickt.

Für Teams, die agentische Coding-Tools bewerten, verschiebt das den Maßstab. Die Frage lautet weniger „Kann das Modell die Aufgabe lösen?“ als vielmehr „Ist der Round-Trip schnell genug, dass Entwickler ihre Arbeitsweise ändern?“ Braintrusts eigenes Fazit, in Goyals Worten, ist mengengetrieben: „Je mehr Code wir schreiben, desto mehr Kundenprobleme können wir lösen.“ Das ist eine Wette darauf, dass sich günstige Iteration kumulativ auszahlt – eine Wette, die diese einzelne Kundengeschichte durch Adoption und persönliche Aussagen belegt, nicht durch gemessenen Output. Ob sich das Muster als dauerhaft erweist, bleibt eine offene Frage, die sich lohnt, in den eigenen Kennzahlen der Teams zu beobachten.