OpenAI Codex release notes: självlärande eval-loopar i praktiken

Det här är inte en ny knapp i Codex CLI. Det är ändå en viktig OpenAI Codex release-notes-signal: OpenAI visar hur Codex används när ett produktionssystem ska bli bättre av verklig feedback, inte bara av fler prompts.

För Hammer-läsare är poängen ganska jordnära. En kodagent är en AI-agent som kan läsa kod, föreslå ändringar och köra kontroller i en avgränsad miljö. En eval är ett test eller en mätning som säger om agenten faktiskt blev bättre på en viss uppgift. När de två kopplas ihop med spårbar produktionsevidens, mänsklig granskning och tydliga stoppregler börjar Codex likna en kontrollerad förbättringsverkstad. Inte magi. Mer som ett arbetssätt.

OpenAI Codex release notes: signalen är feedback som blir arbete

Den formella Codex-changeloggen har fortfarande Codex CLI 0.134.0 som senaste stabila CLI-post. Den postade vi om redan, med profiler, MCP och lokala historiksökningar. Dagens nya signal kommer i stället från OpenAI Engineering: artikeln om Tax AI, byggd av OpenAI och Thrive Holdings för Cretes nätverk av redovisningsbyråer.

Källa: Codex changelog: Codex CLI 0.134.0 och OpenAI Engineering: Building self-improving tax agents with Codex.

OpenAI beskriver ett produktionsflöde där korrigeringar från praktiker blir mer än supportärenden. De blir strukturerade fynd, riktade evals och avgränsade Codex-uppgifter. Det är release-note-värdet här: Codex flyttas från "hjälp mig skriva kod" till "undersök den här återkommande avvikelsen, förbättra rätt del av systemet och bevisa det med evals".

Vad OpenAI visade i Tax AI

Tax AI hjälper amerikanska redovisningspraktiker med 1040- och 1041-deklarationer. I pilotmiljön behandlade systemet 7 000 deklarationer, sparade ungefär en tredjedel av förberedelsetiden, tog fram utkast med upp till 97 procents träffsäkerhet och ökade genomströmningen med ungefär 50 procent. OpenAI skriver också att andelen deklarationer som nådde 75 procent korrekt ifyllnad gick från en fjärdedel vid lansering till 86 procent inom sex veckor.

Källa: OpenAI Engineering: measurable self-improvement in Tax AI.

Det viktiga är inte amerikansk skatt i sig. Det viktiga är hur teamet gjorde fel användbara. En ändrad siffra kunde bero på en verklig extraktionsmiss, ett mappningsfel, saknat produktstöd, en preferens från praktiker eller normalt arbetsflödesbrus. Innan Codex fick göra något behövde skillnaderna grupperas, granskas och göras mätbara.

Från produktionsspår till kontrollerad Codex-uppgift

OpenAI beskriver tre delar: håll dig nära experterna, bygg produkten så att produktion skapar evidens, och låt Codex arbeta mot granskade evals. Ett produktionsspår är den sparade kedjan från källdokument till extraherat fält, proveniens, mappning, mänsklig korrigering och slutligt resultat. Utan det spåret vet agenten inte vad den ska förbättra.

Källa: OpenAI Engineering: practitioner feedback, production traces and Codex-driven eval loops.

Det mest praktiska stycket i artikeln är arbetsmiljön. OpenAI visar en avgränsad kandidatmiljö där Codex får en skrivbar arbetsgren, relevanta produktfiler, riktade evals, regressionssviter, skills och dokumentation. Produktionsspår, källdokument och tax-engine-dokumentation ligger däremot som läsbar evidens. Det är en sund integrationsmodell: låt agenten se tillräckligt för att felsöka, men ge den inte fri hand över originaldata eller produktionssystem.

Källa: OpenAI Engineering: bounded Codex task environment.

Vad svenska team kan testa nu

För ett svenskt automationsteam kan samma mönster användas i mindre skala: kundsupportärenden, offertflöden, schemaavvikelser, fakturatolkning, interna kunskapsbaser eller rapportautomatisering. Välj ett återkommande fel som människor redan rättar. Spara före- och eftervärden, källa, beslut och testfall. Gör sedan en liten eval innan Codex får föreslå ändringar.

Det här passar väl in i Verktygssmide: bygg en AI-arbetsmiljö där integrationen är användbar men kontrollerad. Använd miljövariabler eller secret manager för nycklar, avgränsade behörigheter, skrivskyddade spår, maskering av känsliga fält, godkännandegrindar före ändringar och loggar som går att granska. Då blir Codex en del av förbättringsarbetet, inte en svart låda bredvid det.

Kort exempel: använd nyheten i Codex

Mänskligt steg: välj ett återkommande, redan granskat fel och samla exempel, förväntat resultat, relevanta filer och ett eval-kommando i en separat arbetsgren eller kandidat-mapp. Dela bara den evidens agenten behöver.

Klistra sedan in en kort instruktion till Codex:

Review this candidate improvement loop. Use the provided trace, expected output and eval command to identify the smallest product change that could fix the repeated failure. Do not edit files yet. Return: suspected root cause, files you would inspect, evals to run, data that must stay read-only, and the approval point before any code change.

Bra svar ska:

• skilja mellan skrivbar kod och läsbar produktionsevidens
• föreslå en liten ändring, inte en ombyggnad av hela flödet
• nämna vilka evals och regressioner som bevisar förbättringen
• stoppa vid mänskligt godkännande innan filer ändras

Att bevaka härnäst

Jag skulle inte migrera processer bara för att en GitHub alpha-tagg finns. Vänta på en tydlig Codex-changelogg eller stabil release om du behöver versionsbeslut. Men börja gärna samla spår och evals redan nu. När nästa Codex CLI-release kommer är teamet som har bra testfall, tydliga behörigheter och granskade förbättringskandidater mycket bättre rustat än teamet som bara har en lång lista med "AI-idéer".