Hva det vil si å være kundeintegrert ingeniør hos OpenAI
Hva vi gjør, hvordan vi jobber, og hvordan vi løser bedrifters tøffeste problemer for å skape reelle resultater.
Av: Colin Jarvis, leder for kundeintegrert ingeniørarbeid hos OpenAI
Da Codex kom, spurte en på teamet meg: «Hva gjør vi når Codex kan løse oppgavene vi har brukt de siste månedene på å bygge løsninger for, i ett forsøk?»
Det spørsmålet treffer kjernen i hva det vil si å være kundeintegrert ingeniør hos OpenAI. Vi jobber side om side med kundene for å forstå de vanskeligste problemene deres og bygge løsninger de kan stole på. Det vi lærer, bidrar til å forme produktene våre og gir forskningsteamet konkrete problemer å løse.
Det er fremgang. Hvis vi gjør oss selv overflødige annenhver måned, gjør teamet vårt av kundeintegrerte ingeniører jobben sin.
Jeg opprettet teamet tidlig i 2025 for å tette det vi kaller «implementeringsgapet»: avstanden mellom det modellene ser ut til å kunne gjøre, og det folk pålitelig kan bruke dem til i arbeidet sitt.
Modellenes evner har utviklet seg raskere enn systemene og prosessene som trengs for å ta dem i bruk. Noen ganger er det et produkt som mangler. Andre ganger gjør en modell det bra på en standardisert test, men klarer ikke jobben med variablene og begrensningene som finnes i praksis.
Vi fokuserer på kundenes vanskeligste problemer. Der modellene våre kan gjøre jobben i dag, samarbeider vi med produktteamet og kunden om å gjøre løsningen gjenbrukbar. Der modellene kommer til kort, samarbeider vi med kundene og forskningsteamet om å definere hva som mangler, og gjøre forbedringer. Målet vårt er at hvert oppdrag skal gi den neste kunden et bedre utgangspunkt. Hvis vi hever grunnivået så mye at kundene ikke trenger kundeintegrerte ingeniører for å løse denne typen problem neste gang, har vi gjort en god jobb.
Utfordringen for John Deere, et 200 år gammelt selskap i landbrukssektoren, var å gi individuelt tilpassede råd til bønder i stor skala.
Et eksempel er See & Spray, selskapets teknologi for presis ugressbekjempelse. Den bruker kameraer og maskinlæring til å identifisere og sprøyte ugress i stedet for å behandle hele åkre, og kan dermed redusere kjemikaliebruken med opptil 70 %.
Men for å oppnå disse fordelene må bøndene vite hvordan de skal konfigurere teknologien, planlegge sesongen og tilpasse driften når forholdene endrer seg.
John Deere tok i bruk API-ene fra OpenAI for å gjøre denne støtten individuelt tilpasset og skalerbar.
KI kan svare på bøndenes spørsmål på naturlig språk, gi tilpasset oppsettsveiledning og anbefalinger, oppdage når utstyrets potensial kanskje ikke utnyttes fullt ut, og hjelpe bøndene med å forstå verdien de får ut av teknologien.
Mulighetene strekker seg utover den enkelte samtalen: relevant veiledning gjennom hele kundereisen kan hjelpe bøndene med å utnytte utstyret bedre og samtidig drive mer effektivt og bærekraftig.
Det er denne typen utfordringer OpenAIs kundeintegrerte ingeniører jobber med å løse: å hjelpe organisasjoner med å omsette mulighetene i KI til systemer som gir praktisk verdi i komplekse miljøer i den virkelige verden.
Men problemene er ofte vidåpne, det finnes kanskje ingen etablert fasit, og det er ingen oppskrift å følge. Alle vil bygge noe som aldri har eksistert. Færre vil gjøre det som trengs for å komme dit.
Å finne dyktige kundeintegrerte ingeniører samtidig som vi hever terskelen for hva som er «godt nok», har krevd kontinuerlig eksperimentering og utprøving i praksis.
I starten av hver samling med de kundeintegrerte ingeniørene viser jeg et lysbilde med én kjerneverdi: «Ta utgangspunkt i resultatet, gjør det som trengs for å lykkes, og skaler deretter».
En imponerende demo kan nå langt før noen spør om den fungerer i praksis.
Jobben vår er å løse kundens problem med en kvalitet vi kan stå inne for i produksjon.
I midten av 2025 hadde vi rundt 15 kundeintegrerte ingeniører som jobbet med over 10 bruksområder hos en stor kunde i halvlederbransjen. Ambisjonen var å bygge verifikasjonsprosessen deres rundt KI, med blant annet:
Generering av målrettede tester
Rotårsaksanalyse og feilsøking
En arkitekturassistent
Verifikasjon kan stå for rundt 70 % av arbeidsinnsatsen i et prosjekt i denne bransjen. Potensialet var enormt, og det var mange mulige steder å begynne.
Noen av de kundeintegrerte ingeniørene hadde begynt hos OpenAI bare noen dager tidligere og hadde aldri jobbet med halvledere. De ble en del av kundens verifikasjonsteam, studerte brikkedesign på fritiden og utviklet evalueringer sammen med ingeniørene for å teste om KI kunne generere nyttige tester og diagnostisere brikkefeil riktig.
Parallelt med denne læringen bygget vi tilpassede rammeverk for de enkelte bruksområdene. I løpet av de første 3–6 månedene var alle løsningene satt i produksjon og tatt i bruk av de første brukerne. Resultatene viste at innsatsen lønte seg:
Rundt 48 % spart tid gjennom KI-basert generering av målrettede tester.
22 % bedre ytelse i median gjennom kjerneoptimalisering.
Uker med feilsøking redusert til timer
Da vi presenterte alt dette, spurte maskinvaredirektøren: «Jobbet dere som brikkedesignere før dere kom hit?»
Våre kundeintegrerte ingeniører trenger ikke å kjenne bransjen fra dag én, men de har ansvar for å lære den å kjenne.
Når kodeassistenter gjør det raskere å bygge programvare, blir det enda viktigere å forstå kundens virksomhet. Vi setter sammen team med både generalister og domeneeksperter.
Du trenger nok kunnskap til å gjøre gode vurderinger, og nok nysgjerrighet til å utfordre antakelser om hvordan ting gjøres i dag.
Innen livsvitenskap bidrar for eksempel den vitenskapelige bakgrunnen til våre kundeintegrerte ingeniører til å skape tillit hos forskere som arbeider med preklinisk legemiddelutvikling. Oppgavene omfatter blant annet validering og prioritering av målmolekyler, genekspresjonsanalyse og rekonstruksjon av kjemiske synteseveier. Denne ekspertisen gjør at de kan bidra med velbegrunnede vurderinger av hvordan arbeidsflytene kan forbedres.
Vi hadde vist at disse arbeidsflytene kunne skape verdi, men hver av dem krevde fortsatt for mye skreddersydd integrasjon for å kunne tas i bruk av et nytt team. Den neste utfordringen var å bevare resultatene og samtidig gjøre programvaren enklere å sette i drift og vedlikeholde.
På det tidspunktet hadde Codex blitt mer kapabel. En kundeintegrert ingeniør prøvde å bygge om applikasjonen sin med Codex som grunnlag, og samarbeidet deretter med teamet om å flytte løsningene for de ulike bruksområdene til et felles rammeverk med Codex i kjernen.
Skreddersydde applikasjoner ble til programtillegg og ferdigheter bygget på felles grunnkomponenter i Codex. Codex ble også selve grensesnittet, slik at vi kunne avvikle de separate terminalgrensesnittene og kommandolinjegrensesnittene vi hadde skrevet for hvert bruksområde.
Vi kunne fjerne omtrent 90 % av den skreddersydde koden fra hvert prosjekt. Det endret hvordan vi bygget, vedlikeholdt og skalerte disse arbeidsflytene:
Vi kunne dra nytte av sentrale forbedringer i Codex og dermed redusere mengden integrasjonskode som krevdes for hvert bruksområde
Viktige funksjoner ble samlet i ferdigheter og programtillegg, noe som gjorde dem enklere å dele mellom team og styre sentralt fra kompetansesenteret for KI. Dermed kunne det å utvide løsningen fra ett team til det neste være så enkelt som å bytte til nye koblinger eller MCP-servere, lage nye evalueringer (som vi også hadde en ferdighet for) og komme i gang.
I ett eksempel fra august 2026 tok den første implementeringen to måneder. Å utvide løsningen til et nytt team tok én dag. De neste teamene kom raskere i gang etter hvert som vi skalerte. Denne utviklingen har fortsatt: For ett bruksområde i august 2026 tok det én dag å få det andre teamet i gang, etter at den første implementeringen hadde tatt to måneder.
Dette er én måte å gjøre oss selv overflødige på. Arbeidet med å få løsningen i produksjon hadde avklart hva som var viktig. Etter hvert som det underliggende produktet ble bedre, kunne vi erstatte mye av den skreddersydde implementeringen og beholde verdien den ga.
Det er derfor rekkefølgen er viktig. LLM-er lar oss bygge raskt. Bruk den farten til å gi brukerne noe verdifullt, finn ut hva som holder i praksis, og skaler deretter det som fungerer.
Det samme prinsippet gjelder for alle oppdrag.
OpenAI Presence, produktet vårt for tale- og chat-agenter i bedrifter, vokste ut av reelle kundeimplementeringer. Arbeidet startet med Swarm(åpnes i et nytt vindu) og utviklet seg gjennom Agents API, og i dag håndterer én kunde nå mer enn halvparten av samtalene sine med AI.
Å få disse utrullingene i produksjon lærte oss hvilke problemer som krevde en tilpasset løsning, og hvilke byggeklosser andre team kunne bruke. Vi tok med oss disse byggeklossene inn i Presence, noe som gjør det enklere for utviklere å automatisere regulerte arbeidsflyter uten å gjenoppbygge den underliggende infrastrukturen. Hver utrulling bidro til å forme produktet og ga den neste kunden et bedre utgangspunkt.
Med Thrive Holdings, OpenAI FDE-er og forskere jobbet sammen med ingeniører og regnskapsførere for å bygge skatte-AI for Kretas regnskapsfirmaer. I løpet av pilotprosjektet behandlet Tax AI 7000 selvangivelser og økte gjennomstrømningen med omtrent 50 %.
En av de vanskeligste utfordringene var å automatisere retur av utleieeiendommer, noe som krevde seks uker med teknisk og fagmessig gjennomgang for å oppnå 90 % presisjon og tilbakekalling. Arbeidet skapte gjenbrukbare mønstre som gjorde det enklere å utvide skatte-AI til andre komplekse skatteskjemaer.
Teamene bruker nå den samme tilnærmingen til bokføring, revisjon og IT-støtte – de bygger systemer som forbedres gjennom tilbakemeldinger fra fagfolk og bruk i den virkelige verden.
Noen ganger lar et bedre produkt oss forenkle det vi har bygget, men andre ganger er det selve modellen som ennå ikke kan gjøre jobben.
Hvis vi bare bygger det dagens modeller allerede gjør mulig, vil vi ikke avdekke de neste manglene i modellenes evner som forskningsteamet må utbedre. Derfor begynner mange av våre viktige oppdrag ved nettopp disse grensene. Kunden, de kundeintegrerte ingeniørene og forskningsteamet forplikter seg til å jobbe seg gjennom utfordringene sammen.
Vi hadde allerede utviklet en kundeserviceplattform sammen med en stor telekomkunde, og de ønsket å utvide den til å håndtere telefonsamtaler.
Telefonsamtaler sto for rundt 90 % av kundeservicehenvendelsene deres. Disse henvendelsene var dyrere å løse uten menneskelig hjelp enn chat, og bød på en rekke nye tekniske utfordringer: Håndtering av aksenter og tonefall, samt responstid og nøyaktighet, måtte opp på et nivå som holdt i produksjon. Å lykkes med dette ville ha stor betydning for virksomheten deres.
I kartleggingsfasen oppnådde modellen vår rundt 60 % på de viktigste evalueringene vi brukte for å vurdere om den kunne gjøre jobben i produksjon. Vi hadde nådd grensen for hva den kunne klare. Funksjonskall og evnen til å følge instruksjoner i kundeservicesituasjoner måtte bli bedre.
Vi forklarte dette til kunden og involverte forskningsteamet i arbeidet. De kundeintegrerte ingeniørene samarbeidet med kunden om å bygge plattformen og definere hva modellen måtte kunne gjøre. Forskningsteamet jobbet med å utbedre manglene i modellens evner. Nye modellversjoner lot oss fortløpende teste fremgangen opp mot kundens krav.
I løpet av seks måneder steg resultatene på de viktigste evalueringene fra rundt 60 % til 80 % og deretter til over 90 %, og nådde dermed nivået som krevdes for produksjon.
Talemodellen vi utviklet, brukes nå i denne kundens løsning, i andre skreddersydde kundeserviceløsninger og i administrerte løsninger gjennom Presence. Et problem hos én kunde bidro til å avdekke forbedringer som kunne komme mange andre til gode.
Alle bidragene var viktige. Kunden forpliktet seg til å jobbe med et problem modellen ennå ikke kunne løse. De kundeintegrerte ingeniørene jobbet tett nok på kunden til å konkretisere problemet, bygge plattformen og drive oppdraget fra start til slutt. Forskningsteamet forbedret den underliggende modellens evner.
Dette er den andre måten å gjøre oss selv overflødige på: å bidra til at et problem dagens modeller ikke kan løse, blir noe fremtidige modeller kan håndtere. Verdien av arbeidet vårt strekker seg utover timene vi bruker hos den enkelte kunden.
Jeg begynte hos OpenAI for å bidra til å gjøre KI nyttig i folks arbeidshverdag. Det er fortsatt det som styrer teamet. Jeg sier ofte til teamet at Ockhams barberkniv gjelder i de fleste tilfeller av LLM-utvikling: Den enkleste løsningen er den beste. I et selskap som kjennetegnes av banebrytende forskning, og i en bransje preget av overdrivelser, vil vi bygge ting som fungerer pålitelig, og som folk kan stole på i det daglige arbeidet.
Målet er at hvert oppdrag skal gjøre det neste enklere: et produkt som er lettere å sette i drift, en modell som kan håndtere en vanskeligere oppgave, eller mindre personlig tilpasning for den neste kunden.
Har du et vanskelig problem du vil løse, vil vi gjerne samarbeide med deg. Vil du bidra til å løse slike problemer, vil vi gjerne ha deg med på laget.
Så hva gjør vi når Codex kan håndtere arbeidet vi brukte måneder på å bygge løsninger for?
Finner et vanskeligere problem.
