Dra nytta av ingenjörskonst: användning av Codex i en agent-värld

Under de senaste fem månaderna har vårt team genomfört ett experiment: att skapa och leverera en intern betaversion av en mjukvaruprodukt med 0 rader manuellt skriven kod.

Produkten har interna dagliga användare och externa alfa-testare. Den levereras, driftsätts, går sönder och åtgärdas. Det som är annorlunda är att applikationslogiken, tester, CI-konfiguration, dokumentation, observerbarhet och interna verktyg har skrivits av Codex. Vi uppskattar att vi skapade detta på ungefär en tiondel av den tid det skulle ha tagit att skriva koden för hand.

Människor navigerar. Agenter exekverar.

Vi valde medvetet denna begränsning för att skapa det som var nödvändigt för att öka avsevärt ingenjörshastigheten. Vi hade veckor på oss att skicka vad som till slut blev en miljon rader kod. För att göra det behövde vi förstå vad som förändras när ett mjukvaruutvecklingsteams primära uppgift inte längre är att skriva kod utan att designa miljöer, specificera avsikt och skapa återkopplingsslingor som gör det möjligt för Codex-agenter att utföra tillförlitligt arbete.

Det här inlägget handlar om vad vi lärde oss när vi skapade en helt ny produkt med ett team av agenter—vad som gick sönder, vad som förvärrades och hur vi kan maximera vår enda verkligt knappa resurs: mänsklig tid och uppmärksamhet.

Den första commiten till ett tomt git-arkiv landade i slutet av augusti 2025.

Den initiala stommen såsom arkivstruktur, CI-konfiguration, formateringsregler, pakethanterarinstallation och applikationsramverk genererades av Codex CLI med hjälp av GPT‑5 och en liten uppsättning befintliga mallar. Även den ursprungliga AGENTS.md-filen som instruerar agenter hur de ska arbeta i arkivet skrevs av Codex.

Det fanns ingen existerande kod skriven av människor för att förankra systemet. Redan från början formades arkivet av agenten.

Fem månader senare innehåller arkivet ungefär en miljon rader kod med applikationslogik, infrastruktur, verktyg, dokumentation och interna utvecklarverktyg. Under den perioden har ungefär 1 500 pull requests öppnats och sammanfogats av ett litet team bestående av endast tre ingenjörer som driver Codex. Detta motsvarar en genomsnittlig kapacitet på 3,5 PRs per ingenjör per dag och överraskande nog har kapaciteten ökat i takt med att teamet vuxit till sju ingenjörer. Detta var dock inte resultat för resultatets skull: produkten har använts av hundratals användare internt, inklusive dagliga interna avancerade användare.

Under utvecklingsprocessen bidrog inte människor med någon kod direkt. Detta blev en kärnfilosofi för teamet: ingen manuellt skriven kod.

Bristen på praktisk mänsklig kodning introducerade ett ingenjörsarbete som fokuserar på system, stödstrukturer och effektivitet.

De tidiga framstegen var långsammare än vi förväntade oss, inte för att det var fel på Codex utan för att miljön inte var tillräckligt specificerad. Agenten saknade de verktyg, abstraktioner och den interna struktur som behövdes för att göra framsteg mot högnivåmål. Vårt teknikteams främsta uppgift blev att göra det möjligt för agenterna att utföra användbart arbete.

I praktiken innebar detta att arbeta på djupet först: att bryta ner större mål i mindre byggstenar (design, kod, granskning, test, etc.), uppmana agenten att konstruera dessa byggstenar och använda dem för att lösa mer komplexa uppgifter. När något gick fel var lösningen nästan aldrig att "anstränga sig mer". Eftersom det enda sättet att göra framsteg var att få Codex att utföra arbetet tog mänskliga ingenjörer alltid itu med uppgiften och frågade: "vilken förmåga saknas och hur gör vi den begriplig och verkställbar för agenten?"

Människor interagerar med systemet nästan helt och hållet genom promptar: en ingenjör beskriver en uppgift, startar agenten och låter den öppna en pull request. För att slutföra en PR instruerar vi Codex att granska sina egna ändringar lokalt, begära ytterligare specifika agentgranskningar både lokalt och i molnet, svara på all feedback från människor eller agenter och iterera i en loop tills alla agentgranskare är nöjda (detta är i praktiken en Ralph Wiggum-loop⁠(öppnas i ett nytt fönster)). Codex använder våra standardutvecklingsverktyg direkt (gh, lokala skript och arkivinbäddade färdigheter) för att samla in kontext utan att människor kopierar och klistrar in i CLI.

Människor kan granska pull requests men det är inte nödvändigt. Med tiden har vi överfört nästan allt granskningsarbete till att hanteras av agenter.

När kodgenomströmningen ökade blev vår flaskhals den mänskliga QA-kapaciteten. Eftersom den fasta begränsningen har varit mänsklig tid och uppmärksamhet har vi arbetat på att lägga till fler funktioner i agenten genom att göra applikationens användargränssnitt, loggar och appmätvärden direkt läsbara för Codex.

Vi gjorde till exempel appen startbar per git worktree så att Codex kunde starta och hantera en instans per ändring. Vi integrerade även Chrome DevTools Protocol i agentens körningsmiljö och utvecklade funktioner för hantering av DOM-ögonblicksbilder, skärmbilder och navigering. Detta gjorde det möjligt för Codex att återskapa buggar, validera korrigeringar och analysera användargränssnittets beteende direkt.

Vi gjorde samma sak för observerbarhetsverktyg. Loggar, mätvärden och spår exponeras för Codex via en lokal observerbarhetsstack som är temporär för varje specifikt arbetsträd. Codex arbetar med en helt isolerad version av den appen (inklusive dess loggar och mätvärden) som tas bort när uppgiften är slutförd. Agenter kan skicka förfrågningar om loggar med LogQL och mätvärden med PromQL. Detta sammanhang gör att promptar som "säkerställ att tjänstens uppstart slutförs på under 800 ms" och "ingen span i dessa fyra kritiska användarresor ska överstiga två sekunder" blir hanterbara.

Vi ser regelbundet att enskilda Codex-körningar arbetar på en enda uppgift i över sex timmar (ofta medan människor sover).

Kontexthantering är en av de största utmaningarna med att göra agenter effektiva vid stora och komplexa uppgifter. En av de första lärdomarna vi fick var enkel: ge Codex en karta, inte en instruktionsmanual på 1 000 sidor.

Vi provade tillvägagångssättet "en stor AGENTS.md⁠(öppnas i ett nytt fönster)" . Det misslyckades på förutsägbara sätt:

• Kontext är en begränsad resurs. En stor instruktionsfil tränger undan uppgiften, koden och den relevanta dokumentationen vilket får agenten att missa antingen viktiga begränsningar eller börja optimera för felaktiga.
• För mycket vägledning blir till ingen vägledning. När allt är "viktigt" är inget viktigt. Agenter tenderar att mönstermatcha lokalt istället för att navigera med avsikt.
• Det ruttnar omedelbart. En monolitisk manual förvandlas till en kyrkogård av föråldrade regler. Agenter kan inte avgöra vad som fortfarande är sant, människor slutar underhålla det, och filen blir i tysthet en lockande olägenhet.
• Det är svårt att verifiera. En enda blob är inte lämplig för mekaniska kontroller (täckning, aktualitet, ägarskap, korslänkar) och gör avvikelse oundvikligt.

Istället för att betrakta AGENTS.md som ett uppslagsverk betraktar vi det som en innehållsförteckning.

Arkivets kunskapsbas finns i en strukturerad docs/-katalog som betraktas som det officiella systemet för dokumentation. En kort AGENTS.md (ungefär 100 rader) infogas i sammanhanget och används främst som en karta med hänvisningar till djupare källor av sanning på andra ställen.

Designdokumentation katalogiseras och indexeras, inklusive verifieringsstatus och en uppsättning grundläggande principer som definierar agent-först-driftsprinciper. Arkitekturdokumentation⁠(öppnas i ett nytt fönster) ger en översiktlig karta över domäner och paketindelning. Ett kvalitetsdokument betygsätter varje produktdomän och arkitekturlager samt följer upp brister över tid.

Planer betraktas som förstklassiga artefakter. Tillfälliga lättviktiga planer används för små ändringar medan komplicerat arbete fångas upp i genomförandeplaner⁠(öppnas i ett nytt fönster) med framstegs- och beslutsloggar som förvaras i arkivet. Aktiva planer, slutförda planer och känd teknisk skuld är alla versionshanterade och samlokaliserade vilket gör att agenter kan arbeta utan att förlita sig på extern kontext.

Detta möjliggör progressiv avslöjande: agenter börjar med en liten, stabil ingångspunkt och lär sig vart de ska titta härnäst istället för att bli överväldigade direkt.

Vi genomför detta automatiskt. Dedikerade linters och CI-jobb validerar att kunskapsbasen är uppdaterad, tvärlänkad och korrekt strukturerad. En återkommande "doc-gardening"-agent skannar efter inaktuell eller föråldrad dokumentation som inte återspeglar det verkliga kodbeteendet och öppnar korrigerande pull requests.

I takt med att kodbasen utvecklades behövde det ramverk som Codex använder för designbeslut även utvecklas.

Eftersom arkivet är helt agentgenererat är det i första hand optimerat för att vara läsbart för Codex. På samma sätt som team strävar efter att förbättra navigerbarheten i sin kod för nya ingenjörsanställningar var målet för våra mänskliga ingenjörer att göra det möjligt för en agent att resonera om hela företagsdomänen direkt från arkivet.

Ur agentens perspektiv existerar ingenting som den inte kan komma åt via kontexten när den körs effektivt. Kunskap som finns i Google Docs, chatter eller i människors huvuden är inte tillgänglig för systemet. Arkivlokala, versionshanterade artefakter (t.ex. kod, markdown, scheman, körbara planer) är allt den kan se.

Vi insåg att vi behövde lägga in allt mer kontext i kodförrådet över tid. Den där Slack-diskussionen som enade teamet runt ett arkitekturmönster? Om den inte är upptäckbar för agenten är den lika obegriplig som för en nyanställd som börjar tre månader senare.

Att ge Codex mer kontext innebär att organisera och exponera rätt information så att agenten kan resonera utifrån den istället för att överväldiga den med ad hoc-instruktioner. På samma sätt som du skulle introducera en ny teammedlem för produktprinciper, ingenjörsnormer och teamkultur (inklusive emoji-preferenser) leder det till mer anpassade resultat när agenten får denna information.

Denna inramning klargjorde många kompromisser. Vi föredrog beroenden och abstraktioner som kunde internaliseras helt och förstås i repon. Teknologier som ofta beskrivs som "tråkiga" tenderar att vara enklare för agenter att modellera på grund av kompositerbarhet, API-stabilitet och representation i träningsuppsättningen. I vissa fall var det billigare att låta agenten återimplementera delmängder av funktionalitet än att hantera otydligt beteende från offentliga bibliotek. Istället för att till exempel använda ett generiskt p-limit-stilspaket implementerade vi vår egen map-with-concurrency-hjälpfunktion: den är tätt integrerad med vår OpenTelemetry-instrumentering, har 100 % testtäckning och beter sig exakt som vår runtime förväntar sig.

Att dra in mer av systemet i en form som agenten kan granska, validera och ändra ökar inte bara inflytandet för Codex utan även för andra agenter (t.ex. Aardvark) som också arbetar med kodbasen.

Enbart dokumentation håller inte en helt agentgenererad kodbas samman. Genom att upprätthålla invarianta villkor och inte detaljstyra implementeringar låter vi agenter leverera snabbt utan att underminera grunden. Vi kräver till exempel att Codex analyserar datastrukturer vid gränsen⁠(öppnas i ett nytt fönster) men är inte specifika om hur det ska ske (modellen verkar föredra Zod fast vi specificerade inte det biblioteket).

Agenter är mest effektiva i miljöer med strikta gränser och förutsägbar struktur⁠(öppnas i ett nytt fönster) och vi skapade därför applikationen runt en rigid arkitektonisk modell. Varje företagsdomän är uppdelad i en fast uppsättning lager med strikt validerade beroenderiktningar och ett begränsat antal tillåtna kanter. Dessa begränsningar upprätthålls mekaniskt med hjälp av anpassade linters (självklart genererade av Codex!) och strukturella tester.

Diagrammet nedan visar regeln: inom varje företagsdomän (t.ex. App Settings) kan kod endast fortsätta "framåt" genom en fast uppsättning lager (Types → Config → Repo → Service → Runtime → UI). Tvärgående aspekter (autentisering, anslutningar, telemetri, funktionsflaggor) kommer in genom ett enda tydligt gränssnitt: Providers. Allt annat är förbjudet och genomdrivs mekaniskt.

Detta är den typ av arkitektur som man vanligtvis skjuter upp tills man har hundratals ingenjörer. Med kodningsagenter är det en tidig nödvändighet: begränsningarna möjliggör hastighet utan förfall eller arkitektonisk avvikelse.

I praktiken tillämpar vi dessa regler med anpassade linterverktyg och strukturella tester samt en liten uppsättning "smakinvarianter". Vi tillämpar till exempel statiskt strukturerad loggning, namngivningskonventioner för scheman och typer, filstorleksgränser och plattformsspecifika tillförlitlighetskrav med anpassade lintverktyg. Eftersom lintarna är anpassade skriver vi felmeddelandena för att inkludera åtgärdsinstruktioner i agentens sammanhang.

I ett människocentrerat arbetsflöde kan dessa regler upplevas som pedantiska eller begränsande. Med agenter blir de till multiplikatorer: när de väl är kodade tillämpas de överallt samtidigt.

Vi är samtidigt tydliga med vart begränsningar spelar roll och vart de inte gör det. Detta är som att leda en stor ingenjörsplattform: upprätthåll gränser centralt och tillåt autonomi lokalt. Du bryr dig mycket om gränser, korrekthet och reproducerbarhet. Inom dessa gränser ger du team (eller agenter) stor frihet i hur lösningar uttrycks.

Den resulterande koden stämmer inte alltid överens med mänskliga stilpreferenser och det är helt okej. Så länge resultatet är korrekt, underhållbart och läsbart för framtida agentkörningar uppfyller det kraven.

Mänsklig smak matas tillbaka in i systemet kontinuerligt. Granskningskommentarer, pull requests för refaktorering och användarvända buggar fångas upp som dokumentationsuppdateringar eller kodas direkt in i verktygen. När dokumentationen inte räcker till för vi in regeln i koden

När kapaciteten hos Codex ökade blev många konventionella ingenjörsnormer kontraproduktiva.

Arkivet fungerar med minimalt blockerande sammanslagningsportar. Pull requests är kortvariga. Testflak hanteras ofta med uppföljande körningar istället för att blockera framsteg på obestämd tid. I ett system där agenternas kapacitet vida överstiger mänsklig uppmärksamhet är korrigeringar billiga och väntan dyrt.

Detta skulle vara oansvarigt i en miljö med låg kapacitet. Här är det ofta den rätta kompromissen.

När vi säger att kodbasen genereras av Codex-agenter menar vi att allt i kodbasen är inkluderat.

Agenter skapar:

• Produktkod och tester
• CI-konfiguration och releaseverktyg
• Interna utvecklarverktyg
• Dokumentation och designhistorik
• Utvärderingsverktyg
• Granska kommentarer och svar
• Skript som hanterar arkivet
• Definitionsfiler i instrumentpanelen för produktion

Människor förblir alltid en del av processen men arbetar på en annan abstraktionsnivå än tidigare. Vi prioriterar arbete, översätter användarfeedback till acceptanskriterier och validerar resultat. När agenten kämpar ser vi det som en signal: identifiera vad som saknas (t.ex. verktyg, skyddsräcken, dokumentation) och mata tillbaka det till arkivet, alltid genom att låta Codex själv skriva lösningen.

Agenter använder våra standardutvecklingsverktyg direkt. De hämtar feedback från recensioner, svarar direkt, skickar uppdateringar och sammanfogar ofta sina egna pull requests.

I takt med att mer av utvecklingscykeln kodades direkt in i systemet (testning, validering, granskning, hantering av återkoppling och återställning) passerade arkivet nyligen en meningsfull tröskel där Codex kan driva en ny funktion från början till slut.

Med en enda prompt kan agenten nu:

• Validera det aktuella tillståndet i kodbasen
• Återskapa en rapporterad bugg
• Spela in en video som demonstrerar felet
• Implementera en lösning
• Validera åtgärden genom att köra applikationen
• Spela in en andra video som demonstrerar lösningen
• Öppna en pull request
• Svara på feedback från agenter och människor
• Identifiera och åtgärda fel i kompileringen
• Vidarebefordra till en människa när omdöme krävs
• Sammanfoga ändringen

Detta beteende beror i hög grad på den specifika strukturen och verktygsuppsättningen i detta arkiv och bör inte antas kunna generaliseras utan liknande investeringar, åtminstone inte än.

Fullständig agentautonomi introducerar även nya problem. Codex replikerar mönster som redan finns i arkivet, även ojämna och suboptimala. Detta leder med tiden till en avvikelse.

Inledningsvis hanterade människor detta manuellt. Vårt team brukade ägna varje fredag (20 % av veckan) åt att städa upp "AI-sörja". Det ledde inte helt oväntat till skalning.

Istället började vi koda in det vi kallar ”gyllene principer” direkt i förvaret och skapade en återkommande rensningsprocess. Dessa principer är normativa, mekaniska regler som håller kodbasen läsbar och konsekvent för framtida agentkörningar. Till exempel: (1) vi föredrar delade verktygspaket framför egenbyggda hjälpfunktioner för att hålla invarianterna centraliserade, och (2) vi undersöker inte data på ett ”YOLO-sätt” utan validerar gränser eller förlitar oss på typade SDK:er så att agenten inte bygger vidare av misstag på gissade strukturer. Med regelbunden frekvens har vi en uppsättning bakgrundsuppgifter i Codex som skannar efter avvikelser, uppdaterar kvalitetsbetyg och öppnar riktade pull requests för refactoring. De flesta av dessa kan granskas på mindre än en minut och slås ihop automatiskt.

Detta fungerar som upprensning. Teknisk skuld är som ett lån med hög ränta: det är nästan alltid bättre att betala av den kontinuerligt i små steg än att låta den växa och hantera den i smärtsamma omgångar. Mänsklig smak fångas upp en gång och tillämpas sedan kontinuerligt på varje kodrad. Detta gör det även möjligt för oss att identifiera och åtgärda dåliga mönster dagligen istället för att låta dem sprida sig i kodbasen under flera dagar eller veckor.

Denna strategi har hittills fungerat bra fram till den interna lanseringen och implementeringen hos OpenAI. Att skapa en riktig produkt för riktiga användare hjälpte oss att förankra våra investeringar i verkligheten och ledde oss mot långsiktig hållbarhet.

Det vi ännu inte vet är hur arkitektonisk koherens utvecklas under flera år i ett helt agentgenererat system. Vi lär oss fortfarande när mänskligt omdöme ger mest inflytande och hur man kodifierar det så att det förstärks. Vi vet inte heller hur detta system kommer att utvecklas i takt med att modeller fortsätter att bli mer kapabla med tiden.

Det som har blivit tydligt är att det fortfarande krävs disciplin för att skapa programvara, fast mer i strukturen än i själva koden. Verktygen, abstraktionerna och feedbackslingorna som håller kodbasen sammanhängande blir allt viktigare.

Våra mest utmanande uppgifter handlar nu om att utforma miljöer, återkopplingsslingor och styrsystem som hjälper agenter att uppnå vårt mål: att skapa och underhålla komplicerad och tillförlitlig programvara i stor skala.

När agenter som Codex tar över större delar av programvarans livscykel kommer dessa frågor att bli ännu viktigare. Vi hoppas att våra tidiga lärdomar hjälper dig att resonera kring vart du ska investera din energi för att enkelt kunna skapa saker.