Vad det innebär att vara kundnära ingenjör på OpenAI
Vad vi gör, hur vi arbetar och hur vi löser företagens svåraste problem för att göra verklig skillnad.
Av: Colin Jarvis, chef för kundnära ingenjörsarbete på OpenAI
När Codex lanserades frågade någon i teamet mig: ”Vad gör vi när Codex klarar de användningsfall vi ägnat de senaste månaderna åt att bygga på ett enda försök?”
Den frågan fångar kärnan i vad det innebär att vara kundnära ingenjör på OpenAI. Vi arbetar sida vid sida med kunderna för att förstå deras svåraste problem och bygga lösningar som de kan lita på. Det vi lär oss bidrar till att forma våra produkter och ger forskningsteamet konkreta problem att lösa.
Det är framsteg. Om vi gör oss själva överflödiga varannan månad gör vårt team av kundnära ingenjörer sitt jobb.
Jag grundade teamet i början av 2025 för att överbrygga det vi kallar ”införandegapet”: avståndet mellan vad modeller verkar klara av och vad människor tillförlitligt kan använda i sitt arbete.
Modellernas förmågor har utvecklats snabbare än de system och processer som behövs för att använda dem. Ibland är den saknade pusselbiten en produkt. Ibland presterar en modell bra i ett jämförelsetest men klarar inte uppgiften med verklighetens variabler och begränsningar.
Vi fokuserar på kundernas svåraste problem. Där våra modeller klarar uppgiften i dag arbetar vi med produktteamet och kunden för att göra lösningen återanvändbar. Där de inte räcker till arbetar vi med kunderna och forskningsteamet för att definiera bristerna och göra förbättringar. Vårt mål är att varje uppdrag ska ge nästa kund en bättre utgångspunkt. Om vi höjer grundnivån så mycket att kunderna inte behöver kundnära ingenjörer för att lösa den här typen av problem nästa gång har vi gjort ett bra jobb.
Utmaningen för John Deere, ett 200 år gammalt företag inom jordbrukssektorn, var att skala upp individanpassad rådgivning till lantbrukare.
Ett exempel är See & Spray, företagets teknik för precisionsbekämpning av ogräs. Den använder kameror och maskininlärning för att identifiera och bespruta ogräs i stället för att behandla hela fält, vilket minskar kemikalieanvändningen med upp till 70 %.
Men för att uppnå dessa fördelar måste lantbrukarna veta hur de ska konfigurera tekniken, planera säsongen och anpassa arbetssätten när förhållandena förändras.
John Deere började använda OpenAI:s API:er för att göra stödet individanpassat och skalbart.
AI kan besvara lantbrukarnas frågor på naturligt språk, ge anpassad vägledning och rekommendationer om inställningar, upptäcka när utrustningen kanske inte utnyttjas fullt ut och hjälpa lantbrukarna att förstå vilket värde tekniken ger dem.
Möjligheterna sträcker sig bortom enskilda kontakter: relevant vägledning genom hela kundresan kan hjälpa lantbrukarna att använda sin utrustning bättre och samtidigt öka effektiviteten och hållbarheten.
Det här är den typ av utmaning som OpenAI:s kundnära ingenjörer arbetar med: att hjälpa organisationer gå från AI-förmågor till system som skapar praktiskt värde i komplexa, verkliga miljöer.
Men problemen är ofta öppna, det kanske saknas ett etablerat facit och det finns ingen färdig väg framåt. Alla vill bygga något som aldrig har funnits. Färre vill göra det som krävs för att nå dit.
Att hitta skickliga kundnära ingenjörer samtidigt som vi höjer ribban för vad som är ”tillräckligt bra” har krävt att vi ständigt prövar nytt och omsätter lärdomarna i praktiken.
I början av varje möte med våra kundnära ingenjörer visar jag en presentationsbild med en grundprincip: ”Utgå från resultatet, gör det som krävs för att lyckas och skala sedan upp.”
En imponerande demo kan ta en långt innan någon frågar om den fungerar i verkligheten.
Vårt jobb är att lösa kundens problem med en kvalitet som vi kan stå för i produktion.
I mitten av 2025 hade vi omkring 15 kundnära ingenjörer som arbetade med en stor halvledarkund på över 10 användningsfall. Ambitionen var att göra AI till grunden för deras verifieringsprocess, med stöd för:
Generering av riktade tester
Grundorsaksanalys och felsökning
En arkitekturassistent
Verifiering kan stå för cirka 70 % av arbetsinsatsen i ett projekt i den här branschen. Potentialen var enorm, och det fanns många möjliga startpunkter.
Vissa kundnära ingenjörer hade börjat på OpenAI bara några dagar tidigare och hade aldrig arbetat med halvledare. De blev en del av kundens verifieringsteam, studerade chipdesign på fritiden och tog fram utvärderingar tillsammans med ingenjörerna för att testa om AI:n kunde generera användbara tester och korrekt diagnostisera fel i chip.
Parallellt med detta lärande byggde vi skräddarsydda körmiljöer för de enskilda användningsfallen. Under de första 3–6 månaderna sattes samtliga i produktion och började användas av de första användarna. Belöningen kom när vi såg siffrorna:
Cirka 48 % tidsbesparing genom AI-baserad generering av riktade tester.
22 % prestandaförbättring i median genom kerneloptimering.
Veckor av felsökning kortades till timmar
När vi presenterade allt detta frågade hårdvaruchefen: ”Jobbade ni som chipdesigners innan ni kom hit?”
Våra kundnära ingenjörer behöver inte kunna branschen från första dagen, men det är deras ansvar att lära sig den.
När kodassistenter gör det snabbare att bygga programvara blir förståelsen för kundens verksamhet ännu viktigare. Vi bygger team med en blandning av generalister och domänexperter.
Du behöver tillräcklig kunskap för att göra välgrundade bedömningar och tillräcklig nyfikenhet för att ifrågasätta invanda föreställningar.
Inom livsvetenskaperna hjälper till exempel våra kundnära ingenjörers vetenskapliga bakgrund dem att vinna förtroende hos forskare som arbetar med preklinisk läkemedelsutveckling, såsom validering och prioritering av målmolekyler, genuttrycksanalys och rekonstruktion av kemiska syntesvägar. Den sakkunskapen gör att de kan bidra med välgrundade bedömningar av hur arbetsflödena kan förbättras.
Vi hade visat att dessa arbetsflöden kunde skapa värde, men vart och ett krävde fortfarande för mycket skräddarsydd integration för att kunna införas i ytterligare ett team. Nästa utmaning var att behålla resultaten och samtidigt göra programvaran enklare att driftsätta och underhålla.
Vid det laget hade Codex blivit mer kapabelt. En kundnära ingenjör testade att bygga om sin applikation kring Codex och arbetade sedan med teamet för att flytta användningsfallen till en gemensam körmiljö med Codex som kärna.
Skräddarsydda applikationer blev insticksprogram och färdigheter byggda på gemensamma grundkomponenter i Codex. Codex blev också gränssnittet, så att vi kunde avveckla de separata terminal- och kommandoradsgränssnitt som vi hade skrivit för enskilda användningsfall.
Vi kunde ta bort ungefär 90 % av den skräddarsydda koden från varje projekt. Det förändrade hur vi byggde, underhöll och skalade upp dessa arbetsflöden:
Vi kunde dra nytta av centrala förbättringar av Codex, vilket minskade mängden integrationskod som krävdes för varje enskilt användningsfall
Viktiga funktioner paketerades som färdigheter och insticksprogram, vilket gjorde dem enklare att dela mellan team och styra centralt via kompetenscentret för AI. Det innebar att det kunde vara så enkelt att utöka till nästa team som att byta till nya anslutningar eller MCP-servrar, bygga nya utvärderingar (vilket vi också hade en färdighet för) och sedan sätta igång.
I ett exempel från augusti 2026 tog den första implementationen två månader. Att utöka lösningen till ett andra team tog en dag. Efterföljande team kom igång snabbare i takt med att vi skalade upp. Det har fortsatt så: i ett användningsfall från augusti 2026 tog det en dag för det andra teamet, efter att den första implementationen hade tagit två månader.
Det är ett sätt att göra oss själva överflödiga. Arbetet med att nå produktion hade visat vad som var viktigt. När den underliggande produkten förbättrades kunde vi ersätta stora delar av vår skräddarsydda implementation och behålla värdet den skapade.
Det är därför ordningen spelar roll. LLM:er låter oss bygga snabbt. Använd den snabbheten för att ge användarna något värdefullt, lär er vad som håller i praktiken och skala sedan upp det som fungerar.
Samma princip gäller för alla uppdrag.
OpenAI Presence, vår produkt för företags röst- och chattagenter, växte fram ur verkliga kunddistributioner. Arbetet började med Swarm(öppnas i ett nytt fönster) och utvecklades genom Agents API, och idag hanterar en kund mer än hälften av sina samtal med AI.
Att få dessa distributioner i produktion lärde oss vilka problem som behövde en anpassad lösning och vilka byggstenar andra team kunde använda. Vi tog med dessa byggstenar i Presence, vilket gjorde det lättare för utvecklare att automatisera reglerade arbetsflöden utan att bygga om den underliggande infrastrukturen. Varje driftsättning bidrog till att forma produkten och gav nästa kund en bättre utgångspunkt.
Med Thrive Holdings, OpenAI FDE och forskare arbetade tillsammans med ingenjörer och revisorer för att bygga Tax AI för Kretas redovisningsföretag. Under pilotprojektet behandlade Tax AI 7 000 skattedeklarationer och ökade Kapacitet med cirka 50%.
En av de svåraste utmaningarna var att automatisera deklarationsarbetet för hyresfastigheter, vilket krävde sex veckors utvecklingsarbete och granskning av sakkunniga för att uppnå 90 % precision och återkallelse. Arbetet skapade återanvändbara mönster som gjorde det lättare att utvidga Tax AI till andra komplexa skattescheman.
Teamen tillämpar nu samma tillvägagångssätt för bokföring, revision och IT-support - bygger system som förbättras genom feedback från praktiker och verklig användning.
Ibland gör en bättre produkt det möjligt att förenkla det vi har byggt, men ibland klarar modellen i sig ännu inte uppgiften.
Om vi bara bygger det som dagens modeller redan klarar av kommer vi inte att upptäcka de brister i förmåga som forskningsteamet behöver åtgärda härnäst. Därför börjar många av våra viktiga uppdrag just vid dessa gränser, där kunden, de kundnära ingenjörerna och forskningsteamet åtar sig att tillsammans ta sig förbi dem.
Vi hade redan utvecklat en kundserviceplattform tillsammans med en stor telekomkund, som nu ville utöka den med röststöd.
Röstsamtal stod för omkring 90 % av deras kundservicevolym. Dessa ärenden var dyrare att hantera utan eskalering än chattärenden och innebar en rad nya tekniska utmaningar: hanteringen av accenter, tonfall, svarstid och träffsäkerhet behövde nå produktionsnivå. En fungerande lösning skulle göra stor skillnad för deras verksamhet.
Under förstudien nådde vår modell omkring 60 % i de centrala utvärderingarna som vi använde för att bedöma om den kunde klara uppgiften i produktion. Vi hade nått gränsen för vad den klarade av. Funktionsanrop och förmågan att följa instruktioner i kundservicescenarier behövde förbättras.
Vi förklarade det för kunden och tog in forskningsteamet i arbetet. De kundnära ingenjörerna arbetade med kunden för att bygga plattformen och definiera vad modellen behövde göra. Forskningsteamet arbetade med att åtgärda bristerna i modellens förmågor. Med successiva modellversioner kunde vi testa framstegen mot kundens krav.
Under sex månader steg resultaten i de centrala utvärderingarna från omkring 60 % till 80 % och sedan till över 90 %, vilket uppfyllde kraven för produktion.
Den röstmodell som arbetet resulterade i används nu i den kundens lösning, i andra skräddarsydda kundservicelösningar och i hanterade lösningar via Presence. Ett problem i en kunds verksamhet hjälpte oss att identifiera förbättringar som kunde komma många andra till nytta.
Varje del var viktig. Kunden åtog sig att arbeta med ett problem som modellen ännu inte kunde lösa. De kundnära ingenjörerna arbetade tillräckligt nära kunden för att formulera problemet, bygga plattformen och driva uppdraget från början till slut. Forskningsteamet förbättrade den underliggande modellens förmågor.
Det här är det andra sättet att göra oss själva överflödiga: att bidra till att ett problem som dagens modeller inte kan lösa blir något som framtida modeller klarar av. Värdet av vårt arbete sträcker sig bortom de timmar vi tillbringar med en enskild kund.
Jag började på OpenAI för att bidra till att göra AI användbart i människors dagliga arbete. Det vägleder fortfarande teamet. Jag säger ofta till teamet att Ockhams rakkniv gäller i de flesta fall inom LLM-utveckling – den enklaste lösningen är den bästa. På ett företag som präglas av sin banbrytande forskning, i en bransch som dras med överdrifter, vill vi bygga sådant som fungerar tillförlitligt och som människor ute i verksamheterna kan lita på.
Målet är att varje uppdrag ska förbättra förutsättningarna för nästa: en produkt som är enklare att driftsätta, en modell som klarar en svårare uppgift eller mindre specialanpassning för nästa kund.
Har du ett svårt problem du vill lösa samarbetar vi gärna med dig. Vill du hjälpa till att lösa sådana problem ser vi gärna att du börjar hos oss.
Så vad gör vi när Codex klarar det vi ägnade månader åt att bygga?
Hittar ett svårare problem.
