Codex lanseras – OpenAI:s programmeringsagent arbetar i en egen molnsandlåda

Codex lanseras – OpenAI:s programmeringsagent arbetar i en egen molnsandlåda

Den 16 maj 2025 lanserade OpenAI Codex som en forskningsförhandsvisning i ChatGPT. Den molnbaserade programmeringsagenten kunde läsa en kodbas, skriva funktioner, rätta buggar, köra tester och föreslå pull requests – samtidigt som varje uppgift kördes i en separat isolerad miljö.

Marketplace sammanfattar lanseringen i efterhand. Codex hade funnits som namn på äldre kodmodeller, men 2025 års produkt var något annat: en agent som kunde arbeta självständigt med ett helt repository under flera minuter och redovisa ändringarna för mänsklig granskning.

Codex i korthet

| Punkt | Uppgift vid lanseringen |
|---|---|
| Lanseringsdatum | 16 maj 2025 |
| Status | Forskningsförhandsvisning |
| Produkt | Molnbaserad mjukvaruagent i ChatGPT |
| Underliggande modell | codex-1, en o3-version optimerad för mjukvaruutveckling |
| Första planer | Pro, Business och Enterprise; Plus följde senare |
| Körmiljö | Separat molnsandlåda med repository och beroenden |
| Uppgifter | Funktioner, buggrättningar, tester, kodfrågor och pull request-förslag |
| Typisk arbetstid | Från några minuter till längre beroende på uppgift |

Skillnaden mot vanlig kodgenerering

En vanlig AI-chatt kan skriva ett kodblock utifrån en prompt. Utvecklaren behöver sedan kopiera koden, placera den i projektet, köra tester och återkomma med felmeddelanden.

Codex arbetade i stället inne i en kopia av repositoryt. Agenten kunde:

1. läsa projektets struktur
2. förstå instruktioner och lokala regler
3. redigera flera filer
4. köra kommandon
5. använda testsvit, linter och typkontroll
6. analysera resultatet
7. fortsätta tills uppgiften var klar eller behövde hjälp
8. visa ändringarna för granskning

Det gjorde Codex mer likt en asynkron utvecklarkollega än en autocomplete-funktion.

Varje uppgift fick en separat miljö

OpenAI skapade en isolerad molnmiljö för varje Codex-uppgift. Repositoryt laddades in tillsammans med konfigurerade beroenden och instruktioner.

Isoleringen hade flera fördelar:

• agenten kunde inte direkt ändra användarens lokala arbetskopia
• parallella uppgifter störde inte varandra
• kommandon och tester kördes i en kontrollerad miljö
• användaren kunde granska diffen innan något slogs samman
• misslyckade experiment kunde kastas utan att påverka huvudgrenen

En sandlåda är dock inte automatiskt säker. Miljön behövde konfigureras så att hemligheter, produktionskonton och onödiga nätverksvägar inte fanns tillgängliga.

AGENTS.md gav projektet egna instruktioner

Codex kunde läsa filer med projektspecifika instruktioner, bland annat `AGENTS.md`. Där kunde teamet beskriva hur projektet skulle byggas, testas och struktureras.

En användbar instruktionsfil kunde innehålla:

• kodstandard och formattering
• kommandon för testning
• katalogstruktur
• hur databasmigreringar hanteras
• vilka filer som inte får ändras
• säkerhets- och licenskrav
• definitionen av färdig uppgift

Det gjorde agenten mer konsekvent. Men instruktioner behövde hållas aktuella. En gammal testkommandorad kunde få Codex att misslyckas eller tro att en defekt implementation var korrekt.

Codex kunde arbeta parallellt

Flera uppgifter kunde startas samtidigt, var och en i sin egen miljö. Ett team kunde exempelvis låta Codex:

• skriva en ny API-endpoint
• skapa tester för en äldre modul
• undersöka ett fel
• uppdatera dokumentation
• föreslå en refaktorering

Parallelliteten kunde öka kapaciteten, men flyttade flaskhalsen till granskning. Om en utvecklare startade tio agenter behövde någon fortfarande förstå och kontrollera tio uppsättningar ändringar.

Ett team borde därför mäta mängden godkänd kod, inte mängden genererade pull requests.

codex-1 var optimerad för verkliga koduppgifter

OpenAI beskrev codex-1 som en variant av o3 som tränats med förstärkt inlärning på verkliga programmeringsuppgifter i olika miljöer.

Målet var att modellen skulle:

• följa instruktioner noggrant
• skriva kod i en stil som passade repositoryt
• köra och rätta tester iterativt
• producera tydliga sammanfattningar
• lämna verifierbara bevis på vad som genomförts

OpenAI sade att modellen tränats för att spegla mänsklig kodstil och pull request-preferenser. Resultatet behövde ändå granskas mot teamets egna krav.

Bevis genom loggar och testresultat

När en uppgift var klar kunde Codex redovisa terminalutdata, testresultat och referenser till filer. Det gjorde det enklare att kontrollera vad agenten faktiskt hade gjort.

En bra leverans från en kodagent borde visa:

1. vilka filer som ändrades
2. varför förändringen gjordes
3. vilka tester som kördes
4. om några tester hoppades över
5. kvarvarande risker eller antaganden
6. hur ändringen kan återställas

Texten ”klart” är inte tillräcklig när agenten har ändrat en produktionskodbas.

Internetåtkomst var begränsad från början

Vid den första lanseringen var internetåtkomsten begränsad under uppgiftens körning. OpenAI byggde senare ut möjligheten att ge Codex kontrollerad nätverksåtkomst.

Begränsningen skyddade mot flera risker:

• agenten kunde inte okontrollerat ladda ned kod
• hemligheter kunde inte lika lätt skickas ut
• externa instruktioner kunde inte påverka arbetet
• beroenden blev mer reproducerbara

Samtidigt behövde många verkliga projekt dokumentation, paketregister eller externa API:er. Därför krävdes en balans med allowlists, proxykontroller och loggning när nätverket aktiverades.

Kodagenten kunde introducera sårbarheter

Att testerna passerar betyder inte att koden är säker. Codex kunde exempelvis:

• missa en behörighetskontroll
• skapa SQL-injektion
• logga känsliga uppgifter
• använda ett osäkert beroende
• ändra ett test så att felet döljs
• bryta bakåtkompatibilitet
• skapa race conditions
• implementera fel affärsregel

Kod behövde därför passera samma säkerhets- och granskningsprocess som mänskligt skriven kod.

En särskilt viktig regel var att agenten inte skulle få hemliga nycklar i promptar eller konfigurationsfiler. Sandlådan skulle använda tillfälliga och minimalt behöriga credentials när integrationstester krävde åtkomst.

Skillnaden mot GitHub Copilot och en IDE-assistent

| IDE-assistent | Codex vid lanseringen |
|---|---|
| Arbetar nära utvecklaren i editorn | Arbetar i en separat molnmiljö |
| Ger förslag medan användaren skriver | Kan genomföra en längre uppgift självständigt |
| Ser oftast aktuell lokal kontext | Läser en kopia av hela repositoryt |
| Omedelbar återkoppling | Arbetar ofta i flera minuter |
| Utvecklaren styr varje steg | Agenten planerar, ändrar och testar flera steg |

Produkterna kompletterade varandra. IDE-assistenten passade för tät parprogrammering, medan Codex kunde ta en avgränsad uppgift i bakgrunden och lämna ett granskningsbart resultat.

Frågor om kodbasen

Codex hade även ett läge där användaren kunde ställa frågor om repositoryt. Det kunde hjälpa nya utvecklare att hitta:

• var autentisering implementerades
• vilka tester som täckte en funktion
• hur ett dataflöde fungerade
• vilka filer som påverkades av en ändring
• varför ett visst designval hade gjorts

Svar behövde länkas till konkreta filer och rader. En kodagent kan annars formulera en plausibel arkitekturbeskrivning som inte stämmer med implementationen.

Codex CLI utvecklades parallellt

OpenAI uppdaterade även Codex CLI, ett lokalt verktyg där utvecklaren kunde arbeta med kodagenten från terminalen. Molnagenten och CLI:t löste delvis olika behov.

• Molnagenten kunde köra flera isolerade uppgifter parallellt.
• CLI:t arbetade närmare den lokala utvecklingsmiljön och gav mer interaktiv kontroll.

Team behövde välja vilken miljö som passade deras säkerhetsmodell. Lokal åtkomst kan ge bättre kontroll över data men också större möjlighet för agenten att påverka utvecklarens dator.

Så kunde svenska utvecklingsteam införa Codex

Ett säkert pilotprojekt kunde genomföras i följande ordning:

1. välj ett mindre internt repository
2. ta bort produktionsnycklar och personuppgifter
3. skapa en tydlig `AGENTS.md`
4. börja med tester och dokumentation
5. mät andel accepterade ändringar
6. lägg till statisk analys och säkerhetsskanning
7. kräva mänsklig pull request-granskning
8. skala först efter verifierad kvalitet

Det var olämpligt att börja med betalningar, identitet eller säkerhetskritiska system där en subtil defekt kunde få stora konsekvenser.

Produktivitet utan kvalitetsillusion

En kodagent kan skapa mycket kod snabbt. Det kan ge en känsla av hög produktivitet även om teamet får mer underhåll och fler fel senare.

Viktiga mätpunkter var:

• accepterade pull requests
• antal ändringar efter granskning
• nya buggar efter release
• tid till testad funktion
• säkerhetsfynd
• hur väl koden följer arkitekturen
• utvecklarnas förståelse av den genererade koden

Det bästa utfallet var inte att ersätta kodgranskning, utan att flytta människans tid från rutinmässigt skrivande till design, kontroll och svårare beslut.

Från Codex till bredare agentiskt arbete

Codex visade hur en specialiserad agent kunde arbeta med ett tydligt verktygsområde och en kontrollerad miljö. Två månader senare lanserade OpenAI ChatGPT Agent, som kombinerade webbläsare, terminal, sökning och anslutna appar i mer allmänna arbetsflöden.

Läs även vår artikel om o3 och o4-mini, modellerna som kunde välja och använda verktyg.

Vanliga frågor

När lanserades Codex som molnagent?

OpenAI lanserade forskningsförhandsvisningen den 16 maj 2025.

Vilken modell drev Codex?

Den första produkten drevs av codex-1, en version av OpenAI o3 som optimerats för mjukvaruutveckling.

Kunde Codex ändra produktionskoden direkt?

Agenten arbetade i en separat kopia och presenterade ändringar för granskning. Teamet behövde själv godkänna och slå samman dem.

Kunde flera uppgifter köras samtidigt?

Ja. Varje uppgift fick en separat molnsandlåda och kunde köras parallellt.

Körde Codex tester?

Ja. Agenten kunde köra testsviter, linters och typkontroller som fanns konfigurerade i miljön.

Behövdes mänsklig kodgranskning?

Ja. Tester och agentens sammanfattning ersatte inte granskning av säkerhet, arkitektur och affärslogik.

Sammanfattning

Codex lanserades den 16 maj 2025 som en molnbaserad programmeringsagent. Den kunde läsa en hel kodbas, redigera flera filer, köra tester och lämna ett granskningsbart förslag i en isolerad miljö.

Lanseringen gjorde parallellt agentarbete praktiskt för utvecklingsteam, men skapade även en ny granskningsutmaning. Säker sandlåda, tydliga projektinstruktioner, automatiska tester och mänsklig pull request-granskning var avgörande för att snabbare kodproduktion skulle ge verklig produktivitet.

Faktaunderlag: OpenAI, ”Introducing Codex”, publicerad 16 maj 2025. Artikeln är en historisk sammanfattning publicerad i efterhand.