Codex AI Super App: GPT-5.5 Workflow-Test

Ein Freund schickte mir an einem Dienstag um 23:14 Uhr einen YouTube-Link mit der Nachricht „Schau dir das an und sag mir dann, dass du ChatGPT immer noch treu bist.“ Bei dem Video handelte es sich um einen dreizehnminütigen Rundgang durch einen Ersteller namens Vaibhav, und seine These lautete, dass jeder, der ChatGPT im Jahr 2026 noch nutzte, bereits ein Jahr im Rückstand war. Der Grund, behauptete er, war ein Produkt namens Codex – eine AI-Super-App auf

Ich habe es zweimal gesehen. Dann klappte ich meinen Laptop zu und ging genervt zu Bett, denn die Hälfte von dem, was er zeigte, hatte ich bereits zwei Wochen lang getestet, und die andere Hälfte klang wie eine Demo, die kaputt geht, sobald man sie aus der Bahn reißt.

Also verbrachte ich die nächsten vier Tage damit, die Super-App Codex AI anhand der genauen Arbeitsabläufe in diesem Video auszuführen. Die Gmail-zu-PowerPoint-Automatisierung. Die Aufforderung „Erstellen Sie mir eine App für Offline-Gründertreffen“. Die Gabelgewinde-Parallelarbeit. Die autonome Fehlerbehebung. Ich lasse es durch echte Daten, echte Misserfolge und echte Überraschungssiege kochen. Ich bin auch den Behauptungen nachgegangen, die ich nicht überprüfen konnte – das „Papier“-Designtool, das er nennt, das genaue Modell

Das ist die Realität. Das ist es, was überverkauft ist. Und hier hat sich der Arbeitsablauf bei mir tatsächlich geändert – einschließlich des Moments, in dem ein gespaltener Thread gleichzeitig ein Marketing-Deck und eine funktionierende App lieferte und mir klar wurde, dass ich völlig falsch über parallele AI-Arbeit nachgedacht hatte.

Lassen Sie uns zunächst die Benennung und das Modell klarstellen

Bevor ich auf einen einzelnen Workflow eingehe, muss das, was das Video beschönigt, auf den Punkt gebracht werden – denn wenn Sie ohne Kontext nach „Codex super app“ oder „GPT-5.5“ suchen, werden Sie innerhalb von dreißig Sekunden verwirrt sein.

Das Produkt heißt Codex, und ja, es ist OpenAI. Kein Wrapper eines Drittanbieters. Kein Fanprojekt. Die Überarbeitung der „Super-App“ der Desktop-App wurde am 16. April 2026 als Codex Desktop v26.415 gemäß Änderungsprotokoll der Entwickler von OpenAI ausgeliefert, und das Modell 2026 gemäß TechCrunchs Berichterstattung über den Start. Das ist die Zeitleiste. Die „Super-App“-Framing im Video ist real – sie stammt direkt aus OpenAIs eigener Positionierung gemäß der TechCrunch-Story und Sam Altmans Vision, ChatGPT,

Was im Video nicht erwähnt wird, ist, dass Codex standardmäßig nicht immer auf GPT-5.5 läuft. Gemäß OpenAIs Codex-Modellseite leitet Codex je nach Aufgabenklasse und Abonnementstufe zwischen GPT-5.5, GPT-5.5 Pro und den älteren 5-Codex-Varianten weiter. Einige Aufgaben laufen auf GPT-5.5 mit besonders hohem Argumentationsaufwand. Einige laufen auf leichteren Prüfpunkten, um die Latenz angemessen zu halten. Wenn Sie ChatGPT Plus nutzen, erhalten Sie GPT-5.5-Zugriff, jedoch mit gedrosselter Nutzung. Wenn Sie die neue Pro-Stufe für 200 $/month nutzen, erhalten Sie die von OpenAI beworbene Zuteilung „5x mehr

Dies ist wichtig, da das Video Demos zeigt, die mit ziemlicher Sicherheit die aufwändigsten Argumentationspfade nutzten. Wenn Sie seine Eingabeaufforderungen auf einem Plus-Konto replizieren, erhalten Sie nicht die gleichen Geschwindigkeiten, die gleiche Planungstiefe oder die gleiche fehlerverzeihende Fehlerbehebung. Das ist kein Fehler, sondern der Preis des Produkts. Aber es ist der Teil, der in viralen Demos stillschweigend übersprungen wird, und wenn man ihn überspringt, wird man am Ende enttäuscht.

Bevor wir fortfahren, noch eine Klarstellung der Namensgebung. Vaibhav führt einmal Codex vor: „Entwerfen in einem Design-Tool namens Paper, indem der Cursor gesteuert und Layouts live erstellt werden.“ Ich habe nach „Paper“ als in Codex integriertes Designtool gesucht und konnte es nicht als aktuelles Codex-Plugin verifizieren. Es gibt einen Figma-Blogbeitrag über die Integration von Codex in Figma – der echt ist und ausgeliefert wird. Es gibt eine ganze Reihe von Designtools, die über den Computernutzungsmodus von Codex funktionieren, der es ermöglicht, durch jede Desktop-App zu klicken. „Paper“ könnte Vaibhavs Name für eines davon sein, es könnte sich um ein Beta-Produkt handeln, auf das ich keinen Zugriff habe, oder es könnte sich um ein Tool handeln, das mir einfach fehlt. Ich kennzele es als nicht bestätigt, anstatt so zu tun, als hätte ich es bestätigt. Das ist die ehrliche Entscheidung.

Hier wird es jedoch interessant: Selbst mit der Modellführung, den Preisstufen und dem nicht verifizierten Design-Tool sind die zugrunde liegenden Workflow-Veränderungen im Video real. Die Art und Weise, wie Codex Ihre Arbeitsweise neu strukturiert, ist die eigentliche Geschichte. Und was mich am härtesten getroffen hat, waren nicht die Demos, mit denen er anführte. Es war das, was die meisten Zuschauer wahrscheinlich übersprungen haben.

Die drei Säulen: Projekte, Plugins, Automatisierungen – und warum die Reihenfolge wichtig ist

Das Video stellt dar, dass Codex über drei Kernfunktionen verfügt: Projekte, Plugins und Automatisierungen. Diese Formulierung ist korrekt. Was er falsch macht, ist, sie als parallele Merkmale zu behandeln. Das sind sie nicht. Es handelt sich um sequentielle Schichten, und das Fehlen der Reihenfolge ist der Grund, warum die meisten Leute, die Codex ausprobieren, innerhalb einer Woche davon abspringen.

Projekte sind das Fundament. Ein Projekt in Codex ist ein dauerhafter Arbeitsbereich, der Dateien, Konversationen, Speicher und Zugriffsberechtigungen für einen bestimmten Arbeitsumfang bündelt. Wenn ich an einem Laravel-Kundenauftrag arbeite, ist das ein Projekt. Wenn ich für den Blog nach AI-Modellversionen recherchiere, ist das ein separates Projekt. Das Projekt ist das, was den Kontext enthält – die Dateien, die Codex gelesen hat, die Entscheidungen, die Sie gemeinsam getroffen haben, die Berechtigungen, die Sie ihm erteilt haben, den Ton und die Konventionen, denen es folgen sollte. Ohne ein Projekt beginnt jede Codex-Interaktion bei Null.

Mit Plugins gelangt Codex außerhalb des Projekts in den Rest Ihrer Arbeit. Mittlerweile gibt es über neunzig Plugins pro OpenAIs Plugin-Marktplatz-Ankündigung, die von The Decoder abgedeckt wird – Slack, Notion, Figma, Gmail, Google Drive, GitHub, GitLab, Atlassian, Render, Neon, Remotion und viele andere. Jedes Plugin kann drei Dinge pro Abdeckung umfassen: Fähigkeiten (wiederverwendbare Eingabeaufforderungsmuster), Apps (Integrationsendpunkte) und MCP-Server (der eigentliche Daten- und Toolzugriff). Das Plugin ermöglicht es Codex, nicht nur über Ihre Notion-Dokumente zu sprechen, sondern sie tatsächlich zu lesen, zu schreiben und neu zu organisieren. Ohne Plugins ist Codex ein brillanter Mitarbeiter ohne E-Mail und ohne Kalender.

Automatisierungen sind die Ebene, die die meisten Leute überspringen – und sie ist die Ebene, auf der das gesamte Wertversprechen der Super-App lebt. Eine Automatisierung in Codex ist eine geplante, kopflose Agentenausführung, die bei einem Auslöser (Zeit, Ereignis oder Webhook) ausgelöst wird und eine definierte Aufgabe unter Verwendung aller Projekte und Plugins ausführt, auf die sie Zugriff hat. Gemäß der Codex-Seite von Das ist die Linie, die die Lede stillschweigend begräbt.

Deshalb ist die Reihenfolge wichtig. Wenn Sie Plugins vor Projekten einrichten, werden Ihre Plugin-Berechtigungen chaotisch und überzogen – Codex erhält Anmeldeinformationen, die es nicht benötigt, in Bereichen, die es nicht haben sollte. Wenn Sie Automatisierungen einrichten, bevor Sie das Verhalten eines Projekts vollständig getestet haben, werden Sie aufwachen und feststellen, dass ein geplanter Agent eine Woche lang täglich etwas subtiles falsch gemacht hat. Ich habe beide Fehler in der ersten Woche gemacht. Durch die Reparatur habe ich gelernt, Codex so einzurichten, wie Sie einen neuen Mitarbeiter einrichten würden: Geben Sie ihm zuerst einen Schreibtisch, dann seine Werkzeuge und dann seine wiederkehrenden Verantwortlichkeiten. Nicht umgekehrt.

Das andere, was das Video nicht sagt: Jedes Plugin und jede Automatisierung ist eine Sicherheitsoberfläche. Die Formulierung „Vollzugriff“ in Vaibhavs Demo verschleiert die Tatsache, dass Sie in der Praxis einem autonomen Agenten dauerhafte OAuth-Bereiche für Ihre Geschäftssysteme gewähren. Ich möchte das zu Protokoll geben, bevor ich beschreibe, was ich damit gebaut habe.

Dies ist die Demo, mit der Vaibhav beginnt, und es ist die, der ich am skeptischsten gegenüberstand. Der Pitch: Jeden Morgen überprüft Codex Ihr Gmail auf den neuesten Newsletter, extrahiert die wichtigsten Erkenntnisse, erstellt eine PowerPoint-Zusammenfassung und legt sie in Ihrem Posteingang ab. Er behauptet, dass er dadurch eine Stunde am Tag spart.

Ich habe es gebaut. Hier ist, was tatsächlich passiert ist.

Die Einrichtung dauerte dreiundzwanzig Minuten. Die Gmail-Plugin-Authentifizierung war der längste Schritt – Codex erfordert, dass Sie Bereiche sorgfältig zuweisen, und der OAuth-Ablauf führt Sie durch die Ordner, welche Labels und Absenderfilter, die berücksichtigt werden sollten. Ich habe es auf ein einzelnes Gmail-Label namens daily-read beschränkt, in das ich interessante Newsletter tagge. Ich habe ihm keinen Zugriff auf meinen gesamten Posteingang gewährt, da ich nicht der Typ bin, der einem autonomen Agenten uneingeschränkten Gmail-Zugriff überlässt, nur um einen Newsletter zusammenzufassen, und das sollten Sie auch nicht tun.

Die Automatisierung selbst war eine fünfzeilige Definition in natürlicher Sprache: „Suchen Sie jeden Wochentag um 8:00 Uhr die Newsletter der letzten 24 Stunden in daily-read, extrahieren Sie die drei wichtigsten Erkenntnisse aus jedem, erstellen Sie ein einzelnes PowerPoint-Deck, das sie mit einer Folie pro Newsletter plus einer Deckfolie zusammenfasst, und senden Sie das Deck als Anhang an meinen Posteingang.“

Ich habe es fünf Werktage lang laufen lassen. Hier ist die ehrliche Scorecard.

Tag eins: Es hat perfekt funktioniert. Drei Newsletter, drei Folien plus Deckblatt, die Formatierung war sauber, die Zusammenfassungen waren korrekt. Ich las das Deck in weniger als neunzig Sekunden durch und fühlte mich selbstzufrieden.

Tag zwei: Es wurde ein Newsletter eingeholt, der eigentlich ein wöchentlicher Überblick mit sieben Themen war, und der gesamte Überblick wurde als eine einzige Erkenntnis zusammengefasst, wobei fünf der sieben Themen fehlten. Das Deck war technisch korrekt, aber praktisch nutzlos.

Tag drei: Es hat wieder perfekt funktioniert, aber es war eine Sponsorennachricht aus einem der Newsletter enthalten, als wäre es eine echte Erkenntnis. Das brachte mich zum Lachen, weil es ein so offensichtlicher AI-Zusammenfassungsfehler war – das Modell konnte redaktionellen Inhalt nicht von bezahlter Platzierung unterscheiden, wenn der Sponsor sauber genug integriert war.

Tag vier: Bei der Ausführung von Codex kam es zu einer Zeitüberschreitung, weil Gmail an diesem Morgen langsam war und die Automatisierung keine Wiederholungslogik hatte. Das Deck ist nicht angekommen. Ich bemerkte es erst um 10 Uhr morgens, da ich die Newsletter ohnehin schon manuell überflogen hatte.

Tag fünf: Hat perfekt funktioniert.

Das Fazit zur Gmail-zu-PowerPoint-Automatisierung lautet also: Sie ist real, sie ist nützlich, sie spart Zeit an den Tagen, an denen sie funktioniert, und es handelt sich nicht um eine Einsparung von einer Stunde pro Tag. An den Tagen, an denen es richtig funktioniert, ist es eher eine Einsparung von fünfzehn bis zwanzig Minuten, an den Tagen, an denen es nicht funktioniert, gleich null oder negativ. Das Video übertrifft die Zeitersparnis um etwa das Dreifache. Aber es handelt sich wirklich um die Art von Hintergrundarbeit, die zuvor niemand zuverlässig erledigt hat, und die richtungsweisende Behauptung – dass diese Kategorie der Automatisierung jetzt ohne das Schreiben von Code möglich ist – ist richtig.

Die größere Lehre aus diesem Test: Automatisierungen brauchen Beobachtbarkeit. Nach dem vierten Tag habe ich eine zweite Automatisierung hinzugefügt, die lediglich den Success/failure-Status der ersten auf einer Notion-Seite protokolliert, sodass ich täglich aufzeichnen kann, welche Läufe funktioniert haben und welche nicht. Diese Art von Meta-Automatisierung wird im Video komplett übersprungen und ist der Unterschied zwischen einer Automatisierung, der Sie vertrauen, und einer, die Sie betreuen müssen.

Test 2: Erstellen einer Offline-App für Gründer-Meetups ohne Code

Dies ist die Demo, die jedes Mal viral geht, wenn Vaibhav einen Clip davon erneut hochlädt. Er fordert Codex auf, „eine App für Offline-Meetups für Gründer in Bangalore und San Francisco“ zu entwickeln. Codex verhält sich wie ein Produktmanager – er stellt klärende Fragen, plant die Benutzeroberfläche, entwirft das Layout in dem, was er Paper nennt, und plant dann den Full-Stack-Build (Datenbank, Routen, Komponenten), bevor er eine Zeile Code schreibt. In der Mitte des Builds verwendet er eine „Steer“-Funktion, um den Umfang live anzupassen, ohne den Agenten zu unterbrechen. Codex testet die App dann selbstständig auf Desktop- und Mobilgeräten, findet Fehler, plant Korrekturen, implementiert sie und führt erneut Tests durch. Kein menschliches Zutun.

Ich habe versucht, es so genau wie möglich nachzubilden. Meine Aufforderung: „Erstellen Sie mir eine einseitige Web-App, in der Gründer Offline-Meetups in ihrer Stadt posten und entdecken können. Sollte das Auflisten von Meetups, den Beitritt zu Meetups und ein Basisprofil pro Benutzer unterstützen. Die Datenbank kann vorerst SQLite sein. Stapeln Sie Ihren Anruf.“

Hier ist, was tatsächlich während einer echten vierstündigen Sitzung passiert ist.

Codex stellte mir zunächst sechs klärende Fragen – genau das Verhalten eines Produktmanagers, das das Video zeigt. Die Fragen waren gut: Wollte ich eine Authentifizierung, welche Städte sollten beim Start unterstützt werden, war es ein Marktplatz oder ein Verzeichnis, was bedeutete „Beitritt“ (nur RSVP oder kostenpflichtiger Ticketverkauf), was benötigten Profile und war dies gehostet oder lokal. Ich habe ihnen innerhalb von zwei Minuten geantwortet.

Anschließend wurde ein Stack vorgeschlagen: Next.js 15 mit App Router, Prisma über SQLite, Tailwind und shadcn/ui-Komponenten. Es wurde erklärt, warum – schnelle Iteration, keine externen Dienste für Version 1, einfache spätere Migration zu Postgres. Ich stimmte zu.

Die Planungsphase war der Teil, in dem ich meine Erwartungen neu kalibrieren musste. Codex hat einen Build-Plan mit 23 Aufgaben für Datenmodell, Routen, Komponenten, Authentifizierung und Tests erstellt. Es war gut. Besser als das, was die meisten Nachwuchsingenieure schreiben würden. Aber es geschah nicht, wie das Video andeutet, augenblicklich. Allein die Planungsphase dauerte etwa vier Minuten des „Denkens“, wobei ein hoher Denkaufwand aktiviert war, und zu beobachten, wie das Denken in Echtzeit geschieht, ist bei weitem nicht so aufregend, wie die Schnitte in YouTube-Demos vermuten lassen.

Der Build selbst dauerte etwa zwei Stunden und zwanzig Minuten. Während dieser Zeit schrieb Codex etwa 4.200 Codezeilen in 38 Dateien, betrieb den Entwicklungsserver selbst und testete die App in seinem in-app browser, indem er durch jeden Flow klickte. Ich habe das Äquivalent von „Steer“ – was in der aktuellen Codex-Benutzeroberfläche ein kleines Eingabefeld oben im laufenden Thread ist, mit dem Sie Anpassungen während des Buildvorgangs einfügen können – zweimal verwendet. Einmal nach einem anderen Farbschema fragen. Einmal, um Profilen den Schalter „Verifizierter Gründer“ hinzuzufügen. Beide Anpassungen wurden übernommen, ohne dass der Build neu gestartet werden musste.

Die autonome Fehlererkennungs- und -behebungsschleife ist real und beeindruckend. Dreimal während des Builds hat Codex Probleme in seiner eigenen Arbeit erkannt – einmal eine Prisma-Migrations-Race-Bedingung, einmal eine Tailwind-Klassenkollision, einmal einen Hydratationsfehler in einer Serverkomponente – und hat sie behoben, ohne mich zu fragen. Ich habe zugesehen, wie es geschah. Das Transkript zeigt, wie Codex seine eigene Konsolenausgabe liest, den Fehler identifiziert, einen Fix plant, den Fix anwendet und den Test erneut ausführt. Diese Schleife ist, mehr als alles andere im Build, der Grund dafür, dass sich die Super-App Codex AI kategorisch anders anfühlt als ein Programmier-Copilot.

Was das Video nicht zeigt: Der Build erzeugte auch zwei echte Fehler, die Codex nicht alleine erkannte. Der Ablauf „Meetup beitreten“ hat einen RSVP-Datensatz erstellt, aber die neue Teilnehmerzahl nicht zurückgegeben, sodass auf der Benutzeroberfläche bis zur Aktualisierung veraltete Daten angezeigt wurden. Und das Meetup-Erstellungsformular ermöglichte es Ihnen, mit einer leeren Standortzeichenfolge einzureichen, wodurch die Entdeckungsseite beschädigt wurde. Ich habe beide manuell in fünfzehn Minuten durch Herumklicken erfasst. Nachdem ich sie darauf hingewiesen hatte, reparierte Codex sie jeweils in weniger als einer Minute. Die Autonomie ist also real, aber begrenzt – sie fängt, was ihre automatisierten Tests fangen, und übersieht, was ein menschlicher Benutzer fängt, indem er die App auf die Art und Weise verwendet, wie ein Mensch eine App verwendet.

Endgültiger Stand des Builds: eine funktionsfähige Next.js 15-App, die ich realistischerweise an eine kleine private Beta liefern könnte. Nicht produktionstauglich. Die Authentifizierung erfolgte nur per E-Mail, es gab keine Ratenbegrenzung und keine richtigen Fehlergrenzen auf den benutzerorientierten Routen. Wahrscheinlich noch acht Stunden menschlicher Feinschliff, bevor ich es zahlenden Benutzern vorstelle. Aber absolut ein MVP, den ich zwei Tage lang alleine aufgebaut hätte, komprimiert auf einen Nachmittag, wobei Codex 85 Prozent der Arbeit erledigt hätte.

Die richtungsweisende Behauptung im Video – dass man Apps erstellen kann, ohne Code zu schreiben – ist real. Die Implikation, dass das Ergebnis so wie es ist lieferbar ist, ist nicht der Fall. Wer Ihnen etwas anderes sagt, verkauft Ihnen einen Kurs.

Test 3: Gegabelte Threads und warum ich über Parallel AI nachgedacht habe Falsch

Dies ist der Test, bei dem mein Rahmen für den gesamten Beitrag kaputt gegangen ist.

Vaibhav demonstriert mitten im Gespräch den Fork eines Codex-Chat-Threads, sodass ein Fork mit dem Aufbau der App fortfährt, während der zweite Fork ein Sponsor-Pitch-Deck und ein Einführungsvideo für dasselbe Produkt generiert. Er zeigt, wie beide Gabeln parallel produzieren. Insgesamt verstrichene Zeit: einige Minuten für beide Ausgänge.

Ich hatte zuvor abgespaltene Threads als Spielerei abgetan. So wie ich es mir vorgestellt habe: Ein AI-Agent läuft auf dem Computer, man kann bereits zwei Agenten in zwei Fenstern ausführen, was ist der Unterschied? Diese Formulierung war falsch, und um herauszufinden, warum sie falsch war, brauchte ich etwa eine Stunde Testzeit.

Der Unterschied ist gemeinsamer Kontext. Wenn Sie einen Thread in Codex forken, erben beide Zweige den gesamten Konversationsverlauf, den Projektstatus, die Plugins, die Anmeldeinformationen und die teilweise erstellten Artefakte bis zum Fork-Punkt. Es handelt sich nicht um zwei getrennte Sitzungen. Es handelt sich um zwei Zweige derselben Sitzung, was bedeutet, dass der Marketing-Fork genau weiß, welche Funktionen der Engineering-Fork ausliefert, dass der Engineering-Fork weiß, zu welcher Positionierung der Marketing-Fork sich verpflichtet, und dass alle Änderungen an gemeinsamen Artefakten (z. B. dem Speicher des Projekts) auf beide Zweige übertragen werden.

Ich habe es in der Gründer-Meetups-App aus Test 2 getestet. Nachdem der Build abgeschlossen war, habe ich den Thread gespalten. Zweig A: „Entwerfen und erstellen Sie drei Pitch-Deck-Folien, die einem potenziellen Sponsor dieses Produkt erklären.“ Zweig B: „Entwerfen Sie ein 90-sekündiges Startvideoskript, das ich über eine Bildschirmaufzeichnung der App aufzeichnen könnte.“ Ich habe sie gleichzeitig ausgeführt.

Abteilung A erstellte in etwa drei Minuten drei Folien – Problem, Produkt, Traktionsprojektion. Die Folien verwiesen auf bestimmte Funktionen, die Codex zehn Minuten zuvor entwickelt hatte: den Schalter für verifizierte Gründer, die stadtbasierte Entdeckung, den RSVP-Flow. Keine allgemeinen Funktionsansprüche. Tatsächliche Verweise auf tatsächliche Codepfade.

Zweig B erstellte ein Skript, das mit „Wenn Sie jemals zu einem sogenannten Gründertreffen erschienen sind und in einen Raum voller Leute gegangen sind, die ihr MLM vorstellten, ist diese App genau das Richtige für Sie“ – worüber ich laut lachen musste, denn dieser Anfang war ein direkter Rückruf auf eine klärende Frage, die ich zuvor im ursprünglichen Thread vierzehn Nachrichten beantwortet hatte, in der ich erklärt hatte, dass das Unterscheidungsmerkmal die Gründerüberprüfung sei. Zweig B hatte diesen Kontext geerbt und ihn verwendet, um ein Skript zu schreiben, das ohne ihn nicht möglich gewesen wäre.

Das ist die Einsicht. Bei gegabelten Threads geht es nicht um Parallelität. Es geht um kontextkohärente Parallelität. Zwei AI-Agenten arbeiten an verwandten Teilaufgaben und teilen dabei das gleiche Verständnis des Projekts, des Benutzers und der Artefakte – ohne dass ein Agent den anderen informieren muss. Das ist ein Workflow, den es vor einem Jahr wirklich noch nicht gab, und er kommt dem „Ein AI-Team zu haben“, das die aktuelle Generation von Agenten hervorgebracht hat, am nächsten. Das Video stimmt, dass sich dadurch etwas ändert. Das Video ist falsch bezüglich des Warum. Es ist nicht die Geschwindigkeit. Es ist die Kohärenz.

Ich habe in den letzten zwei Wochen nun drei echte Workflows rund um gespaltene Threads erstellt: Code-and-Docs (Engineering-Zweig + Dokumentationszweig aus derselben Spezifikation), Build-and-Launch (Produktzweig + Marketing-Zweig aus demselben MVP) und Audit-and-Fix (Sicherheitsüberprüfungszweig + Korrekturzweig aus derselben Codebasis). Alle drei erzeugen Ausgaben, die auf eine Weise zusammenpassen, wie es zwei separate AI-Sitzungen niemals könnten. Das ist die Freischaltung.

Wo das Video zu viel verkauft und wo es zu wenig verkauft

Nach vier Testtagen hier die ehrliche Aufteilung.

Überverkauft:

Die Formulierung „ChatGPT-Nutzer werden bis 2026 zurückfallen“ ist Marketing. ChatGPT verschwindet nicht. Codex ist eine andere Oberfläche für eine andere Arbeitskategorie. Es ersetzt ChatGPT nicht für den durchschnittlichen Benutzer. Es ersetzt Tools, die Sie für die Power-User-Kategorie noch nicht haben.

Die Zeiteinsparungsansprüche sind aggressiv. Die Newsletter-Automatisierung spart keine Stunde am Tag. Die App-Erstellung erfolgt nicht in wenigen Minuten. Die autonome Fehlerbehebung fängt nicht jeden Fehler ab. Die Formulierung „keine Programmierkenntnisse erforderlich“ trifft technisch gesehen auf glückliche Pfade zu und ist äußerst irreführend für jedes Projekt, das auf einen echten Grenzfall trifft. Wenn Sie einen Stack-Trace nicht lesen können, stoßen Sie am dritten Tag, wenn Sie etwas Nicht-Triviales bauen, an eine Wand.

Der unbestätigte Name des Design-Tools. Wie ich bereits erwähnt habe, kann ich „Paper“ als Codex-Designtool nicht anhand der offiziellen Codex-Dokumentation von OpenAI oder dem Änderungsprotokoll der Entwickler bestätigen. Das Figma-Plugin ist echt. Andere Designtools funktionieren im Computermodus. Ob „Paper“ ein bestimmtes Produkt, ein Beta-Tool oder eine Umbenennung von etwas anderem ist, weiß ich nicht.

Unterverkauft:

Die Automatisierungsfunktion ist im Video versteckt und stellt die eigentliche Super-App-Freischaltung dar. Geplante Hintergrundarbeit, die über Tage oder Wochen hinweg ausgeführt wird, mit vollem Plugin-Zugriff und dauerhaftem Speicher, ist eine wirklich neue Kategorie der Produktivitätsinfrastruktur. Die meisten Menschen werden es zu wenig nutzen, weil sie ihre Arbeit nicht im Hinblick auf geplante Aufgaben betrachten. Wer es schafft, wird die Nase vorn haben.

Das Forked-Thread-Kontextkohärenzmuster wird mit AI auf eine „Parallelarbeit“-Demonstration reduziert, obwohl es sich tatsächlich um ein grundlegend neues Kooperationsmodell handelt. Ich denke, dass dies die größte Workflow-Veränderung in der gesamten Version ist.

Die autonome Fehlererkennungs- und -behebungsschleife wird kurz vorgestellt, ihre Auswirkungen sind jedoch enorm. Ein Agent, der seine eigene Konsolenausgabe lesen, Probleme identifizieren und sich selbst korrigieren kann, ist der Unterschied zwischen einem Tool, das Sie ständig überwachen, und einem Tool, das Sie überprüfen. Dadurch ändert sich die Einheitsökonomie, wie viel Sie pro Tag bauen können.

Der Plugin-Marktplatz als Sicherheitsarchitektur wird kaum erwähnt. Gemäß der Plugin-Marktplatzabdeckung in The Decoder ist jedes Plugin eine eigenständige Gewährung von Funktionen, die auf bestimmte Daten und Tools beschränkt sind. Auf diese Weise schaffen Sie Vertrauen in einen autonomen Agenten – indem Sie jede Funktion überprüfbar machen. Das Video überspringt dies, weil es nicht sexy ist. Dies ist der Teil, der für die Unternehmensakzeptanz am wichtigsten ist.

Der Arbeitsablauf, der meinen tatsächlich verändert hat

Wenn ich aus diesen vier Tagen eine Schicht auswählen müsste, die ich in den Mai vorziehe, dann diese: Ich betrachte AI-Arbeit nicht länger als „Aufforderung senden, Ausgabe empfangen“. Ich betrachte es als „Arbeitsbereich einrichten, Zugriff gewähren, wiederkehrende Arbeiten planen und regelmäßig einchecken.“

Das klingt offensichtlich, wenn man es ausschreibt. Dies ist nicht die Art und Weise, wie die meisten Menschen AI im Jahr 2026 verwenden. Die meisten Menschen leben immer noch im Prompt-and-Response-Zyklus und behandeln jede AI-Interaktion als eine einmalige Transaktion. Der eigentliche Beitrag der Super-App Codex AI besteht darin, den Arbeitsbereich zur Einheit der Interaktion zu machen. Projekte enthalten einen dauerhaften Kontext. Plugins erhöhen die Reichweite. Automatisierungen werden nach Zeitplänen ausgeführt. Gegabelte Threads ermöglichen eine kohärente Parallelität. Bei keinem davon geht es um eine einzelne Eingabeaufforderung. Bei allen geht es um eine dauerhafte Infrastruktur.

Der Unterschied zwischen AI-Power-Usern und AI-Touristen in der zweiten Hälfte des Jahres 2026 ist die Frage, ob sie diesen Wandel vollziehen. Die Touristen werden weiterhin Eingabeaufforderungen eingeben. Die Power-User werden zehn Automatisierungen ausführen, an die sie kaum denken, drei Projekte mit tiefem Kontext und Forked-Thread-Workflows, die an einem Nachmittag kohärente Multi-Output-Arbeit produzieren.

Ich gehe nicht davon aus, dass ChatGPT-Benutzer ins Hintertreffen geraten werden. Das ist die Art von YouTube-Übertreibung, die stark altert. Aber ich sage Folgendes: Wenn Sie AI immer noch verwenden, indem Sie etwas in ein Chatfeld eingeben und auf eine Antwort warten, machen Sie mit demselben Abonnement, für das Sie bereits bezahlen, etwa 15 % dessen, was derzeit möglich ist. Die anderen 85 % leben in der Super-App-Oberfläche. Und es ist nicht mehr theoretisch. Es ist ausgeliefert, es läuft und es wird von Leuten verwendet, die in aller Stille alle übertreffen, die sich nicht die Mühe gemacht haben, es zu lernen.

Heute Abend lohnt es sich, sich mit einer Frage auseinanderzusetzen: Wenn Sie jetzt Codex öffnen und versuchen würden, eine einzelne Automatisierung einzurichten, die jeden Morgen vor dem Aufwachen ausgeführt wird, was würde sie tun? Wenn die Antwort „Ich weiß nicht“ lautet, ist das die Lücke. Es zu schließen ist die Arbeit.

Häufig gestellte Fragen

Was ist die Super-App Codex AI?

Die Super-App Codex AI ist der Desktop-Agent von OpenAI, der hauptsächlich auf GPT-5.5 läuft und Codierung, Computernutzung, einen in-app browser, Plugins für Tools wie Slack und Die Super-App-Überarbeitung wurde am 16. April 2026 als Codex Desktop v26.415 ausgeliefert und ist in kostenpflichtigen ChatGPT-Plänen enthalten und nicht separat erhältlich.

Ist Codex dasselbe wie ChatGPT?

Nein. ChatGPT bleibt die web/mobile-Konversationsschnittstelle; Codex ist die Agenten-Desktop-Ebene.

Auf welchem Modell läuft Codex eigentlich?

Gemäß der Codex-Modelldokumentation von OpenAI leitet Codex je nach Aufgabenklasse und Abonnementstufe zwischen GPT-5.5, GPT-5.5 Pro und älteren 5-Codex-Varianten weiter. Agentische Aufgaben mit hohem Aufwand werden in der Regel auf GPT-5.5 mit aktivierter besonders hoher Argumentation ausgeführt, während leichtere Aufgaben schnellere Prüfpunkte verwenden, um die Latenz angemessen zu halten.

Kann Codex wirklich eine vollständige App ohne Codierung erstellen?

Teilweise. Codex kann ein funktionierendes MVP über eine Eingabeaufforderung in natürlicher Sprache planen, aufbauen, erstellen und selbst testen – siehe Test 2 oben für eine echte vierstündige Sitzung, die eine funktionsfähige Next.js 15-App erstellt hat. Aber es fängt nicht jeden Fehler ab, das Ergebnis ist ohne Feinschliff selten produktionsbereit und Sie müssen immer noch Stack-Traces lesen, wenn Randfälle die autonome Schleife unterbrechen.

Was ist der Unterschied zwischen Projekten, Plugins und Automatisierungen?

Projekte sind dauerhafte Arbeitsbereiche, die Dateien, Konversationsverlauf und Anmeldeinformationen für einen bestimmten Bereich speichern. Plugins sind Integrationen (Slack, Notion, Figma, Gmail und über 90 andere), die die Reichweite von Codex auf externe Tools erweitern. Automatisierungen sind geplante, kopflose Agentenläufe, die definierte Aufgaben auf einen Auslöser hin ausführen – sie sind die Ebene, die Codex wie eine Super-App und nicht wie einen Chatbot wirken lässt. Die vollständige Aufschlüsselung finden Sie oben im Abschnitt „Drei Säulen“.

Lasst uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
Portfolio: mejba.me
Ramlit Limited (Unternehmenslösungen): ramlit.com
ColorPark (Design & Branding): colorpark.io
xCyberSecurity (Sicherheitsdienste): xcybersecurity.io

Codex AI Super App: GPT-5.5 Workflow-Test