Tidligere teknologigrunnlegger i Meta deler tre ting alle teknologidirektører må gjøre før de tar i bruk KI

James Everingham har ledet ingeniørarbeidet hos noen av verdens mest avanserte selskaper, blant annet Meta. Han er nå administrerende direktør og medgrunnlegger av Guild.ai, et kontrollplan for AI-agenter som gir organisasjoner ett sted å distribuere, styre, overvåke og optimalisere alle agenter i produksjon.

Vi satte oss ned med James for å lære hvordan AI endrer arbeidsflytene innen ingeniørarbeid – og hva ingeniørteam må endre før AI kan integreres effektivt. Her er det han fortalte oss.

Fra Meta til AI-oppstartsbedrift

Jeg er administrerende direktør og medgrunnlegger av Guild.ai, kontrollplanet for AI-agenter som gir organisasjoner ett sted å distribuere, styre, overvåke og optimalisere alle agenter i produksjon. Vi har hentet inn 44 millioner dollar – en serie A-runde ledet av Google Ventures, med deltakelse fra NFX, Acrew, Scribble Ventures, Khosla Ventures og Webb Investment Network. Vi er et team på rundt 35 personer basert i San Francisco.

Før dette var jeg visepresident for ingeniørarbeid i Meta DevInfra, der jeg bygget og drev de sentrale utviklerverktøyene, tjenestene og plattformene som driver Metas produkter. Teamet mitt bygget Metas første interne AI-agent, noe som umiddelbart påvirket hvordan Metas ingeniører brukte AI-verktøy. I løpet av tiden min i Meta var jeg også med på å skape Diem og var Instagrams teknologidirektør.

Med en 40 år lang karriere som leder, entreprenør og teknologiutvikler har jeg ledet en rekke ingeniørteam i verdensklasse. I Yahoo var jeg visepresident for ingeniørarbeid for Yahoos medievirksomheter etter at de kjøpte opp Luminate, et selskap innen interaktiv bildeteknologi som jeg grunnla. Før det ledet jeg team hos Oracle, Netscape Communications, Tellme (kjøpt opp av Microsoft) og flere av mine egne selskaper.

Hvordan AI bidro til å fjerne Metas årlige kodefrys

Da jeg var i Meta, brukte vi en AI-risikomodell til å avskaffe den årlige kodefrysen.

Tidligere frøs Meta kodebasen hvert år fra midten av desember til og med januar, fordi dette er perioden med mest trafikk til produktene deres. I årevis sendte ingen ut kode for å unngå produksjonshendelser i de mest risikable ukene. Dette var trygt, men det satte også produktiviteten i hele selskapet på pause i over en måned.

Teamet mitt bygget og gjorde Diff Risk Score tilgjengelig som åpen kildekode, et LLM-drevet system som beregner sannsynligheten for at en kodeforskjell fører til at produksjonen krasjer. I stedet for å behandle alle endringer som like farlige under fryseperioden utførte modellen en risikoprioritering. Den tildelte en kontinuerlig risikoscore til hver kodeforskjell, justert for høy tilbakekalling – for eksempel ved å flagge 10 % av kodeforskjellene samtidig som den fanget opp 60 % av endringene som faktisk forårsaket hendelser. Modellen gjorde det mulig for kodeforskjeller med lav risiko å bli tatt i bruk selv under fryseperioden, mens den holdt tilbake dem som ble flagget som risikable.

Resultatet er at fryseperioden ikke lenger er alt eller ingenting. Diff Risk Score gjør det også mulig for Meta å begynne å fjerne kodefrysen helt – ingeniørene får tilbake uker i kalenderen som tidligere var bortkastet tid, uten å ofre sikkerhetsnettet fryseperioden ga.

Det er et godt eksempel på min bredere filosofi: Ikke gi ingeniører et toppstyrt AI-pålegg, men gi dem infrastruktur – en sentralisert plattform, et risikosignal, et kontrollplan – og la dem selv finne ut hvordan de kan utnytte dette.

Hvorfor mennesker må kunne forklare kode før den settes i drift

Hvis du ikke kan forklare det, kan du ikke sette det i drift.

Jeg bruker AI-verktøy aktivt for å få fart på arbeidet, men jeg råder ingeniører til å alltid kreve validering før noe når produksjon. AI erstatter ikke ingeniørfaglig skjønn; den gir ingeniører større mulighet til å bruke dette skjønnet i stor skala.

AI gir nå innspill til arbeidet med risikovurdering, samt verktøy- og arbeidsflytutforskning.

Der mennesker er best:

• Styring og sikkerhetsrammer rundt selve agentene: Når team bygger resonneringsmodeller og agenter dypt inn i infrastrukturen, oppdager de raskt styringssvikt — agentene formerer seg raskere enn noen forventet, og budsjettene forsvinner over natten. Du trenger det samme styringslaget rundt ikke-deterministiske agenter som du ville lagt rundt mennesker som bruker denne infrastrukturen — det vil si at mennesker fortsatt fastsetter budsjettrammer, tilgangsgrenser og revisjonskrav.
• Adopsjonsstrategi: Du pålegger ikke bruk av AI-verktøy — bruk som er gjort fortjent slår pålagt bruk, siden pålegg fører til overfladisk bruk. Å avgjøre hvordan AI skal integreres i et teams arbeidsflyt, er fullt og helt en menneskelig ledelses- og kulturavgjørelse — verktøyet kan bevise sin verdi, men adopsjonsbeslutningen kan ikke automatiseres.

Hvorfor ingeniørteam må tenke nytt om arkitekturen sin

Den tidlige databehandlingen startet med én stormaskin som alle delte, før den gikk over til serverrack med spesialiserte tjenester. Agentene følger den samme utviklingen.

Den gamle antakelsen var å bygge en håndfull agenter for generell bruk og sentralisere bruken rundt dem, på samme måte som man sentraliserte datakraft. Men selskaper innser at virkeligheten deres ikke består av en håndfull delte verktøy — den ligner mer på et økosystem av spesialiserte, formålsbygde agenter. Dette tvinger frem en ny vurdering av hva «arkitektur» egentlig betyr for en kodebase: mindre monolitt med programtillegg, mer en mikrotjenesteverden, bortsett fra at tjenestene er agenter i stedet for endepunkter.

Instinktet i de fleste organisasjoner er å behandle en agent som enhver annen programvare — skrive spesifikasjonen, levere den og forvente konsistente resultater. Det la jeg bort og erstattet det med en arbeidsstyrkemodell. Dette omformulerer spørsmål om organisasjonsdesign — hvem godkjenner hva, hvem eier budsjettet, hvem er ansvarlig når noe går galt — til ledelsesspørsmål, ikke utrullingsspørsmål. Det er en annen måte å strukturere et teams forhold til verktøyene sine på.

Hvorfor styring må være på plass før AI-adopsjonen skyter fart

I mine tidligere roller skulle jeg ønske at vi hadde bygget styringslaget før adopsjonen skjøt fart, ikke etterpå.

Da jeg var i Meta, begynte ingeniører å bygge og publisere sine egne agenter på den interne plattformen; agentene formerte seg raskt, og infrastrukturteamet måtte plutselig kjempe for å holde tritt med etterspørselen — bokstavelig talt forsøke å finne titusenvis av ledige servere.

Dette kunne man i ettertid ha unngått. Hvis du antar at adopsjonen kan bli viral internt, bygger du kostnadskontroller og tilgangsgrenser inn som en del av plattformen fra dag én, ikke som krisehåndtering.

CTO-er må redesigne grensen mellom «hvor AI befinner seg» og «hva AI kan berøre» — flytte den ut av redigeringsverktøyet og inn i infrastrukturen, fordi det er på dette laget risikoen oppstår og styringen må ligge.

James deler

CTO-er må redesigne grensen mellom “hvor AI befinner seg

Hvorfor organisasjoner må ha et sentralisert sted der agenter kan forkes

Som ingeniør var jeg en bedre tyv enn programmerer. Jeg fant noe som delvis dekket behovene mine, tilpasset det til mitt spesifikke formål og lærte underveis.

Det første trinnet i arbeidsflyten er ikke «send en forespørsel til en modell»; det er å bla gjennom et sentralisert sted for å se hvilke agenter som allerede finnes for denne oppgaven, og forke en av dem i stedet for å begynne helt fra bunnen av. Organisasjoner må opprette prosesser som gjør det enkelt å stjele agenter.

Tre råd til CTO-er som integrerer AI i tekniske organisasjoner

Her er mine råd:

1. Ikke pålegg det – få folk med på det. Pålagt bruk av KI for produktivitet frustrerer meg fordi det fører til en overflatisk innføring – de beste utviklerverktøyene gjør seg fortjent til å bli brukt, og utviklere er smarte nok til å motsette seg å bli fortalt hvilke verktøy de skal like. CTO-er bør presentere forretningsutfordringer av en helt annen størrelsesorden for organisasjonen – problemer som er så store at KI er den eneste realistiske løsningen. Deretter bør man la ingeniørene som løser dem, bli naturlige ambassadører. 
2. Slutt å behandle KI som et verktøy for å skrive kode, og begynn å behandle det som infrastruktur. 2025 var året da kodeverktøy som Cursor og Copilot ble allemannseie. Nå slutter resonneringsmodeller og agenter som utfører oppgaver i flere trinn, å være programtillegg i kodeeditoren og blir i stedet en del av infrastrukturen i selskaper – de sender inn kode, kjører tester, setter nye ingeniører inn i arbeidet og håndterer atferd i produksjon. Hvis KI-strategien din fortsatt handler om «hvilket programtillegg til kodeeditoren bør vi kjøpe», løser du et gammelt problem.
3. Styr agenter slik du ville styrt en arbeidsstyrke, ikke slik du ville styrt programvare. Agenter som drives av resonneringsmodeller, er ikke-deterministiske – gi den samme agenten det samme inndataet to ganger, og du kan få ulike resultater. Dette er ikke en feil som må utbedres; det er teknologiens grunnleggende natur. CTO-er håndterer allerede ikke-deterministiske systemer hver dag gjennom ansatte. Du må bruke noen av de samme sikkerhetsreglene på agenter som du bruker på arbeidsstyrken din. Ikke gi en agent ubegrenset tilgang til produksjonsmiljøet, root-opplysninger eller et ubegrenset skybudsjett den første dagen, like lite som du ville gitt dette til en helt ny medarbeider.

Følg med

Du kan følge James Everinghams arbeid på X og LinkedIn.

Flere intervjuer med eksperter kommer på The CTO Club!