OpenAI Codex: verifierbara belägg är kärnan i kodgranskningen

OpenAI presenterade en forskningsförhandsversion av molnbaserade Codex den 16 maj 2025. Den drevs av codex-1, en version av o3 anpassad för programvaruutveckling. Uppgifter kördes i separata miljöer med kodförrådet förberett. Det daterade tillägget till systemkortet beskrev filläsning, redigering, tester och hänvisningar till terminalloggar och filer. En senare presentation den 15 september 2025 introducerade GPT-5-Codex och betonade kodgranskning. Det är olika steg i produktens historia. Den här historiska analysen publiceras den 25 oktober 2026. Den fastställer inte aktuella versioner, priser, abonnemangsgränser eller tillgänglighet. Skillnaden är viktig eftersom ett lanseringsdokument beskriver beskedet vid en viss tidpunkt, inte tjänstens hela beteende mer än ett år senare. Ett införandebeslut behöver en ny kontroll av faktisk konfiguration och avtal. 1

En hänvisning till terminalen låter granskaren kontrollera vad som faktiskt kördes i stället för att lita på en berättande sammanfattning. Ett lyckat kommando kan ändå sakna betydelse för ändringen. Begär exakt testkommando, resultat och uppgifter om överhoppade kontroller. Skilj tester som körts från tester agenten bara rekommenderar. Ett verifierbart underlag minskar oklarheten men tar inte bort behovet av att bedöma om beläggen stöder påståendet.

Systemkortstillägget från maj beskrev att internetåtkomst saknades under själva uppgiften efter förberedelserna. Lanseringssidan noterade senare en juniuppdatering som lät användare ge internetåtkomst. Därför vore det missvisande att upprepa det ursprungliga isoleringspåståendet som en bestående produktgaranti. Utvärdera den faktiska miljön, nätverksbehörigheterna och beroendena i varje pilot. Säkerhetsegenskaper hör till en daterad konfiguration, inte ett produktnamn som fortsätter förändras.

Bedöm granskningen med ändringar som innehåller kända fel. Mät vilka fynd som stämmer, vilka viktiga fel som missas och tiden utvecklare lägger på falska larm. Räkna allvarlighetsgrad, inte bara antal kommentarer. En granskare med många trovärdiga synpunkter kan bromsa leveransen utan att förebygga viktiga fel. Skilj agenten som skriver koden från det slutliga godkännandet. Att låta samma system berömma sin egen ändring är ingen oberoende granskningsmetod.

Kräv mer än ett påstående om godkända tester vid utvärdering av Codex. Varje föreslagen ändring bör ange testad revision, exakta kommandon, miljöantaganden, avslutningsstatus och relevant utdata. Skilj faktiskt genomförda kontroller från sådana som bara rekommenderats eller blockerats av saknade beroenden. Begär ett regressionstest som misslyckas med det ursprungliga felet och lyckas efter rättningen; annars kanske en grön testsvit aldrig prövar det ändrade beteendet. Förankra förväntningarna i företagskunskap och tillämpa agentsäkerhet när tester kräver inloggningsuppgifter eller externa tjänster. Behandla genererade förklaringar som vägledning för granskaren, inte som ersättning för reproducerbara belägg om ändringen. Ange även vilka centrala beteenden som ännu inte har kunnat verifieras.

Granskaren behöver undersöka om testernas kontroller bevisar kravet eller bara speglar den nya implementationen. Leta efter försvagade förväntningar, borttagen täckning, omfattande testdubblar och uppdaterade ögonblicksbilder utan förklaring. Upprepa den avgörande kontrollen i en ren miljö när det går. Skilj produktfel från infrastrukturfel utan att automatiskt ursäkta någotdera. Ta med negativa fall och kompatibilitetsgränser när gemensamt beteende påverkas. Registrera hur ofta beläggspaketet låter en annan utvecklare nå samma slutsats. AI-rådgivning kan hjälpa till att utforma granskningskriterier; en AI-föreläsning kan förklara varför trovärdiga testberättelser inte är kvalitetssäkring. Införandet bör bygga på kontroller som andra kan upprepa, inte på säkerheten i en genererad sammanfattning av arbetet.