Codex bliver et workspace, ikke bare en coding agent
· 3 min read · Filippo Spinella · AI, Codex, Developer Tools, Productivity
Det, der blev hængende hos mig i den nye Codex-annoncering, var ikke ordet plugin. Det var idéen om, at Codex prøver at blive et sted, hvor arbejde lander.
OpenAI udgav Codex for every role, tool, and workflow den 2. juni 2026. De synlige nyheder er rolleplugins, Sites og annotationer. Men det nyttige spørgsmål er enklere: kan en agent tage spredt virksomhedskontekst og gøre den til noget, et team kan åbne, diskutere og forbedre?
Det egentlige skift
Længe var Codex nem at forklare: den hjalp udviklere med at ændre kode. Denne opdatering gør den forklaring for smal. De nye plugins taler også til analytics, sales, product design, creative production, public equity investing og investment banking.
Det betyder, at Codex ikke kun læser et repository. Den kan læse dashboards, CRM-noter, dokumenter, spreadsheets, design briefs eller finansielle kilder og bygge et arbejdsartefakt.
Det er der, det bliver praktisk. De fleste teams har ikke brug for endnu et chatsvar. De har brug for en side, et launch room, et review board, en planner, en lille intern app eller et dashboard, som alle kan åbne.
Sites er delen, jeg ville holde øje med
Sites virker mest konkret. Et chatsvar forsvinder i scroll. Et site har en URL. Det kan deles, kommenteres, åbnes igen senere, og Codex kan opdatere kun det, der har ændret sig.
Jeg kan se det bruges til produktlanceringer, customer reviews, ugentlige business reviews, investor memos og intern tooling. Ikke fordi første version bliver perfekt. Det gør den ikke. Værdien er, at teamet får et fælles objekt.
Annotationer gør feedback mindre uklart
Annotationer betyder også noget. Hvis jeg siger gør det klarere, kan agenten ændre for meget. Hvis jeg peger på en graf, et afsnit eller en sektion, bliver opgaven mindre.
Sådan fungerer rigtig redigering. Man vil sjældent omskrive alt. Man vil have denne sætning skarpere, den graf mindre forvirrende, den slide roligere, den tabel bedre sorteret.
Sådan ville jeg teste det
Jeg ville ikke forbinde alle værktøjer på dag ét. Jeg ville vælge et kedeligt workflow med klare owners. En ugentlig business review passer: få metrics, nogle noter, ét delt output og menneskelig review før noget sendes.
Kort checklist:
- beslut hvilke kilder Codex må læse;
- beslut hvad den må skrive;
- kræv links til vigtige kilder;
- sæt en owner på hvert artefakt;
- arkivér eller slet det, der ikke længere er nyttigt.
Risikoen er ikke et dårligt første draft. Teams overlever dårlige drafts. Risikoen er sprawl: ti genererede sites, ingen owner, intet source trail og ingen ved, hvilken version der er rigtig.
Min læsning
Annonceringen viser, at agents bevæger sig ud af demo-fasen. De nyttige bliver ikke de mest støjende. De bliver dem, der passer ind i teamets rytme: samler kontekst, laver draft, bevarer spor, tager præcis feedback og holder grænser.
For udviklere gør det ikke engineering mindre vigtigt. Det gør det vigtigere. Nogen skal stadig designe permissions, defaults, reviewpunkter og hvad done betyder.