Dra nytte av Codex i en agentfokusert verden

I løpet av de siste fem månedene har teamet vårt gjennomført et eksperiment: å bygge og levere en intern betaversjon av et programvareprodukt med 0 linjer med manuelt skrevet kode.

Produktet har interne daglige brukere og eksterne alfatestere. Det sendes, distribueres, går i stykker og blir fikset. Det som er annerledes, er at hver kodelinje – applikasjonslogikk, tester, CI-konfigurasjon, dokumentasjon, observerbarhet og interne verktøy – er skrevet av Codex. Vi anslår at vi utviklet dette på omtrent en tidel av tiden det ville ha tatt å skrive koden for hånd.

Mennesker styrer. Agenter utfører.

Vi valgte bevisst denne begrensningen slik at vi kunne bygge det som var nødvendig for å øke utviklingshastigheten med flere størrelsesordener. Vi hadde flere uker på oss til å sende det som til slutt ble en million linjer med kode. For å gjøre det, måtte vi forstå hva som endrer seg når en ingeniørgruppes primære jobb ikke lenger er å skrive kode, men å utvikle miljøer, spesifisere hensikt og bygge tilbakemeldingssløyfer som lar Codex-agenter utføre pålitelig arbeid.

Dette innlegget handler om hva vi lærte ved å bygge et helt nytt produkt med et team av agenter – hva som gikk i stykker, hva som ble forsterket, og hvordan vi kan maksimere vår eneste virkelig knappe ressurs: menneskers tid og oppmerksomhet.

Den første bunten til et tomt lagerble gjort i slutten av august 2025.

Den innledende strukturen – lagerstrukturen, CI-konfigurasjonen, formateringsregler, oppsett av pakkebehandler og applikasjonsrammeverket – ble generert av Codex CLI ved hjelp av GPT‑5, veiledet av et lite sett med eksisterende maler. Selv den første AGENTS.md-filen som instruerer agenter i hvordan de skal arbeide i lageret, ble skrevet av Codex.

Det var ingen eksisterende menneskeskrevet kode for å forankre systemet. Lageret ble formet av agenten fra starten av.

Fem måneder senere inneholder lageret omtrent én million kodelinjer fordelt på applikasjonslogikk, infrastruktur, verktøy, dokumentasjon og interne utviklerverktøy. I løpet av denne perioden har omtrent 1500 pull requests blitt åpnet og slått sammen, med et lite team på bare tre ingeniører som driver Codex. Dette tilsvarer en gjennomsnittlig gjennomstrømming på 3,5 PRs per ingeniør per dag, og overraskende nok har gjennomstrømmingen økt etter hvert som teamet har vokst til nå syv ingeniører. Det er viktig å merke seg at dette ikke var utdata for utdataens skyld: Produktet har blitt brukt av hundrevis av brukere internt, inkludert daglige interne superbrukere.

Gjennom hele utviklingsprosessen bidro mennesker aldri direkte med kode. Dette ble en kjernefilosofi for teamet: Ingen manuelt skrevet kode.

Mangelen på praktisk koding av mennesker introduserte en annen type ingeniørarbeid, med fokus på systemer, rammeverk og utnyttelse.

Den første fremgangen var saktere enn vi forventet. Ikke fordi Codex ikke kunne utføre jobben, men fordi miljøet var underspesifisert. Agenten manglet verktøyene, abstraksjonene og den indre strukturen som var nødvendig for å drive fremgang mot mål på høyt nivå. Den primære oppgaven til ingeniørteamet vårt ble å legge til rette for at agentene kunne utføre nyttig arbeid.

I praksis innebar dette å jobbe i dybden: å bryte ned større mål i mindre byggeklosser (design, kode, gjennomgang, testing osv.), be agenten om å sette sammen disse klossene, og bruke dem til å låse opp mer komplekse oppgaver. Når noe mislyktes, var løsningen nesten aldri «prøv hardere.» Fordi den eneste måten å gjøre fremskritt på var å få Codex til å gjøre arbeidet, gikk menneskelige ingeniører alltid inn i oppgaven og spurte: «hvilken kapasitet mangler, og hvordan gjør vi den både forståelig og håndhevbar for agenten?»

Mennesker samhandler med systemet nesten utelukkende gjennom prompter: En ingeniør beskriver en oppgave, kjører agenten og lar den åpne en pull request. For å fullføre en PR, ber vi Codex om å gjennomgå sine egne endringer lokalt, be om ytterligere spesifikke agentvurderinger både lokalt og i skyen, svare på tilbakemeldinger fra mennesker eller agenter, og iterere i en løkke frem til alle agentvurderere er fornøyde (dette er i praksis en Ralph Wiggum-løkke⁠(åpnes i et nytt vindu)). Codex bruker våre standard utviklingsverktøy direkte (gh, lokale skript og ferdigheter innebygd i lageret) for å samle kontekst uten at mennesker kopierer og limer inn i CLI.

Mennesker kan gjennomgå pull requests, men det er ikke nødvendig. Over tid har vi flyttet nesten all gjennomgang til å bli håndtert mellom agenter.

Etter hvert som kodegjennomstrømmingen økte, ble flaskehalsen vår kapasiteten til menneskelig kvalitetssikring. Fordi den faste begrensningen har vært menneskers tid og oppmerksomhet, har vi jobbet med å legge til flere funksjoner til agenten ved å gjøre ting som programmets brukergrensesnitt, logger og appmålinger i seg selv direkte lesbare for Codex.

For eksempel gjorde vi at appen kunne startes via git worktree, slik at Codex kunne starte og kjøre én instans per endring. Vi koblet også Chrome DevTools Protocol til agentens kjøretid og utviklet ferdigheter for å arbeide med DOM-øyeblikksbilder, skjermbilder og navigasjon. Dette gjorde det mulig for Codex å reprodusere feil, validere rettinger og direkte resonnere om atferden til brukergrensesnittet.

Vi gjorde det samme for observabilitetsverktøy. Logger, måledata og spor eksponeres for Codex via en lokal observerbarhetsstakk som er kortvarig for enhver gitt worktree. Codex arbeider på en helt isolert versjon av denne appen – inkludert dens logger og måledata, som blir fjernet når oppgaven er fullført. Agenter kan forespørre logger med LogQL og målinger med PromQL. Med denne konteksten tilgjengelig blir prompter som «ensure service startup completes in under 800ms» eller «no span in these four critical user journeys exceeds two seconds» håndterbare.

Vi ser ofte at enkeltstående Codex-kjøringer arbeider med én oppgave i over seks timer (ofte mens mennesker sover).

Konteksthåndtering er en av de største utfordringene for å gjøre agenter effektive i store og omfattende oppgaver. En av de tidligste lærdommene vi lærte var enkel: Gi Codex et kart, ikke en 1000-siders bruksanvisning.

Vi prøvde den «ene store AGENTS.md⁠(åpnes i et nytt vindu)» -tilnærmingen. Den sviktet på forutsigbare måter:

• Kontekst er en knapp ressurs. En gigantisk instruksjonsfil fortrenger oppgaven, koden og den relevante dokumentasjonen. Det betyr at agenten enten går glipp av viktige begrensninger eller begynner å optimalisere for feil oppgaver.
• For mye veiledning blir feilaktig veiledning. Når alt er «viktig», er ingenting det. Agenter ender opp med å mønstergjenkjenne lokalt i stedet for å navigere med hensikt.
• Det faller sammen med en gang. En monolittisk veiledning blir til en kirkegård av utdaterte regler. Agenter kan ikke si hva som fortsatt er sant, mennesker slutter å vedlikeholde, og filen blir i det stille til en ulempe.
• Det er vanskelig å bekrefte. En enkelt blob egner seg ikke for mekaniske kontroller (dekning, aktualitet, eierskap, tverrkoblinger), så avvik er uunngåelig.

Så i stedet for å behandle AGENTS.md som et leksikon, behandler vi det som en innholdsfortegnelse.

Lagerets kunnskapsbase ligger i en strukturert docs/-katalog som behandles som systemets hovedkilde. En kort AGENTS.md (omtrent 100 linjer) settes inn i konteksten og fungerer primært som et kart, med henvisninger til dypere sannhetskilder andre steder.

Designdokumentasjon katalogiseres og indekseres, inkludert verifiseringsstatus og et sett med kjerneoverbevisninger som definerer driftsprinsippet med agent først. Arkitekturdokumentasjon⁠(åpnes i et nytt vindu) gir en oversikt over domener og lagdeling av pakker. Et kvalitetsdokument vurderer hvert produktdomene og arkitekturlag, og sporer hull over tid.

Planer behandles som førsteklasses artefakter. Midlertidige lettvektsplaner brukes for små endringer, mens komplekst arbeid fanges opp i utførelsesplaner⁠(åpnes i et nytt vindu) med fremdrifts- og beslutningslogger som sjekkes inn i lageret. Aktive planer, fullførte planer og kjent teknisk gjeld er alle versjonert og samlet, slik at agenter kan operere uten å være avhengige av ekstern kontekst.

Dette muliggjør gradvis avdekking: Agenter starter med et lite, stabilt utgangspunkt og instrueres i hvor de skal se videre, i stedet for å bli overveldet med én gang.

Vi håndhever dette mekanisk. Egne filtre og CI-jobber validerer at kunnskapsbasen er oppdatert, tverrkoblet og strukturert riktig. En tilbakevendende «doc-gardening»-agent skanner etter utdatert eller foreldet dokumentasjon som ikke gjenspeiler den faktiske kodeatferden, og åpner pull requests for retting.

Etter hvert som kodebasen utviklet seg, måtte også Codex’ rammeverk for designbeslutninger utvikle seg.

Fordi lageret er fullstendig agentgenerert, er det først og fremst optimalisert for Codex' lesbarhet. På samme måte som team har som mål å forbedre navigerbarheten i koden sin for nyansatte ingeniører, var målet til våre menneskelige ingeniører å gjøre det mulig for en agent å resonnere om hele forretningsdomenet direkte fra lageret.

Fra agentens synspunkt eksisterer alt den ikke kan få tilgang til i kontekst mens den kjører, i praksis ikke. Systemet har ikke tilgang til kunnskap som finnes i Google Docs, chattråder eller i folks hoder. Lagerlokale, versjonerte artefakter (f.eks., kode, markdown, skjemaer, kjørbare planer) er alt den kan se.

Vi lærte at vi måtte legge til mer og mer kontekst i lageret over tid. Slack-diskusjonen som fikk teamet til å enes om et arkitekturmønster? Hvis agenten ikke kan oppdage det, er det uleselig på samme måte som det ville vært ukjent for en nyansatt som begynner tre måneder senere.

Å gi Codex mer kontekst innebærer å organisere og synliggjøre riktig informasjon slik at agenten kan resonnere over den, i stedet for å overvelde den med ad hoc-instruksjoner. På samme måte som du ville gitt en ny medarbeider en innføring i produktprinsipper, ingeniørnormer og teamkultur (inkludert emoji-preferanser), fører det å gi agenten denne informasjonen til bedre tilpasset output.

Denne innrammingen klargjorde mange avveininger. Vi foretrakk avhengigheter og abstraksjoner som kunne internaliseres fullt ut og resonneres om i lageret. Teknologier som ofte beskrives som «kjedelige», har en tendens til å være enklere for agenter å modellere på grunn av komponerbarhet, API-stabilitet og representasjon i treningssettet. I visse tilfeller var det billigere å la agenten reimplementere delsett av funksjonalitet enn å omgå uklar oppstrøms oppførsel fra offentlige biblioteker. I stedet for å hente inn en generisk p-limit-aktig pakke, implementerte vi for eksempel vår egen hjelper for samtidig tilordning: Den er tett integrert med OpenTelemetry-instrumentene våre, har 100 % testdekning og oppfører seg nøyaktig slik kjøretiden vår forventer.

Å trekke mer av systemet inn i en form som agenten kan inspisere, validere og endre direkte, øker utnyttelsen – ikke bare for Codex, men også for andre agenter (f.eks. Aardvark) som også jobber med kodebasen.

Dokumentasjon alene kan ikke alene sørge for at en agentgenerert kodebase henger sammen. Ved å bruke invarianter i stedet for detaljstyre implementasjoner, lar vi agenter levere raskt uten å undergrave fundamentet. Vi krever for eksempel at Codex parser datastrukturer ved grensen⁠(åpnes i et nytt vindu), men vi er ikke preskriptive om hvordan det skjer (modellen ser ut til å like Zod, men vi spesifiserte ikke dette spesifikke biblioteket).

Agenter er mest effektive i miljøer med strenge grenser og forutsigbar struktur⁠(åpnes i et nytt vindu), så vi bygde programmet rundt en rigid arkitekturmodell. Hvert forretningsdomene er delt inn i et fast sett med lag, med strengt validerte avhengighetsretninger og et begrenset sett med tillatte kanter. Disse begrensningene sikres mekanisk via tilpassede (Codex-genererte) filtre og strukturelle tester.

Diagrammet nedenfor viser regelen: innenfor hvert forretningsdomene (f.eks. Appinnstillinger), kode kan bare avhenge «fremover» gjennom et fast sett med lag (Types → Config → Repo → Service → Runtime → UI). Tverrgående hensyn (autentisering, koblinger, telemetri, funksjonsflagg) kommer inn gjennom ett enkelt grensesnitt: Leverandører. Alt annet er ikke tillatt og håndheves automatisk.

Dette er typen arkitektur du vanligvis utsetter til du har hundrevis av ingeniører. Med kodeagenter er det en tidlig forutsetning: Begrensningene er det som muliggjør hastighet uten svekkelse eller arkitektonisk forskyvning.

I praksis håndhever vi disse reglene med tilpassede filtre og strukturelle tester, pluss et lite sett med «smaksinvarianter». For eksempel håndhever vi statisk strukturert logging, navnekonvensjoner for skjemaer og typer, filstørrelsesgrenser og plattformspesifikke pålitelighetskrav med tilpassede filterregler. Fordi filtrene er egendefinerte, skriver vi feilmeldingene for å legge inn utbedringsinstruksjoner i agentkonteksten.

Disse reglene kan føles pedantiske eller begrensende i en menneskefokusert arbeidsflyt. Med agenter blir de multiplikatorer: når de først er kodet, gjelder de overalt samtidig.

Samtidig er vi tydelige på hvor begrensninger er viktige, og hvor de ikke er det. Dette minner om å lede en stor ingeniørplattformorganisasjon: håndhev grenser sentralt, tillat autonomi lokalt. Du bryr deg om grenser, korrekthet og reproduserbarhet. Innenfor disse grensene gir du team – eller agenter – betydelig frihet i hvordan løsninger uttrykkes.

Den resulterende koden samsvarer ikke alltid med menneskers stilistiske preferanser, og det er helt greit. Så lenge resultatet er riktig, kan vedlikeholdes og er leselig for fremtidige agentkjøringer, oppfyller det kravene.

Menneskers preferanser mates kontinuerlig tilbake til systemet. Kommentarer om gjennomgang, refaktorering av pull requests og brukerrettede feil fanges opp som dokumentasjonsoppdateringer eller kodes direkte inn i verktøyene. Når dokumentasjonen ikke er tilstrekkelig, fremmer vi regelen til kode

Etter hvert som Codex' gjennomstrømming økte, ble mange konvensjonelle ingeniørnormer kontraproduktive.

Lageret opererer med minimale blokkerende sammenslåingsporter. Pull requests er kortvarige. Testflak håndteres ofte med oppfølgingskjøringer i stedet for å blokkere fremdriften på ubestemt tid. I et system der agentgjennomstrømming langt overgår menneskelig oppmerksomhet, er korreksjoner rimelige mens venting er dyrt.

Dette ville være uansvarlig i et miljø med lav gjennomstrømming. Her er det ofte den rette avveiningen.

Når vi sier at kodebasen er generert av Codex-agenter, mener vi alt i kodebasen.

Agentene produserer:

• Produktkode og tester
• CI-konfigurasjon og utgivelsesverktøy
• Interne utviklerverktøy
• Dokumentasjon og designhistorie
• Evalueringsrammeverk
• Kommentarer og svar på gjennomgang
• Skript som administrerer selve lageret
• Definisjonsfiler til produksjonsdashbord

Mennesker forblir alltid en del av arbeidet, men jobber på et annet abstraksjonsnivå enn vi gjorde før. Vi prioriterer arbeid, oversetter brukertilbakemeldinger til akseptansekriterier og validerer resultater. Når agenten sliter, ser vi det som et signal: Vi identifiserer hva som mangler – verktøy, retningslinjer, dokumentasjon – og legger det tilbake i lager, alltid ved å la Codex selv skrive rettelsen.

Agenter bruker våre standard utviklingsverktøy direkte. De henter tilbakemeldinger fra gjennomgang, svarer i linjen, pusher oppdateringer og slår ofte sammen sine egne pull requests.

Etter hvert som mer av utviklingssløyfen ble kodet direkte inn i systemet via testing, validering, gjennomgang, håndtering av tilbakemeldinger og gjenoppretting, krysset lageret nylig en meningsfull terskel der Codex kan drive en ny funksjon fra start til slutt.

Når agenten får en enkelt prompt, kan den nå:

• Validere den nåværende tilstanden til kodebasen
• Gjenskape en rapportert feil
• Ta opp en video som viser feilen
• Utføre en rettelse
• Validere rettelsen ved å kjøre programmet
• Ta opp en annen video som demonstrerer oppløsningen
• Åpne en pull request
• Svar på tilbakemeldinger fra agenter og mennesker
• Oppdage og utbedre byggefeil
• Eskalere til et menneske bare når det kreves dømmekraft
• Slå sammen endringen

Denne oppførselen avhenger i stor grad av den spesifikke strukturen og verktøyene i dette lageret og bør ikke antas å kunne generaliseres uten tilsvarende investering, i hvert fall ikke ennå.

Full agentautonomi introduserer også nye problemer. Codex replikerer mønstre som allerede finnes i lageret – selv ujevne eller suboptimale mønstre. Over tid fører dette uunngåelig til drift.

Først håndterte mennesker dette manuelt. Teamet vårt pleide å bruke hver fredag (20 % av uken) på å rydde opp i «KI-rot.» Dette kunne ikke skaleres.

I stedet begynte vi å kode det vi kaller «gullprinsipper» direkte i lageret og bygde en gjentakende oppryddingsprosess. Disse prinsippene er meningsbærende, mekaniske regler som holder kodebasen lesbar og konsistent for fremtidige agentkjøringer. For eksempel: (1) Vi foretrekker delte verktøypakker fremfor egenlagde hjelpere for å holde invarianter sentralisert, og (2) vi undersøker ikke data vilkårlig – vi validerer grenser eller stoler på typede SDK-er slik at agenten ikke ved et uhell kan bygge på antatte strukturer. Vi har et sett med bakgrunnsoppgaver i Codex som jevnlig skanner etter avvik, oppdaterer kvalitetsgrader og åpner målrettede pull requests for refaktorering. De fleste av disse kan gjennomgås på under ett minutt og automatisk slås sammen.

Dette fungerer som opprydding. Teknisk gjeld er som et lån med høy rente: Det er nesten alltid bedre å betale det ned kontinuerlig i små trinn enn å la det hope seg opp og måtte håndtere det i smertefulle rykk. Menneskelig smak fanges én gang, og håndheves deretter kontinuerlig på hver kodelinje. Dette lar oss også fange opp og løse dårlige mønstre daglig, i stedet for å la dem spre seg i kodebasen i flere dager eller uker.

Denne strategien har så langt fungert godt frem til intern lansering og adopsjon hos OpenAI. Ved å utvikle et ekte produkt for faktiske brukere, kunne vi forankre investeringene våre i virkeligheten og bevege oss mot langsiktig vedlikehold.

Det vi ennå ikke vet, er hvordan arkitektonisk sammenheng utvikler seg over flere år i et fullt agentgenerert system. Vi lærer fortsatt hvor menneskelig vurdering er viktigst, og hvordan vi kan kode inn denne vurderingen slik at den akkumuleres. Vi vet heller ikke hvordan dette systemet vil utvikle seg etter hvert som modellene fortsetter å bli mer dyktige over tid.

Ett er sikkert: Å utvikle programvare krever fortsatt disiplin, men disiplinen viser seg mer i strukturen enn i selve koden. Verktøyene, abstraksjonene og tilbakemeldingssløyfene som holder kodebasen samlet, blir stadig viktigere.

Våre mest krevende utfordringer går nå ut på å utvikle miljøer, tilbakemeldingssløyfer og kontrollsystemer som hjelper agenter med å oppnå målet vårt: å bygge og vedlikeholde kompleks, pålitelig programvare i stor skala.

Etter hvert som agenter som Codex tar på seg større deler av programvarelivsløpet, vil disse spørsmålene bli enda viktigere. Vi håper at vi kan dele tidlige lærdommer som hjelper deg med å vurdere hvor du bør legge inn innsatsen, slik at du enkelt kan bygge.