Codex AI Super App: GPT-5.5 Workflowtest
Een vriend stuurde me op dinsdag om 23:14 uur een YouTube-link met de boodschap "kijk dit en vertel me dan dat je nog steeds loyaal bent aan ChatGPT." De video was een dertien minuten durende walkthrough van een maker genaamd Vaibhav, en zijn stelling was dat iedereen die in 2026 nog ChatGPT gebruikte al een jaar achterliep. De reden, zo beweerde hij, was een product genaamd Codex – een AI super-app op GPT-5.5 die apps als een productmanager kon plannen, gebruikersinterfaces kon ontwerpen door een cursor in ontwerptools te besturen, chatthreads kon splitsen om ontwikkeling en marketing parallel uit te voeren, en elke ochtend stilletjes PowerPoints vanuit je Gmail kon bouwen terwijl je sliep.
Ik heb het twee keer bekeken. Toen klapte ik mijn laptop dicht en ging geïrriteerd naar bed, want de helft van wat hij liet zien had ik al twee weken getest, en de andere helft klonk als het soort demo dat kapot gaat zodra je hem uit de rails haalt.
Dus bracht ik de volgende vier dagen door met het uitvoeren van de Codex AI super-app volgens de exacte workflows in die video. De Gmail-naar-PowerPoint-automatisering. De prompt 'Bouw een app voor offline oprichtersbijeenkomsten voor mij'. Het parallelle werk met gevorkte draad. De autonome bugfixing. Ik laat het koken via echte gegevens, echte mislukkingen en echte verrassende overwinningen. Ik heb ook de beweringen achterna gezeten die ik niet kon verifiëren - de 'Paper'-ontwerptool die hij een naam geeft, het precieze GPT-5.5-model achter de Codex-aanroepen, de prijzen die hij verdoezelt - omdat de helft van het AI YouTube-ecosysteem in 2026 is gebouwd op namen die niet helemaal overeenkomen met wat er daadwerkelijk wordt verzonden.
Dit is wat echt is. Dit is wat er oververkocht is. En dit is waar de workflow die van mij feitelijk veranderde - inclusief het moment waarop een gevorkte draad tegelijkertijd een marketingdeck en een werkende app verscheepte, en ik besefte dat ik had nagedacht over parallel AI-werk, helemaal verkeerd.
Laten we eerst de naamgeving en het model duidelijk maken
Voordat ik ook maar één enkele workflow aanraak, moet datgene wat in de video wordt verdoezeld eerst worden opgesomd - want als je zonder context gaat zoeken naar "Codex super app" of "GPT-5.5", zul je binnen dertig seconden in de war raken.
Het product heet Codex en ja, het is van OpenAI. Geen verpakking van derden. Geen fanproject. De desktop-app heeft zijn "super-app" -revisie op 16 april 2026 uitgebracht als Codex Desktop v26.415 per OpenAI's changelog, en het GPT-5.5-model dat het grootste deel van het nieuwe agentgedrag aanstuurt, werd op 24 april 2026 algemeen beschikbaar in de API. volgens TechCrunch's berichtgeving over de lancering. Dat is de tijdlijn. De 'super-app'-framing in de video is reëel: het komt rechtstreeks voort uit OpenAI's eigen positionering volgens het TechCrunch-verhaal, en de visie van Sam Altman om ChatGPT, Codex en de Atlas-browser samen te voegen tot één verenigd product is nu openbare berichtenuitwisseling.
Wat de video niet vermeldt, is dat Codex standaard niet altijd op GPT-5.5 draait. Per OpenAI's Codex-modellenpagina routeert Codex tussen GPT-5.5, GPT-5.5 Pro en de oudere 5-Codex-varianten, afhankelijk van de taakklasse en uw abonnementsniveau. Sommige taken worden uitgevoerd op GPT-5.5 met extra hoge redeneringsinspanning. Sommige draaien op lichtere controlepunten om de latentie redelijk te houden. Als u ChatGPT Plus gebruikt, krijgt u GPT-5.5-toegang, maar met beperkt gebruik. Als je het nieuwe Pro-niveau hebt voor $ 200/month, krijg je de toewijzing "5x meer Codex-gebruik" die OpenAI adverteert, samen met eerste toegang tot de zwaarste redeneermodi.
Dit is van belang omdat de video demo's toont die vrijwel zeker gebruik maakten van de redeneerpaden met de hoogste inspanning. Als u zijn aanwijzingen repliceert op een Plus-account, krijgt u niet dezelfde snelheden, dezelfde diepgaande planning of hetzelfde vergevingsgezinde foutherstel. Dat is geen bug, maar de prijs van het product. Maar het is het deel dat stilletjes wordt overgeslagen in virale demo's, en als je dit overslaat, raak je teleurgesteld.
Nog één verduidelijking van de naamgeving voordat we verder gaan. Vaibhav demonstreert op een gegeven moment Codex "ontwerpen in een ontwerptool genaamd Paper, door de cursor te besturen en live lay-outs te maken." Ik ging op zoek naar "Paper" als een Codex-geïntegreerd ontwerptool en kon het niet verifiëren als een huidige Codex-plug-in. Er is een Figma blogpost over Codex die integreert met Figma - die echt is en verzonden. Er is een lange reeks ontwerptools die werken via de computergebruiksmodus van Codex, waarmee je door elke desktop-app kunt klikken. "Paper" kan de naam van Vaibhav zijn voor een van deze producten, het kan een bètaproduct zijn waartoe ik geen toegang heb, of het kan een tool zijn die ik gewoonweg mis. Ik markeer het als niet-geverifieerd in plaats van te doen alsof ik het heb bevestigd. Dat is de eerlijke beslissing.
Hier wordt het echter interessant: zelfs met de modelrouting, de prijsniveaus en de niet-geverifieerde ontwerptool zijn de onderliggende workflowverschuivingen in de video reëel. De manier waarop Codex hoe u werkt herstructureert, is het eigenlijke verhaal. En wat mij het hardst raakte waren niet de demo's waarmee hij leidt. Het was degene die de meeste kijkers waarschijnlijk hebben overgeslagen.
De drie pijlers: projecten, plug-ins, automatiseringen — en waarom de volgorde ertoe doet
De videoframes Codex hebben drie kernfuncties: projecten, plug-ins en automatiseringen. Dat kader klopt. Wat hij fout doet, is dat hij ze als parallelle kenmerken behandelt. Dat zijn ze niet. Het zijn opeenvolgende lagen, en het missen van de volgorde is de reden waarom de meeste mensen die Codex proberen er binnen een week weer vanaf zijn.
Projecten vormen de basis. Een project in Codex is een permanente werkruimte die bestanden, gesprekken, geheugen en toegangsrechten voor een specifiek werkgebied bundelt. Als ik aan een Laravel-klantbetrokkenheid werk, is dat een project. Wanneer ik AI-modelreleases voor de blog onderzoek, is dat een apart project. Het Project is wat de context bevat: de bestanden die Codex heeft gelezen, de beslissingen die jullie samen hebben genomen, de referenties die jullie eraan hebben toegekend, de toon en de conventies die het moet volgen. Zonder een project begint elke Codex-interactie vanaf nul.
Plug-ins zijn de manier waarop Codex buiten het project naar de rest van uw werk reikt. Er zijn nu ruim negentig plug-ins per OpenAI's plug-inmarktaankondiging gedekt door The Decoder - Slack, Notion, Figma, Gmail, Google Drive, GitHub, GitLab, Atlassian, Render, Neon, Remotion en een lange reeks anderen. Elke plug-in kan drie dingen bevatten met dezelfde dekking: vaardigheden (herbruikbare promptpatronen), apps (integratie-eindpunten) en MCP-servers (de daadwerkelijke toegang tot gegevens en tools). Dankzij de plug-in kan Codex niet alleen praten over uw Notion-documenten, maar ze ook daadwerkelijk lezen, schrijven en reorganiseren. Zonder plug-ins is Codex een briljante werknemer zonder e-mail en zonder agenda.
Automatiseringen zijn de laag die de meeste mensen overslaan – en het is de laag waarin de volledige waardepropositie van de super-app leeft. Een automatisering in Codex is een geplande, headless agent-run die wordt geactiveerd op een trigger (tijd, gebeurtenis of webhook) en een gedefinieerde taak uitvoert met behulp van de projecten en plug-ins waartoe hij toegang heeft. Volgens OpenAI's Codex-pagina kan Codex nu "toekomstig werk voor zichzelf plannen en automatisch wakker worden om door te gaan met een langetermijntaak, mogelijk over dagen of weken." Dat is de lijn die stilletjes de lede begraaft.
Dit is waarom de volgorde ertoe doet. Als u plug-ins instelt vóór Projecten, worden uw plug-in-machtigingen rommelig en overbemeten. Codex krijgt uiteindelijk inloggegevens die het niet nodig heeft, in bereiken die het niet zou moeten hebben. Als u Automatiseringen instelt voordat u het gedrag van een project volledig hebt getest, wordt u wakker en merkt u dat een geplande agent al een week lang dagelijks iets subtiel verkeerds doet. Ik maakte beide fouten in week één. Door ze op te lossen, heb ik geleerd om Codex op dezelfde manier in te richten als een nieuwe medewerker: geef ze eerst een bureau, dan hun gereedschap en dan hun terugkerende verantwoordelijkheden. Niet andersom.
Het andere wat de video niet zegt: elke plug-in en elke automatisering is een beveiligingsoppervlak. Het frame van "volledige toegang" in de demo van Vaibhav verdoezelt het feit dat u in de praktijk een autonome agent persistente OAuth-scopes toekent aan uw bedrijfssystemen. Ik wil dat op de plaat hebben voordat ik beschrijf wat ik ermee heb gebouwd.
Test 1: De Gmail-naar-PowerPoint-nieuwsbriefautomatisering
Dit is de demo waarmee Vaibhav opent, en hier was ik het meest sceptisch over. De pitch: elke ochtend controleert Codex uw Gmail op de laatste nieuwsbrief, haalt de belangrijkste inzichten eruit, genereert een PowerPoint-samenvatting en plaatst deze in uw inbox. Hij beweert dat het hem een uur per dag bespaart.
Ik heb het gebouwd. Dit is wat er feitelijk is gebeurd.
Het instellen kostte me drieëntwintig minuten. De authenticatie van de Gmail-plug-in was de langste stap: Codex vereist dat u de bereiken zorgvuldig toekent, en de OAuth-stroom leidt u door welke mappen, welke labels en welke afzenderfilters het moet respecteren. Ik heb het beperkt tot een enkel Gmail-label met de naam daily-read waarin ik interessante nieuwsbrieven tag. Ik heb hem geen toegang tot mijn volledige inbox gegeven, omdat ik niet iemand ben die een autonome agent onbeperkte Gmail-toegang geeft alleen maar om een nieuwsbrief samen te vatten, en dat zou jij ook niet moeten zijn.
De automatisering zelf was een definitie van vijf regels in natuurlijke taal: "Zoek elke weekdag om 8.00 uur nieuwsbrieven in daily-read van de afgelopen 24 uur, extraheer de drie belangrijkste inzichten uit elk, genereer een enkel PowerPoint-deck waarin ze worden samengevat met één dia per nieuwsbrief plus een voorbladdia, en stuur het dek als bijlage naar mijn inbox."
Ik heb het vijf werkdagen laten draaien. Hier is de eerlijke scorekaart.
Dag één: Het werkte perfect. Drie nieuwsbrieven, drie dia's plus omslag, de opmaak was helder, de samenvattingen waren accuraat. Ik las het kaartspel in minder dan negentig seconden en voelde me zelfvoldaan.
Dag twee: Er werd een nieuwsbrief binnengehaald die eigenlijk een wekelijkse samenvatting was met zeven onderwerpen, en de hele samenvatting werd samengevat in één enkel inzicht, waarbij vijf van de zeven onderwerpen ontbraken. Het deck was technisch correct maar praktisch nutteloos.
Dag drie: Het werkte weer perfect, maar er stond een sponsorbericht uit een van de nieuwsbrieven bij alsof het een echt inzicht was. Die maakte me aan het lachen omdat het zo'n duidelijke AI-samenvattingsfout was: het model kon redactionele inhoud niet onderscheiden van betaalde plaatsing als de sponsor netjes genoeg was geïntegreerd.
Dag vier: Er is een time-out opgetreden bij de uitvoering van Codex omdat Gmail die ochtend traag was en de automatisering geen logica voor opnieuw proberen had. Het dek is niet aangekomen. Ik merkte het pas om 10.00 uur, en op dat moment had ik de nieuwsbrieven toch al handmatig doorgenomen.
Dag vijf: Werkte perfect.
Dus het oordeel over de Gmail-naar-PowerPoint-automatisering: het is echt, het is nuttig, het bespaart tijd op de dagen dat het werkt, en het is geen besparing van één uur per dag. Het is meer een besparing van vijftien tot twintig minuten op de dagen dat het correct werkt, en nul of negatief op de dagen dat het niet werkt. De video overtreft de tijdbesparing met ongeveer 3x. Maar het is echt het soort achtergrondwerk dat niemand eerder betrouwbaar deed, en de richtinggevende claim – dat deze categorie van automatisering nu mogelijk is zonder code te schrijven – is correct.
De grotere les uit deze test: automatiseringen hebben waarneembaarheid nodig. Na dag vier heb ik een tweede automatisering toegevoegd die alleen de success/failure-status van de eerste registreert op een Notion-pagina, zodat ik dagelijks een grootboek heb van welke runs werkten en welke niet. Dat soort meta-automatisering wordt in de video helemaal overgeslagen, en het is het verschil tussen een automatisering die je vertrouwt en een automatisering waarop je moet babysitten.
Test 2: een offline Founder Meetups-app bouwen zonder code
Dit is de demo die viraal gaat telkens wanneer Vaibhav er een fragment van opnieuw uploadt. Hij vraagt Codex om "een app te bouwen voor offline bijeenkomsten voor oprichters in Bangalore en San Francisco." Codex fungeert als een productmanager: hij stelt verduidelijkende vragen, plant de gebruikersinterface, ontwerpt de lay-out in wat hij Paper noemt en plant vervolgens de volledige build (database, routes, componenten) voordat hij een regel code schrijft. Halverwege de build gebruikt hij een "Steer" -functie om de reikwijdte live aan te passen zonder de agent te onderbreken. Codex test vervolgens autonoom de app op desktop en mobiel, vindt bugs, plant oplossingen, implementeert deze en test opnieuw. Geen menselijke inbreng.
Ik heb geprobeerd het zo goed mogelijk na te bootsen. Mijn opdracht: "Bouw een webapp van één pagina voor mij waar oprichters offline meetups in hun stad kunnen posten en ontdekken. Moet ondersteuning bieden voor het vermelden van meetups, deelname aan meetups en een basisprofiel per gebruiker. Database kan voorlopig SQLite zijn. Stapel je oproep."
Dit is wat er feitelijk gebeurde tijdens een echte sessie van vier uur.
Codex begon met het stellen van zes verhelderende vragen: precies het gedrag van de productmanager dat in de video wordt getoond. De vragen waren goed: wilde ik authenticatie, welke steden moesten bij de lancering worden ondersteund, was het een marktplaats of een directory, wat betekende 'lid worden' (alleen RSVP of betaalde ticketing), wat hadden profielen nodig, en werd dit gehost of lokaal. Ik beantwoordde ze binnen twee minuten.
Vervolgens werd een stapel voorgesteld: Next.js 15 met App Router, Prisma via SQLite, Tailwind en shadcn/ui componenten. Het legde uit waarom: snelle iteratie, geen externe services voor v1, gemakkelijk later naar Postgres te migreren. Ik ging akkoord.
De planningsfase was het onderdeel waarop ik mijn verwachtingen moest bijstellen. Codex genereerde een bouwplan met drieëntwintig taken voor het datamodel, routes, componenten, verificatie en testen. Het was goed. Beter dan wat de meeste junior-ingenieurs zouden schrijven. Maar het was niet, zoals de video impliceert, onmiddellijk. De planningsfase alleen al kostte ongeveer vier minuten 'denken' met een hoge redeneerinspanning, en het is lang niet zo opwindend om dat denken in realtime te zien gebeuren als de bezuinigingen op YouTube-demo's suggereren.
De build zelf duurde ongeveer twee uur en twintig minuten. Gedurende die tijd schreef Codex ongeveer 4.200 regels code in 38 bestanden, draaide de dev-server zelf en testte de app in zijn in-app browser door door elke stroom te klikken. Ik heb het equivalent van "Steer" gebruikt - wat in de huidige Codex-gebruikersinterface een klein invoervak bovenaan de lopende thread is waarmee je aanpassingen in het midden van de build kunt injecteren - twee keer. Eén keer om een ander kleurenschema te vragen. Eén keer om een schakelaar 'geverifieerde oprichter' aan profielen toe te voegen. Beide aanpassingen werden geabsorbeerd zonder dat de build opnieuw werd gestart.
De autonome lus voor het detecteren en oplossen van bugs is echt en indrukwekkend. Tijdens de build heeft Codex drie keer problemen in zijn eigen werk gedetecteerd (een keer een Prisma-migratierace-conditie, een keer een botsing van de Tailwind-klasse, een keer een hydratatiefout in een servercomponent) en deze opgelost zonder het mij te vragen. Ik zag het gebeuren. Het transcript laat zien dat Codex zijn eigen console-uitvoer leest, de fout identificeert, een oplossing plant, de oplossing toepast en de test opnieuw uitvoert. Die lus, meer dan al het andere in de build, is wat ervoor zorgt dat de super-app Codex AI zich categorisch anders voelt dan een coderende copiloot.
Wat de video niet laat zien: de build leverde ook twee echte bugs op die Codex niet zelf opmerkte. De stroom 'deelnemen aan de meetup' creëerde een RSVP-record, maar retourneerde niet het aantal nieuwe bezoekers, waardoor de gebruikersinterface verouderde gegevens vertoonde totdat deze werd vernieuwd. En met het formulier voor het maken van een meetup kun je het indienen met een lege locatiestring, waardoor de ontdekkingspagina kapot ging. Ik ving beide handmatig op in een kwartiertje rondklikken. Nadat ik ze had aangewezen, repareerde Codex ze elk binnen een minuut. De autonomie is dus reëel maar beperkt: ze vangt op wat de geautomatiseerde tests opvangen, en ze mist wat een menselijke gebruiker opvangt door de app te gebruiken zoals een mens een app gebruikt.
Eindstatus van de build: een functionele Next.js 15-app die ik realistisch gezien naar een kleine privébèta zou kunnen verzenden. Niet op productieniveau. De verificatie vond alleen via e-mail plaats, er waren geen snelheidsbeperkingen en er waren geen goede foutgrenzen op de gebruikersgerichte routes. Waarschijnlijk nog acht uur menselijk poetswerk voordat ik het aan betalende gebruikers zou laten zien. Maar absoluut een MVP zou ik twee dagen solo hebben gebouwd, gecomprimeerd tot een middag waarbij Codex vijfentachtig procent van het werk zou doen.
De richtinggevende claim in de video – dat je apps kunt bouwen zonder code te schrijven – is reëel. De implicatie dat het resultaat verzendbaar is zoals het is, is dat niet. Iedereen die je iets anders vertelt, verkoopt je een cursus.
Test 3: gevorkte draden en waarom ik dacht aan parallelle AI verkeerd
Dit is de test waarbij mijn frame van het hele bericht kapot ging.
Vaibhav demonstreert tijdens een gesprek een Codex-chatthread, dus de ene fork gaat door met het bouwen van de app, terwijl de tweede fork een sponsorpitchdeck en een lanceringsvideo voor hetzelfde product genereert. Hij laat zien dat beide vorken parallel produceren. Totaal verstreken tijd: enkele minuten voor beide uitgangen.
Ik had gevorkte threads eerder afgedaan als een gimmick. Zoals ik erover nadacht: een AI-agent draait op compute, je kunt al twee agenten in twee vensters uitvoeren, wat is het verschil. Dat kader was verkeerd, en het kostte me ongeveer een uur testen om erachter te komen waarom het verkeerd was.
Het verschil is gedeelde context. Wanneer u een thread afsplitst in Codex, nemen beide vertakkingen de volledige gespreksgeschiedenis, de projectstatus, de plug-ins, de inloggegevens en de gedeeltelijk gebouwde artefacten tot aan het afsplitsingspunt over. Het zijn geen twee afzonderlijke sessies. Het zijn twee takken van dezelfde sessie, wat betekent dat de marketingfork precies weet welke functies de engineeringfork verzendt, de engineeringfork weet aan welke positionering de marketingfork zich verbindt, en dat eventuele bewerkingen van gedeelde artefacten (bijvoorbeeld het geheugen van het project) zich over beide verspreiden.
Ik heb het getest in de Founder Meetups-app van Test 2. Nadat de build was voltooid, heb ik de draad gesplitst. Tak A: "ontwerp en genereer drie pitchdeck-dia's waarin dit product aan een potentiële sponsor wordt uitgelegd." Tak B: "maak een lanceringsvideoscript van 90 seconden dat ik kan opnemen via een schermopname van de app." Ik heb ze tegelijkertijd uitgevoerd.
Tak A produceerde in ongeveer drie minuten drie dia's: probleem, product, tractieprojectie. De dia's verwezen naar specifieke functies die Codex tien minuten eerder had gebouwd: de schakelaar voor geverifieerde oprichters, de stadsgebaseerde ontdekking, de RSVP-stroom. Geen algemene functieclaims. Werkelijke verwijzingen naar daadwerkelijke codepaden.
Branch B produceerde een script dat opende met "als je ooit bent verschenen bij een zogenaamde oprichtersbijeenkomst en een ruimte bent binnengelopen waar mensen hun MLM pitchen, dan is deze app iets voor jou" - waardoor ik hardop moest lachen, omdat die opening een directe terugroep was naar een verhelderende vraag die ik veertien berichten eerder in de oorspronkelijke thread had beantwoord, waarin ik had uitgelegd dat de onderscheidende factor oprichterverificatie was. Tak B had die context geërfd en gebruikt om een script te schrijven dat zonder deze context niet mogelijk zou zijn geweest.
Dat is het inzicht. Gevorkte draden gaan niet over parallellisme. Ze gaan over context-coherent parallellisme. Twee AI-agenten die aan gerelateerde subtaken werken en tegelijkertijd hetzelfde inzicht in het project, de gebruiker en de artefacten delen, zonder dat de ene agent de andere hoeft te briefen. Dat is een workflow die een jaar geleden nog niet bestond, en die het dichtst in de buurt komt van het "hebben van een AI-team" dat de huidige generatie agenten heeft voortgebracht. De video heeft gelijk dat dit dingen verandert. De video klopt niet over waarom. Het is niet de snelheid. Het is de samenhang.
Ik heb de afgelopen twee weken nu drie echte workflows rond gevorkte threads gebouwd: code-en-docs (engineeringtak + documentatietak van dezelfde specificatie), build-and-launch (producttak + marketingtak van dezelfde MVP), en audit-and-fix (beveiligingsbeoordelingstak + hersteltak van dezelfde codebase). Alle drie produceren ze resultaten die in elkaar passen op een manier die twee afzonderlijke AI-sessies nooit zouden kunnen. Dat is de ontgrendeling.
Waar de video te veel en te weinig verkoopt
Na vier dagen testen is hier de eerlijke verdeling.
Oververkocht:
Het frame ‘ChatGPT-gebruikers zullen in 2026 achterop raken’ is marketing. ChatGPT verdwijnt niet – Codex is gebouwd bovenop dezelfde modelfamilie, toegankelijk via hetzelfde account, en de conversatie-interface is nog steeds de plek waar in de nabije toekomst 90% van het informele AI-gebruik zal plaatsvinden. Codex is een ander oppervlak voor een andere categorie werk. Het vervangt ChatGPT niet voor de gemiddelde gebruiker. Het vervangt tools die je nog niet hebt voor de categorie power-users.
De claims over tijdbesparing zijn agressief. De nieuwsbriefautomatisering bespaart geen uur per dag. Het bouwen van de app gebeurt niet in minuten. De autonome bugfixing vangt niet elke bug op. De formulering "geen codeervaardigheid vereist" is technisch gezien waar voor gelukkige paden en ernstig misleidend voor elk project dat een echt randgeval tegenkomt. Als je een stapeltracering niet kunt lezen, loop je op dag drie tegen een muur aan als je iets niet-triviaal bouwt.
De niet-geverifieerde naam van het ontwerptool. Zoals ik eerder heb opgemerkt, is "Papier" als Codex-ontwerptool niet iets dat ik kan bevestigen aan de hand van OpenAI's officiële Codex-documentatie of de changelog van de ontwikkelaars. De Figma-plug-in is echt. Andere ontwerptools werken via de computergebruiksmodus. Of "Paper" een specifiek product is, een bètatool of een hernoeming van iets anders, weet ik niet.
Onderverkocht:
De Automatiseringsfunctie is verborgen in de video en is de daadwerkelijke ontgrendeling van de super-app. Gepland werk op de achtergrond dat over dagen of weken wakker wordt, met volledige toegang tot plug-ins en permanent geheugen, is een werkelijk nieuwe categorie productiviteitsinfrastructuur. De meeste mensen zullen er te weinig gebruik van maken, omdat ze niet over hun werk nadenken in termen van geplande taken. Degenen die dat wel doen, zullen voorop blijven lopen.
Het context-coherentiepatroon met gevorkte threads wordt gereduceerd tot een demo van "parallel werk", terwijl het feitelijk een fundamenteel nieuw samenwerkingsmodel is met AI. Ik denk dat dit de grootste workflowverschuiving in de hele release is.
De autonome lus voor het detecteren en oplossen van bugs wordt kort getoond, maar de implicaties ervan zijn enorm. Een agent die de eigen console-uitvoer kan lezen, problemen kan identificeren en zichzelf kan corrigeren, is het verschil tussen een tool waarop u voortdurend toezicht houdt en een tool waarop u incheckt. Dat verandert de eenheidseconomie van hoeveel u per dag kunt bouwen.
De plug-inmarktplaats als beveiligingsarchitectuur wordt nauwelijks genoemd. Volgens de dekking op de marktplaats voor plug-ins in The Decoder, is elke plug-in een discrete toekenning van mogelijkheden, beperkt tot specifieke gegevens en tools. Zo bouw je vertrouwen op in een autonome agent, door elke mogelijkheid controleerbaar te maken. De video slaat dit over omdat het niet sexy is. Het is het onderdeel dat het belangrijkst is voor de adoptie door bedrijven.
De workflow die de mijne daadwerkelijk heeft veranderd
Als ik één dienst zou moeten kiezen uit deze vier dagen die ik doorzet naar mei, dan is het deze: ik beschouw het werk van AI niet langer als 'prompt verzenden, uitvoer ontvangen'. Ik beschouw het als "werkruimte inrichten, toegang verlenen, terugkerend werk plannen en periodiek inchecken."
Dat klinkt vanzelfsprekend als je het uitschrijft. Dit is niet de manier waarop de meeste mensen AI gebruiken in 2026. De meeste mensen leven nog steeds in de cyclus van prompt-and-response, waarbij ze elke AI-interactie behandelen als een eenmalige transactie. De werkelijke bijdrage van de Codex AI super-app is om van de werkruimte de eenheid van interactie te maken. Projecten hebben een persistente context. Plug-ins vergroten het bereik. Automatiseringen worden volgens schema uitgevoerd. Gevorkte draden maken coherent parallellisme mogelijk. Geen daarvan gaat over een enkele prompt. Ze gaan allemaal over duurzame infrastructuur.
Wat AI-hoofdgebruikers in de tweede helft van 2026 zal scheiden van AI-toeristen, is of ze deze verschuiving maken. De toeristen zullen aanwijzingen blijven typen. De hoofdgebruikers zullen tien automatiseringen gebruiken waar ze nauwelijks aan denken, drie projecten met een diepe context en gevorkte thread-workflows die in één middag samenhangend werk met meerdere uitvoer opleveren.
Ik ga niet voorspellen dat ChatGPT-gebruikers achterop zullen raken. Dat is het soort YouTube-hyperbool dat slecht veroudert. Maar ik zal dit zeggen: als je AI nog steeds gebruikt door in een chatbox te typen en op een reactie te wachten, doe je ongeveer 15% van wat momenteel mogelijk is met hetzelfde abonnement waarvoor je al betaalt. De overige 85% woont in het super-app-oppervlak. En het is niet meer theoretisch. Het is verzonden, het draait en het wordt gebruikt door mensen die stilletjes iedereen zullen overtreffen die niet de moeite heeft genomen om het te leren.
Er is één vraag die de moeite waard is om vanavond bij stil te staan: als je Codex nu zou openen en zou proberen een enkele automatisering op te zetten die elke ochtend zou worden uitgevoerd voordat je wakker wordt, wat zou die dan doen? Als het antwoord 'Ik weet het niet' is, is dat de kloof. Het sluiten is het werk.
Veelgestelde vragen
Wat is de Codex AI super-app?
De Codex AI super-app is de desktopagent van OpenAI die voornamelijk op GPT-5.5 draait en codering, computergebruik, een in-app browser, plug-ins voor tools zoals Slack en Notion, permanent geheugen en geplande achtergrondautomatiseringen combineert. Het heeft zijn super-app-revisie op 16 april 2026 uitgebracht als Codex Desktop v26.415 en is inbegrepen bij betaalde ChatGPT-abonnementen in plaats van afzonderlijk te worden verkocht.
Is Codex hetzelfde als ChatGPT?
Nee. Codex is een afzonderlijke desktopapplicatie die uw ChatGPT-account gebruikt, maar een ander oppervlak blootlegt – bestandstoegang, computercontrole, plug-ins en geplande automatiseringen – gebouwd rond autonome taakuitvoering in plaats van conversatiereacties. ChatGPT blijft de conversatieweb/mobile-interface; Codex is de agentische bureaubladlaag.
Op welk model draait Codex eigenlijk?
Volgens de Codex-modellendocumentatie van OpenAI, routeert Codex tussen GPT-5.5, GPT-5.5 Pro en oudere 5-Codex-varianten, afhankelijk van de taakklasse en het abonnementsniveau. Agentische taken met hoge inspanning worden doorgaans uitgevoerd op GPT-5.5 met extra hoge redenering ingeschakeld, terwijl lichtere taken snellere controlepunten gebruiken om de latentie redelijk te houden.
Kan Codex echt een volledige app bouwen zonder codering?
Gedeeltelijk. Codex kan een werkende MVP plannen, ondersteunen, bouwen en zelf testen vanaf een prompt in natuurlijke taal - zie Test 2 hierboven voor een echte sessie van vier uur die een functionele Next.js 15-app opleverde. Maar het lost niet elke bug op, het resultaat is zelden productieklaar zonder polijsten, en je moet nog steeds stacktraces lezen wanneer edge cases de autonome lus doorbreken.
Wat is het verschil tussen projecten, plug-ins en automatiseringen?
Projecten zijn permanente werkruimten die bestanden, gespreksgeschiedenis en referenties voor een specifiek bereik bevatten. Plug-ins zijn integraties (Slack, Notion, Figma, Gmail en meer dan 90 andere) die het bereik van Codex uitbreiden naar externe tools. Automatiseringen zijn geplande, headless agent-runs die gedefinieerde taken uitvoeren op basis van een trigger. Zij vormen de laag die ervoor zorgt dat Codex aanvoelt als een superapp in plaats van als een chatbot. Voor het volledige overzicht, zie het gedeelte met de drie pijlers hierboven.
Laten we samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (ondernemingsoplossingen): ramlit.com
- ColorPark (ontwerp en branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
