Warum schließen sich Codex und ChatGPT zusammen? Wie sieht die Zukunft von Codex aus? Der führende Kernmitarbeiter von OpenAI beantwortet alle Fragen

Wenn Sie fragen, welches KI - Produkt im Jahr 2026 am beeindruckendsten gewachsen ist, dann steht sicherlich „Codex“ an erster Stelle.

Seit Januar dieses Jahres hat die Anzahl der wöchentlichen aktiven Benutzer dieses Produkts sich um mehr als das Fünffache erhöht, und die Wachstumskurve ist sehr steil. Derzeit hat es bereits 5 Millionen wöchentliche aktive Benutzer erreicht. Dabei ist die Akzeptanzrate von Codex unter Wissensarbeitern (nicht - Entwicklern) mehr als dreimal so hoch wie unter der Gruppe der Entwickler.

Es ist bemerkenswert, dass für diese steile Wachstumskurve ein wichtiger Katalysator vorhanden ist - die Veröffentlichung der Desktop - App im Februar. Diese Desktop - Version bietet eine exklusive und optimierte Benutzeroberfläche, die die Einstiegshürde erheblich senkt und einen sprunghaften Anstieg der Downloads und der Akzeptanzrate von Codex bewirkt.

Hinter dieser steilen Wachstumskurve ist es ein relativ wenig diskutierter Akteur, der die Veränderung der Produktform vorantreibt - Andrew Ambrosino, der Leiter des Codex - Desktop - Anwendungs - Teams.

Als derjenige, der direkt für die Weiterentwicklung des Codex - Desktop - Produkts verantwortlich ist, steht er zwischen zwei sich schnell überlappenden Welten: Einerseits ist es die Entwickler - Toolkette, deren Kernpunkt das „Schreiben von Code“ ist, andererseits ist es der universelle KI - Arbeitszugang, der sich schnell in fast alle Wissensarbeitsszenarien ausbreitet. Von der Veröffentlichungsrhythmus des Produkts bis hin zur Veränderung des Benutzerverhaltens und wie das Team intern die Grenzen zwischen „Design“, „Engineering“ und „Produkt“ neu definiert, das, was er sieht, liegt oft näher am Kern dieser Veränderung als die Wachstumsdaten selbst.

Das folgende Interview geht von seiner Perspektive aus, um zu analysieren, was Codex verändert hat, warum es mit ChatGPT zusammengeführt wurde und wie seine zukünftige Iterationsrichtung aussieht.

Video - Link: https://www.youtube.com/watch?v=P3KDebPTUrw

Wir haben Teile des Interviews zusammengefasst. Weitere Details finden Sie im Originalvideo.

Die Umsetzung wird billiger,

was wird dann teurer?

Vor einigen Jahren war die Logik der gesamten Produktentwicklung so: Die Umsetzung war sehr teuer. Deshalb mussten Sie vor dem eigentlichen Schreiben von Code eine Menge Vorarbeiten zur Risikominimierung leisten - Dokumente schreiben, Recherchen machen, Prototypen entwickeln, um das Design kostengünstiger zu gestalten. Da die Umsetzung an sich sehr kostspielig war, mussten Sie alles von Anfang an gründlich durchdenken.

Aber jetzt hat sich diese Annahme komplett umgedreht. Bei OpenAI ist es so: Menschen bekommen eine Menge Token, und jeder hat gute Ideen, also macht jeder etwas. Das Ergebnis ist, dass für eine zu implementierende Funktion möglicherweise 90 verschiedene Teams gleichzeitig 90 verschiedene Umsetzungsansätze erkunden.

Das bedeutet, dass die Umsetzung nicht mehr der teure Teil ist. Was wird dann teurer? Andrew sagt es direkt aus: Es ist der Geschmack. Genauer gesagt, es ist der Prozess der Kuration. Wenn Sie diesen 90 verschiedenen Versuchen gegenüberstehen, müssen Sie den Blick haben, um zu beurteilen: Was ist gut gemacht? Wie sollten diese in andere Funktionen integriert werden? Wie sollte dieses Ding strukturiert werden? Wie viele Stufen sollte dieser Umschaltknopf haben? Diese Entscheidungen selbst sind jetzt das Teuerste und erfordern die meiste Überlegung.

Was genau ist Geschmack?

Das Wort „Geschmack“ ist in Silicon Valley zu Tode gesprochen worden. Aber bei Andrew hat es eine sehr konkrete Bedeutung.

Es gibt ein interessantes Sprichwort: Der Produktmanager von Linear hat einmal gesagt, dass man den ästhetischen Aspekt des Geschmacks zu sehr betont und hat Paul Graham als Beispiel angeführt - Paul Graham hat offensichtlich guten Geschmack, aber er trägt Arbeitshosen. Das zeigt, dass Geschmack weit mehr als nur das Äußere ist. Andrew listet die Inhalte des Geschmacks auf: Es gibt den ästhetischen Aspekt, aber das ist nur ein Teil; es gibt den Aspekt des Systemsdenkens, d. h. wie dieses Ding in das gesamte System passt; es gibt den Aspekt des Richtungssinns, zu welchem Thema dieses Ding gehört; es gibt den Aspekt der Präsentation. Natürlich gibt es auch einige Detailaspekte, z. B. ob diese Interaktionsanimation mit der zu exprimierenden Semantik übereinstimmt - ob sie zu schnell ist und für die Darstellung dieses Konzepts ungeeignet ist.

Die eigentliche zentrale Frage zum Geschmack ist jedoch die folgende: Wenn wir alles bauen können, was möchten wir dann? Was ist das? Wie gelangen wir dorthin? Das sind die echten Fragen zum Geschmack.

Es geht nicht nur darum, was man tun soll. Es geht auch darum, wie man Informationen präsentiert, wie man Ziele erreicht und welches Medium man verwendet. Geschmack ist der am meisten wertvolle Aspekt des menschlichen Gehirns in dieser neuen Ära.

Warum kann KI bis jetzt noch nicht gut gestalten?

Dies ist ein interessantes Paradoxon: Codex ist bei der Codeerstellung bereits sehr leistungsfähig, aber wenn man es zur Generierung von Design verwendet, ist die Qualität der Ausgabe oft mäßig. Man kann selten sagen: „Wow, es hat alles perfekt gemacht.“

Andrew sieht mehrere Gründe dahinter. Zunächst gibt es praktische Gründe. Das Design ist schwieriger zu bewerten als Software, denn der menschliche Geschmack, der die Güte des Designs beurteilt, ist selbst Teil des Feedback - Mechanismus. Dies macht das Trainieren von Modellen schwierig - anders als beim Code, den man mit objektiven Kriterien (kann der Code kompiliert werden? Funktioniert die Funktion normal?) messen kann. Zweitens betrachtet man von der Perspektive des Forschungsaufwands: Die Labore haben in der Vergangenheit am meisten Ressourcen in die Verbesserung der Fähigkeiten investiert, die die KI - Forschung selbst beschleunigen können. In der frühen Phase des Codierungsmodells hat die Fähigkeit, richtigen Code zu schreiben, offensichtlich die Forschung beschleunigt. Aber ob die Gestaltungsfähigkeit gut ist oder nicht, beschleunigt die KI - Forschung nicht so direkt.

Ein tieferes Problem betrifft die Komplexität des Gestaltungsarbeits selbst. Im Design gibt es einen kulturellen Aspekt - was als „gutes Design“ gilt, wird von der Kultur bestimmt. Im vergangenen Jahr haben alle neuen Websites das Design von Linear kopiert. Das war wirklich gutes Design mit Geschmack. Aber wenn ein Modell jedes Mal das Design von Linear ausgibt, dann ist das kein Fortschritt, sondern ein Misserfolg. Design erfordert Neuheit, während bei der Softwareentwicklung genau das Gegenteil gilt: Man möchte fast immer, dass der Code bekannten Mustern folgt.

Das schwierigste Problem liegt auf der Abstraktionsebene. Wenn der Code die visuelle Gestaltung steuert, besteht eine tiefe Interaktion zwischen beiden. Beispielsweise sollte etwas in der linken oberen Ecke im Code - Repository die gleiche Abstraktion wie etwas unten teilen. Es geht nicht nur darum, dass das Modell ein besserer Designer werden muss, sondern auch darum, dass das Modell diese tieferen strukturellen Beziehungen verstehen muss - wenn das Unternehmen morgen eine Markenumbildung vornimmt, ist die oberflächliche Methode, 263 Komponenten einzeln zu aktualisieren, aber das tiefere Verständnis sollte sein: Diese beiden scheinbar verschiedenen Dinge sind semantisch gleich, beide sind Listen, haben die gleiche Darstellung und vermitteln das gleiche Interaktionsmuster. Ein solches Verständnis auf der Abstraktionsebene ist für KI derzeit noch weit weg.

Warum konnte Codex nicht früher veröffentlicht werden?

Dies ist eine sehr tiefgreifende Beobachtung: Der Erfolg eines Produkts hängt nicht nur vom Design selbst ab, sondern auch von der richtigen Zeit der Modellfähigkeiten.

Andrew ist sich sehr sicher, dass, wenn die Codex - App im November letzten Jahres veröffentlicht worden wäre, sie auf dem Markt total gescheitert wäre. Wenn dasselbe Produkt im Februar veröffentlicht worden wäre, wäre es jedoch ein großer Erfolg geworden. Die einzige Variable war der Fortschritt der Modellfähigkeiten in diesen wenigen Monaten. Mit anderen Worten, das Interaktionsdesign, die Benutzeroberfläche und das gesamte Konzept des Produkts haben sich nicht verändert, aber die Verbesserung der Intelligenz des Modells hat das Ergebnis völlig verändert.

Dies enthüllt eine tiefgreifende Wahrheit: In der KI - Ära wird nicht allein durch das UI - Design oder das Interaktionsdesign entschieden, ob ein Produkt gut nutzbar und wertvoll ist, sondern durch „was das Modell in diesem Moment tun kann“. Dieselbe Idee kann mit einem alten Modell nutzlos sein, aber mit einem neuen Modell kann sie sehr interessant sein.

Dies ändert auch die Art der Produktplanung. Andrew hat in seiner früheren Firma diesen Wandel gesehen: Es ist nicht mehr „was wir das ganze Jahr über planen“, sondern es wird zu „wir glauben, was das Modell zu einem bestimmten Zeitpunkt tun kann. Lassen Sie uns alle interessanten Dinge auflisten, für alle davon Prototypen entwickeln und dann entscheiden, welche wir jetzt tun können und welche wir erstmal liegen lassen. Wenn das Modell einen neuen Sprung macht, versuchen wir dann die früher aufgeschobenen Ideen mit dem aktualisierten Modell“. Denn die Voraussetzung dafür, ob eine Funktion gut nutzbar ist, ist nicht die Form des Designs, sondern ob das Modell intelligent genug ist.

Sind die Grenzen zwischen Ingenieuren, Designern und Produktmanagern verschwunden?

Lenny hat erwähnt, dass, wenn man sich Andrews Karriereansicht anschaut, er schon als Ingenieur, Designer, Produktmanager und Unternehmer gearbeitet hat und jetzt das gesamte Desktop - App - Team leitet. Er hat gefragt, ob das Design - Team auch ihm unterstellt sei. Andrew hat gelacht und gesagt: „Es hängt von der Woche ab“ - die Berichtsbeziehungen ändern sich ständig, aber das Team arbeitet immer eng zusammen und ineinander verwoben.

Andrew hat gesagt, dass es draußen schon über die „Kollaps der Rollen“ gesprochen wird und dass es in Zukunft keine Rollenunterschiede mehr geben werde. Sein Team ist noch nicht so weit, aber die Überlappung zwischen den Rollen ist deutlicher als in anderen Abteilungen der Firma und sogar in der gesamten Branche - teilweise deshalb, weil Codex von Anfang an ein technisches Produkt für Ingenieure war. Die Designer im Team können die Sprache der Ingenieure sprechen, und die Produktmanager können auch Code schreiben. Beispielsweise hat der andere Produktmanager Alexander einen Master in Informatik, während Andrew das nicht hat.

Er meint, dass es jetzt genauer zu sagen ist: Eine Person wird nicht mehr durch die Grenze definiert, „wo das Design endet und wo das Engineering beginnt“, sondern durch das, wofür sie im Durchschnitt ihre Zeit verwendet - dies hängt auch von der Arbeitsweise des Teams zusammen, denn die gesamte App ist durch das interne „Eigenkonsum“ entstanden. Alle möchten so viel wie möglich in der App erledigen, auch wenn es für die Zeit nicht das beste Werkzeug ist, damit es langsam das beste Werkzeug werden kann. Die beiden haben auch kurz über die Herkunft des Titels „member of technical staff“ gesprochen. Andrew meint, dass diese vielleicht erstmals von Xerox so genannt wurde und dass es heute in forschungsgetriebenen Firmen eine Art Tradition ist.

Lenny hat nachgefragt, ob das bedeute, dass alle in Zukunft zu „Buildern“ ohne funktionale Unterscheidung werden würden und ob die Skill - Kategorien wie PM, Design und Engineering noch existieren würden. Andrews Meinung ist klar: Er stimmt nicht mit der völligen Abschaffung der Rollenunterscheidung überein. Er hat viele Firmen gesehen, die „die Produkt - Position abschaffen und jeder sei ein Builder“ gerufen haben. Das Ergebnis war, dass die über Jahre hinweg gesammelten besten Praktiken und die Fehlersuch - Erfahrungen in der Produkt - Branche weggeworfen wurden, nur weil man dachte: „Ich kann auch Code schreiben“. Er begrüßt das Verschwinden der grenzengängigen Haltung wie „dies ist nicht Ihr Bereich“, aber jedes Fach hat immer noch seine eigenen Skill - Hürden - nicht jeder, der Excel benutzen kann, kann in der Finanzabteilung arbeiten.

Er hat auch erwähnt, dass es jetzt tatsächlich leichter ist, die Rolle zu wechseln, weil die Fähigkeiten nicht mehr fest an die „Beherrschung eines bestimmten Tools“ gebunden sind: Er selbst hat sich lange gedacht, er solle nicht als Ingenieur arbeiten, weil er es nicht mag, sich mit Assemblersprache zu beschäftigen und die TypeScript - Syntax auswendig zu lernen. Die Hürde, dass man ein Tool beherrschen muss, um gut zu arbeiten, bricht zusammen. Aber er warnt auch, dass diese Tendenz von außen derzeit übertrieben wird.

Die neuesten KI - unterstützten Entwicklungsansätze

Lenny hat das Thema einen Schritt zurückgenommen: Vom reinen manuellen Schreiben von Code über die Möglichkeit, dass KI 100 % des Codes schreiben kann, bis hin zum heutigen Zustand, in dem „Code schreiben“ zu „KI leiten“ geworden ist - die Bewertung, wie viel Code eine Person geschrieben hat, ist fast zu „wie oft haben Sie die Richtung der KI korrigiert“ geworden. Er hat gefragt, ob die neueste Methode „loop“ (autonomer zyklischer Entwicklungsansatz) sei und wie die vordersten KI - Teams derzeit konkret funktionieren.

Andrew hat erwähnt, dass die Frage, „wie viel Code von der KI geschrieben wurde“, an sich schon nicht mehr wichtig ist, denn nach den Standards des vergangenen Jahres wird heute fast 100 % des Codes von der KI geschrieben; die echte Frage ist, ob dieser Code „unter Aufsicht“ oder „ohne Aufsicht“ geschrieben wurde, und das sind zwei völlig verschiedene Dinge. Er freut sich, dass diese Bewertungskriterien ständig aktualisiert werden, denn das zeigt, dass das Produkt voranschreitet. Das Team hat viele Untersuchungen in Richtung „autonomer Softwareentwicklung“ durchgeführt, einschließlich vieler Versuche im Bereich „harness engineering“, z. B. die Vorstellung, dass das Modell in der Nacht selbst einmal durchläuft und die Code - Basis wie bei einer „Müllentsorgung“ bereinigt.

Er hat auch zugegeben, dass alle gegenwärtigen Modelle ein gemeinsames Problem haben - sie neigen dazu, den Code immer komplexer zu machen. Er hat halb im Scherz gesagt, dass, wenn das Forschungs - Team einer Firma zuhört, er hoffe, dass das Modell besser darin werden würde, Code zu löschen. Dies ist auch ein reales Problem