Hvad det vil sige at være avanceret ingeniør hos OpenAI
Hvad vi laver, hvordan vi arbejder, og hvordan vi løser virksomheders sværeste problemer og skaber konkrete resultater.
Af: Colin Jarvis, leder af avanceret ingeniørarbejde hos OpenAI
Da Codex udkom, spurgte en fra teamet mig: “Hvad gør vi, når Codex bare kan løse de opgaver, vi har brugt de sidste par måneder på at bygge løsninger til, i ét forsøg?”
Det spørgsmål rammer kernen i, hvad det vil sige at være avanceret ingeniør hos OpenAI. Vi arbejder side om side med kunderne for at forstå deres sværeste problemer og bygge løsninger, de kan stole på. Det, vi lærer, er med til at forme vores produkter og giver forskningsafdelingen konkrete problemer at løse.
Det er fremskridt. Hvis vi gør os selv overflødige med et par måneders mellemrum, gør vores team af avancerede ingeniører sit arbejde.
Jeg grundlagde teamet i begyndelsen af 2025 for at lukke det, vi kalder “implementeringskløften”: afstanden mellem det, modellerne ser ud til at kunne, og det, folk pålideligt kan bruge i deres arbejde.
Modellernes evner har udviklet sig hurtigere end de systemer og processer, der skal til for at tage dem i brug. Nogle gange er den manglende brik et produkt. Andre gange klarer en model sig godt i en benchmarktest, men kan ikke løse opgaven med virkelighedens variabler og begrænsninger.
Vi fokuserer på kundernes sværeste problemer. Hvor vores modeller kan løse opgaven i dag, samarbejder vi med produktafdelingen og kunden om at gøre løsningen genanvendelig. Hvor modellerne kommer til kort, samarbejder vi med kunderne og forskningsafdelingen om at definere manglerne og skabe forbedringer. Vores mål er, at hvert samarbejde giver den næste kunde et bedre udgangspunkt. Hvis vi løfter grundniveauet så meget, at kunderne ikke behøver avancerede ingeniører til at løse denne type problem næste gang, har vi gjort vores arbejde godt.
Udfordringen for John Deere, en 200 år gammel virksomhed i landbrugsbranchen, var at udbrede personlig rådgivning til flere landmænd.
Et eksempel er See & Spray, virksomhedens teknologi til præcis ukrudtsbekæmpelse, som bruger kameraer og maskinlæring til at identificere og sprøjte ukrudt frem for at behandle hele marker. Det kan reducere kemikalieforbruget med op til 70 %.
Men for at opnå disse fordele skal landmændene vide, hvordan de indstiller teknologien, planlægger sæsonen og tilpasser deres metoder, når forholdene ændrer sig.
John Deere tog OpenAI's API'er i brug for at gøre denne støtte personlig og skalerbar.
AI kan besvare landmændenes spørgsmål i naturligt sprog, give skræddersyet vejledning i opsætning og anbefalinger, opdage, når udstyrets fulde potentiale måske ikke udnyttes, og hjælpe landmændene med at forstå, hvilken værdi de får af teknologien.
Mulighederne rækker ud over den enkelte samtale: Relevant vejledning gennem hele kunderejsen kan hjælpe landmændene med at udnytte deres udstyr bedre og samtidig øge effektiviteten og bæredygtigheden.
Det er den slags udfordringer, OpenAI's avancerede ingeniører arbejder på at løse: at hjælpe organisationer med at omsætte AI's evner til systemer, der skaber konkret værdi under komplekse forhold i virkeligheden.
Men problemerne er ofte uafgrænsede, der er måske ingen fastlagt facitliste, og der findes ingen opskrift. Alle vil bygge noget, der aldrig har eksisteret før. Færre vil gøre det, der skal til for at nå dertil.
At finde dygtige avancerede ingeniører og samtidig hæve barren for “godt nok” har krævet, at vi hele tiden eksperimenterer og omsætter erfaringerne til praksis.
Ved starten af hvert møde med teamet af avancerede ingeniører viser jeg en slide med én kerneværdi: “Tag udgangspunkt i resultatet, gør, hvad der skal til for at lykkes, og skalér derefter”.
En imponerende demo kan nå langt, før nogen spørger, om den virker i den virkelige verden.
Vores opgave er at løse kundens problem med en kvalitet, vi kan stå inde for, når løsningen er i drift.
I midten af 2025 havde vi omkring 15 avancerede ingeniører, der arbejdede med en stor kunde i halvlederbranchen på mindst 10 anvendelsesområder. Ambitionen var at lade AI være fundamentet for deres verifikationsproces, herunder:
Generering af målrettede test
Analyse af grundårsager og fejlfinding
En arkitekturassistent
Verifikation kan udgøre omkring 70 % af arbejdet i et projekt i denne branche. Potentialet var enormt, og der var mange mulige steder at begynde.
Nogle af de avancerede ingeniører var startet hos OpenAI blot få dage tidligere og havde aldrig arbejdet med halvledere. De blev en del af kundens verifikationsteam, studerede chipdesign i fritiden og udviklede evalueringer sammen med ingeniørerne for at teste, om AI kunne generere nyttige test og diagnosticere chipfejl korrekt.
Sideløbende med at vi lærte, byggede vi et tilpasset harness til hvert anvendelsesområde. I løbet af de første 3–6 måneder kom alle løsningerne i drift og fik deres første brugere. Resultaterne viste, at arbejdet bar frugt:
Omkring 48 % tidsbesparelse gennem AI-baseret generering af målrettede test.
En medianforbedring af ydeevnen på 22 % gennem kerneloptimering.
Ugers fejlfinding reduceret til timer
Da vi fremlagde det hele, spurgte hardwaredirektøren: “Arbejdede I som chipdesignere, før I kom hertil?”
Vores avancerede ingeniører behøver ikke kende branchen fra første dag, men de har selv ansvaret for at sætte sig ind i den.
Når kodeassistenter gør det hurtigere at udvikle software, bliver det endnu vigtigere at forstå kundens forretning. Vi sammensætter teams med en blanding af generalister og fageksperter.
Man skal have viden nok til at foretage velovervejede vurderinger og nysgerrighed nok til at sætte spørgsmålstegn ved antagelser om, hvordan tingene gøres i dag.
Inden for biovidenskab hjælper vores avancerede ingeniørers naturvidenskabelige baggrund dem for eksempel med at vinde tillid hos forskere, der arbejder med opgaver inden for præklinisk lægemiddelforskning, såsom validering og prioritering af lægemiddelmål, analyse af genekspression og rekonstruktion af kemiske synteseveje. Den ekspertise gør dem i stand til at bidrage med velbegrundede vurderinger af, hvordan disse arbejdsgange kan forbedres.
Vi havde vist, at disse arbejdsgange kunne skabe værdi, men hver af dem krævede stadig for meget skræddersyet integration til at kunne udbredes til et andet team. Den næste udfordring var at bevare resultaterne og samtidig gøre softwaren lettere at implementere og vedligeholde.
På det tidspunkt var Codex blevet mere kapabel. En avanceret ingeniør afprøvede at genopbygge applikationen omkring Codex og samarbejdede derefter med teamet om at flytte løsningerne til et fælles harness med Codex som kerne.
Skræddersyede applikationer blev til plugins og færdigheder bygget på fælles Codex-grundkomponenter. Codex blev også selve grænsefladen, så vi kunne udfase de særskilte terminalgrænseflader og kommandolinjegrænseflader, vi havde skrevet til de enkelte anvendelsesområder.
Vi kunne fjerne omkring 90 % af den specialskrevne kode fra hvert projekt, og det ændrede måden, vi byggede, vedligeholdt og skalerede disse arbejdsgange på:
Vi kunne drage fordel af centrale forbedringer af Codex, hvilket reducerede behovet for integrationskode til hvert enkelt anvendelsesområde
Centrale funktioner blev samlet som færdigheder og plugins, så de var lettere at dele mellem teamene og styre centralt fra AI-kompetencecentret. Det betød, at udrulningen fra ét team til det næste kunne være så enkel som at indsætte nye forbindelser/MCP-servere, bygge nye evalueringer (som vi også havde en færdighed til) og komme i gang.
I et eksempel fra august 2026 tog den første implementering to måneder. Det tog én dag at udrulle løsningen til et andet team. De næste teams kom hurtigere i gang, efterhånden som vi skalerede. Den udvikling er fortsat: I august 2026 tog udrulningen af én løsning til det andet team 1 dag, efter at den første implementering havde taget 2 måneder.
Det er én måde at gøre os selv overflødige på. Arbejdet med at få løsningen i drift havde vist, hvad der var vigtigt. Efterhånden som det underliggende produkt blev bedre, kunne vi erstatte en stor del af vores skræddersyede implementering og bevare den værdi, den skabte.
Derfor er rækkefølgen vigtig. Store sprogmodeller (LLM’er) lader os udvikle hurtigt. Brug den fart til at give brugerne noget værdifuldt, lær, hvad der holder i praksis, og skalér så det, der virker.
Det samme princip gælder i alle kundesamarbejder.
OpenAI Presence, vores produkt til virksomheders stemme- og chatagenter, voksede ud af virkelige kundeimplementeringer. Arbejdet begyndte med Swarm(åbner i et nyt vindue) og udviklede sig gennem Agents API, og i dag håndterer én kunde nu mere end halvdelen af sine opkald med AI.
At få disse implementeringer i produktion lærte os, hvilke problemer der krævede en brugerdefineret løsning, og hvilke byggesten andre teams kunne bruge. Vi har integreret disse byggesten i Presence, hvilket gør det nemmere for udviklere at automatisere regulerede arbejdsgange uden at genopbygge den underliggende infrastruktur. Hver implementering hjalp med at forme produktet og gav den næste kunde et bedre udgangspunkt.
Sammen med Thrive Holdings arbejdede OpenAI’s FDE’er og forskere sammen med ingeniører og revisorer om at udvikle Tax AI til Cretes revisionsfirmaer. Under pilotprojektet behandlede Tax AI 7.000 selvangivelser og øgede gennemløbet med omkring 50 %.
En af de sværeste udfordringer var at automatisere selvangivelser for udlejningsejendomme, hvilket krævede seks ugers ingeniørarbejde og gennemgang ved fagfolk for at nå 90 % præcision og genfinding. Arbejdet skabte genanvendelige mønstre, der gjorde det nemmere at udvide Tax AI til andre komplekse skatteskemaer.
Teamene anvender nu den samme tilgang til bogføring, revision og it-support og bygger systemer, der forbedres gennem feedback fra fagfolk og brug i praksis.
Nogle gange gør et bedre produkt det muligt at forenkle det, vi har bygget, men andre gange kan selve modellen endnu ikke løse opgaven.
Hvis vi kun bygger det, som dagens modeller allerede gør muligt, opdager vi ikke de mangler i modellernes evner, som forskningsafdelingen skal afhjælpe som det næste. Derfor starter mange af vores vigtige kundesamarbejder netop ved disse grænser, hvor kunden, de avancerede ingeniører og forskningsafdelingen forpligter sig til at overvinde dem sammen.
Vi havde allerede udviklet en kundeserviceplatform sammen med en stor kunde i telebranchen, og de ville udvide den til også at håndtere tale.
Telefonopkald stod for omkring 90 % af deres kundeservicehenvendelser. Disse henvendelser var dyrere at håndtere uden menneskelig hjælp end chat og gav en række nye tekniske udfordringer med at få accenter, tone samt svartid og nøjagtighed op på et niveau, der var klar til drift. At få det til at fungere ville gøre en væsentlig forskel for deres forretning.
Under afklaringen af projektets omfang scorede vores model omkring 60 % i de centrale evalueringer, vi brugte til at vurdere, om den kunne løse opgaven i drift. Vi havde nået grænsen for dens evner. Den skulle blive bedre til funktionskald og til at følge instruktioner i kundeservicesituationer.
Det forklarede vi kunden og inddrog forskningsafdelingen i arbejdet. De avancerede ingeniører samarbejdede med kunden om at bygge platformen og definere, hvad modellen skulle kunne. Forskningsafdelingen arbejdede på at afhjælpe manglerne i modellens evner, og med løbende modelversioner kunne vi teste fremskridtene op mod kundens krav.
I løbet af seks måneder steg resultaterne i de centrale evalueringer fra omkring 60 % til 80 % og derefter 90 % eller mere, så modellen nåede det niveau, der krævedes for at sætte den i drift.
Den talemodel, der kom ud af arbejdet, understøtter nu både denne kundes løsning, andre skræddersyede kundeserviceløsninger og løsninger, der drives via Presence. Et problem i én kundes forretning hjalp med at identificere forbedringer, som kunne gavne mange andre.
Alle dele var vigtige. Kunden forpligtede sig til at arbejde på et problem, modellen endnu ikke kunne løse. De avancerede ingeniører arbejdede tæt nok på kunden til at afgrænse problemet, bygge platformen og drive samarbejdet fra start til slut. Forskningsafdelingen forbedrede modellens underliggende evner.
Det er den anden måde at gøre os selv overflødige på: at hjælpe med at omsætte et problem, dagens modeller ikke kan løse, til en evne, fremtidens modeller kan levere. Værdien af vores arbejde rækker ud over de timer, vi bruger hos den enkelte kunde.
Jeg kom til OpenAI for at hjælpe med at gøre AI nyttig i folks daglige arbejde. Det er stadig det, der driver teamet. Jeg siger ofte til teamet, at Ockhams ragekniv gælder i de fleste tilfælde inden for LLM-udvikling: Den enkleste løsning er den bedste. I en virksomhed, der er kendetegnet ved banebrydende forskning, og i en branche præget af overdrevne påstande vil vi bygge løsninger, der fungerer pålideligt, og som folk kan stole på i deres daglige arbejde.
Målet er, at hvert kundesamarbejde forbedrer det, der kommer bagefter: et produkt, der er lettere at implementere, en model, der kan løse en sværere opgave, eller mindre behov for specialtilpasning hos den næste kunde.
Har du et svært problem, du vil have løst, vil vi gerne samarbejde med dig. Vil du hjælpe med at løse de problemer, vil vi gerne have dig med på holdet.
Så hvad gør vi, når Codex kan klare det arbejde, vi brugte måneder på at bygge løsninger til?
Vi finder et sværere problem.
